Hi Chris,<br><br>On Thu, Dec 11, 2008 at 7:05 AM, Chris Marshall <span dir="ltr"><<a href="mailto:jns-cmarshall@comcast.net">jns-cmarshall@comcast.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I tried to get an image of my finished drawing<br>
from the Journal but the only option was to<br>
resume Colors!. Then when it resumed it seemed<br>
to hang. I then clicked on Play and dragged<br>
the slider to 100 and the image finally appeared.</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Trying to reproduce the problem, I noticed that<br>
if I move the stylus pointer while the program<br>
was resuming, it looked like progress started to<br>
be made or at least updates to the display.</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
How can one get an image of the drawing for<br>
sharing/printing/...?</blockquote><div class="Ih2E3d"><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don't know if all wacom tablets have the same linear<br>
resolution. Ideally, the value for "Suppress" would be<br>
calculated from the native tablet resolution and the<br>
drawing area pixel dimensions. e.g. a tablet with only<br>
1000lpi resolution might work better with a value of 25.</blockquote><div class="Ih2E3d"><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Maybe whiten the image slightly as if looking through<br>
paper and make it easier to have it be a visual guide<br>
independent of the drawing itself?</blockquote><div class="Ih2E3d"><br>Yeah, I will have to play with this to figure out how to make it most useful. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You might keep track of the zoom center for each<br>
level and then just pop the stack. The problem<br>
I had would not have occurred if the zoom in and<br>
zoom out operations were inverses.</blockquote><div class="Ih2E3d"><br>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. <br><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maybe one of the Wacom buttons could be assigned to the Frame key event? Can this be done in xorg-dcon.conf?<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think the buttons look like mouse-ish events. At any<br>
rate they can be detected and acted upon.</blockquote><div class="Ih2E3d"><br>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.<br>
<br></div></div>Best,<br>Wade<br><br>