[Sugar-devel] Wacom Bamboo with XO?
wadetb at gmail.com
Thu Dec 11 11:55:51 EST 2008
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).
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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel