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 <[EMAIL PROTECTED]> wrote: > Hi Chris, > > On Thu, Dec 11, 2008 at 7:05 AM, Chris Marshall <[EMAIL PROTECTED] > > 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 > >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
