[Sugar-devel] Wacom Bamboo with XO?

[Wade Brainerd]

BTW, if any of you guys playing around with Colors! have access to multiple
XOs, I would love to hear how the collaboration feature is working (and what
you think about it).

-Wade

On Thu, Dec 11, 2008 at 8:07 AM, Wade Brainerd <wadetb at gmail.com> wrote:

> Hi Chris,
>
> On Thu, Dec 11, 2008 at 7:05 AM, Chris Marshall <jns-cmarshall at comcast.net
> > wrote:
>
>> I tried to get an image of my finished drawing
>> from the Journal but the only option was to
>> resume Colors!.  Then when it resumed it seemed
>> to hang.  I then clicked on Play and dragged
>> the slider to 100 and the image finally appeared.
>
>
> Gary Martin reported this too.  It's an issue that appeared when I stopped
> Colors! from pegging the CPU all the time.  There is an idle event that
> needs to be turned on when playback is running, it should be a simple fix.
>
>
>> Trying to reproduce the problem, I noticed that
>> if I move the stylus pointer while the program
>> was resuming, it looked like progress started to
>> be made or at least updates to the display.
>
>
> Yep, makes sense - the mouse events wake up the 'update' loop which allows
> the playback to make progress.  There should be an idle event doing this
> while playback is active.
>
> How can one get an image of the drawing for
>> sharing/printing/...?
>
>
> Git builds have a Copy button which copies the canvas to the clipboard.
> Note that Copy & Paste semantics will be slightly different from normal
> apps, in that Copy will copy the current canvas state, while Paste will
> paste into the Reference Image.
>
> I don't know if all wacom tablets have the same linear
>> resolution.  Ideally, the value for "Suppress" would be
>> calculated from the native tablet resolution and the
>> drawing area pixel dimensions.  e.g. a tablet with only
>> 1000lpi resolution might work better with a value of 25.
>
>
> Good point - It would be nice to be able to specify Suppress as a ratio
> that takes into account the screen resolution.  Perhaps a filter in the
> mouse event handler would be more effective after all, since it could just
> take into account the screen space movement when discarding events.
>
>
>> Maybe whiten the image slightly as if looking through
>> paper and make it easier to have it be a visual guide
>> independent of the drawing itself?
>
>
> Yeah, I will have to play with this to figure out how to make it most
> useful.
>
> You might keep track of the zoom center for each
>> level and then just pop the stack.  The problem
>> I had would not have occurred if the zoom in and
>> zoom out operations were inverses.
>
>
> Good idea!  Zoom in will remain the same (e.g. focus on the mouse cursor),
> but I will change Zoom out to pop the stack.
>
>  Maybe one of the Wacom buttons could be assigned to the Frame key event?
>>  Can this be done in xorg-dcon.conf?
>>
>
> I think the buttons look like mouse-ish events.  At any
>> rate they can be detected and acted upon.
>
>
> Perhaps we can map it to Mouse4 or some other obscure mouse button, and
> then patch Sugar to recognize that as the frame key.  That would actually be
> kind of nice for people with many-button mice to be able to open the Frame
> without reaching for the keyboard, since the Frame is mouse driven anyway.
>
> Best,
> Wade
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20081211/e9ce7c78/attachment.htm