[Edu-sig] PySqueak: pyGTK & Cairo & pygtkglext (OpenGL) next?

[Paul D. Fernhout]

Just as an update, I've released a 1.10 version of PataPata at:
   http://sourceforge.net/project/showfiles.php?group_id=165910

As a recap of what is new relative to the previous version, there is now a 
TK version in addition to the wxWidgets version. The TK version has the 
inspector and other controls live in the world (so the inspector can 
inspect and modify itself, you can "shoot yourself in the foot" by 
deleting the file "open..." and "save..." buttons or the inspector edit 
field, etc.).

One recent change related to the flicker and dragging problem discussed 
here is that the TK version no longer updates the inspector when you click 
on a morph. You have to ALT-right-click to bring up the menu and pick the 
first item which says "inspect morph". That solved both most of the 
flicker issue (still a little) and, more importantly, the dragging bug 
(where a widget kept tracking the mouse after you let go of it). This is 
little less convenient in some ways, but I'll see how people take to it. 
The interface feels a little less "hyper" now (in a good way). :-)

No solution yet for the ALT-right-click menu flicker issue under windows.

I did try to do just ALT-dragging to move morphs under TK (without a need 
for a mouse click), but gave up on it for now as I ran into a few issues. 
It turns out you need to click first in the frame to get TK to listen for 
keys. So, if you are just mousing over the window, and press ALT, it might 
in some cases not work. Also, frustratingly, the canvas (as opposed to a 
frame) seemed to ignore key events for some reason despite my trying lots 
of variations (you would think that would be resolvable, but with the 
first issue making me wonder if it was a good idea, I did not pursue that 
at great length).

Still lots of stuff to do.

--Paul Fernhout

Paul D. Fernhout wrote:
> francois schnell wrote:
>>I didn't saw that yet but sometimes (rarely)  on Win & LInux,  if I
>>alt-click & drag a widget/morph quickly and then if I stop pushing the
>>alt-key and continue to move the mouse away the morph drop but if I press
>>the alt key again in the world the morph go to the new position of the
>>mouse.
>>This is not a big problem (at least  for me).
> 
> 
> Yes, that's the sort of thing, generally with fast drags, and I suspect it 
> may have something to do with dragging widgets over or under other widgets 
> at  the same time. Not sure exactly where the problem is. I suspect it is 
> in TK not processing some events fast enough somehow and perhaps even 
> dropping events. I need to look more at this. One thing I have been 
> thinking of, which might help with the TK events, is switching to a drag 
> model where a drag starts when you press the ALT key down (not the mouse 
> button), so to drag you would mouse over to a widget, press the ALT key, 
> watch the widget move while dragging, and then let go of the ALT key when 
> you were done. I'm hoping to code that up and see how it feels, and if it 
> as a byproduct solves the problem. It may introduce another problem though 
> -- if you press the ALT key at any other time when using the system (say 
> by mistake) your widgets might move. I'll have to see if that is a serious 
> problem in practice. Anyway, not certain I will do that, but just one 
> approach. And not sure it will map to all platforms either.
> 
> 
>>On the other-hand on WinOS  if I right-alt-click on a morph  I need to
>>engage in the menu and "quickly" stop pressing the alt-key (otherwise the
>>menu is flickering and its difficult to choose an entry of the menu). When
>>you know it after its fine.
> 
> 
> Hmmm, need to think about that. Clearly that is awkward. I wonder how 
> other widget editors cope with that. Originally, in an earlier proof of 
> concept I had a right click menu (without requiring ALT) which joined 
> together the widget options and the world options. (I could have made a 
> cascading menu for the world options at the top, I guess). I'm reluctant 
> to abandon the "ALT" difference for menus, but I could consider going back 
> to that old approach. But if I do, then any common widget that puts up its 
> own menu using native calls might not have access to the world menu 
> (unless it explicitly does something). On the other hand, not many native 
> widgets use menus out-of-the box I think (probably there are some fancy 
> complex widgets, like graphs with their own internal menus). It seems like 
> in using native widgets,there simply will need to be some compromises 
> somewhere.