From: Brice D. <bri...@ve...> - 2006-12-19 14:15:20
|
On Mon, 18 Dec 2006 22:09:03 -0500, Andrew Trevorrow <an...@tr...> wrote: > Hmm, I don't see this in my GTK version (Debian). Tiles with selections > behave just like they do in the Mac and Win versions. Does the stutter > only occur while you are dragging the selection cursor? By stutter, do > you mean the selection rect is continually being redrawn? Yes, it's the dragging that stutters badly when multiple universes have simultaneous selections. It depends only on how many selections are active, not which order the layers are visited. > I'm wondering if this (and the next) problem could be due to a GTK bug > or incompatibility? Which version of GTK+ do you have installed? > According to the Synaptic Package Manager, I have libgtk2.0-0 package > version 2.6.4-3.1 installed (the 3.1 is my Debian version). I have the same GTK libs on a Debian derived system. > This sounds like a GTK+ bug or wxGTK bug. When a selection drag begins > I do a CaptureMouse() call so that I'll get a mouse-up event regardless > of where the mouse might be when that happens. It sounds like I'm not > getting the mouse-up event and so ReleaseMouse() is never called. Exactly -- something like that. I imagined the stuttering was causing your code to miss the "closing parentheses" mouse event. Somehow the layer 1 window state got corrupted. Maybe not just because layer 1 missed the ReleaseMouse, but also because some other component recieved a mouse event in an order you didn't anticipate. That might be a GTK bug, but maybe there's additional GTK housekeeping functions that prevent this kind of problem when events are being processed slowly? > If you get into that state again, try hitting the escape key -- that > should force a ReleaseMouse() call. Ok. Like I said, any hotkey which activated the golly menus was enough to break the grab. Unfortunately the layer 1 window was "stuck" in this mode. I could use all the other layers fine, but every time I tried selecting inside layer 1 I got the exclusive grab again. That's what's strange -- the new mouse mode became persistent. If it had only happened once I wouldn't have mentioned it. If it was the dropping of ReleaseMouse then why were all future CaptureMouse exclusive (modal)? All future CaptureMouse (or whichever) were grabbing the cursor from the entire desktop and all of the rest of golly. > Hopefully you can find reproducible steps to get into that buggy state, > but if I can't duplicate them here it could be tricky to fix. > Try renaming GollyPrefs to see if that forces the problem to occur. Good idea. I'll delete it. Thanks, -brice -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |