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).<br><br>-Wade<br><br><div class="gmail_quote">On Thu, Dec 11, 2008 at 8:07 AM, Wade Brainerd <span dir="ltr">&lt;<a href="mailto:wadetb@gmail.com">wadetb@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Chris,<div class="Ih2E3d"><br><br>On Thu, Dec 11, 2008 at 7:05 AM, Chris Marshall <span dir="ltr">&lt;<a href="mailto:jns-cmarshall@comcast.net" target="_blank">jns-cmarshall@comcast.net</a>&gt;</span> wrote:<br>
</div><div class="gmail_quote"><div class="Ih2E3d"><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!. &nbsp;Then when it resumed it seemed<br>
to hang. &nbsp;I then clicked on Play and dragged<br>
the slider to 100 and the image finally appeared.</blockquote></div><div><br>Gary Martin reported this too.&nbsp; It&#39;s an issue that appeared when I stopped Colors! from pegging the CPU all the time.&nbsp; There is an idle event that needs to be turned on when playback is running, it should be a simple fix.<br>

&nbsp;<br></div><div class="Ih2E3d"><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><div><br>Yep, makes sense - the mouse events wake up the &#39;update&#39; loop which allows the playback to make progress.&nbsp; There should be an idle event doing this while playback is active.<br>

<br></div><div class="Ih2E3d"><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><div><br>Git builds have a Copy button which copies the canvas to the clipboard.&nbsp; Note that Copy &amp; 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><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don&#39;t know if all wacom tablets have the same linear<br>
resolution. &nbsp;Ideally, the value for &quot;Suppress&quot; would be<br>
calculated from the native tablet resolution and the<br>
drawing area pixel dimensions. &nbsp;e.g. a tablet with only<br>
1000lpi resolution might work better with a value of 25.</blockquote></div><div><br>Good point - It would be nice to be able to specify Suppress as a ratio that takes into account the screen resolution.&nbsp; 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>

&nbsp;<br></div><div class="Ih2E3d"><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><div><br>Yeah, I will have to play with this to figure out how to make it most useful. <br><br></div><div class="Ih2E3d"><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. &nbsp;The problem<br>
I had would not have occurred if the zoom in and<br>
zoom out operations were inverses.</blockquote></div><div><br>Good idea!&nbsp; Zoom in will remain the same (e.g. focus on the mouse cursor), but I will change Zoom out to pop the stack. <br><div class="Ih2E3d"><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? &nbsp;Can this be done in xorg-dcon.conf?<br>
</blockquote>
<br></div></div><div class="Ih2E3d"><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. &nbsp;At any<br>
rate they can be detected and acted upon.</blockquote></div><div><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.&nbsp; 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><font color="#888888">Wade<br><br>
</font></blockquote></div><br>