[Sugar-devel] Wacom Bamboo with XO?

[Wade Brainerd]

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.laptop.org/pipermail/devel/attachments/20081211/d2979a2d/attachment.html>