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

[Paul D. Fernhout]

francois schnell wrote:
> Still take care of  yourself !  undefined day you should ...  time.sleep
> (7*60*60)

Well, after a good night's sleep, the bug I've spent endless time chasing, 
scouring all the delegation code in Prototypes.py for perhaps ten or so 
hours on and off, turned out to be a problem in the GUI code from all the 
way back to the wx code I copied for tk (which it turns out had the same 
problem). So nothing wrong with the delegation code (though I did optimize 
it some, and add a debugging flag during all the hair pulling. :-).

Avoiding these kind of mistakes is just the reason "pair programming" is 
surprisingly cost effective.
   http://www.pairprogramming.com/
 From there: "One programmer, the driver, has control of the 
keyboard/mouse and actively implements the program. The other programmer, 
the observer, continuously observes the work of the driver to identify 
tactical (syntactic, spelling, etc.) defects and also thinks strategically 
about the direction of the work." Someone looking over my shoulder when I 
wrote the original code might have noticed that and saved me lots of 
debugging. Need to add support for doing that virtually over the net with 
PataPata someday. :-) It's amazing how much even a novice programmer can 
contribute to an expert's productivity by just noticing something like 
that and asking a question about it while the code is being first written.

For those who are curious, or to mildly challenge your students, here is 
the offending piece of code (though most of the problem was knowing where 
to look, of course. :-):

     def duplicateMorph(self, morph):
         newMorph = morph.copy()
         self.addMorph(newMorph)
         newMorph.x += 5
         newMorph.y += 5
         if morph.getPropertyDefinition("createEmbeddedWidget"):
             morph.createEmbeddedWidget()
     World.duplicateMorph = duplicateMorph

As the Monty Python team might say, "Can you spot the loony [bug]?" :-)

============================
==== If you need a hint: ===
============================

  If I had done a better job of naming the input variable to 
"originalMorph" this would have been a more obvious problem.

Solution below: (*)

I also corrected the wx version, which used the identical code, which I 
had copied to the tk version.

> Don't worry about the package I've actually co the repository a day ago (on
> my XP and Kubuntu box) and will check for updates often to have my current
> juicy PataPata version :)

Great. :-)

> Here's the problem I have with the Tk version:
> 
> On Win XP :
> 
> - If I alt-right-click on a Morph and call the inspector it doesn't work 
> (ie
> I can see in the dos window that it called InspectMorph <Prototype xxxxx>
> but the inspector doesn't focus on this Morph)
> - If I manually search for a morph in the Inspector (where it says "morphs
> <'type list'>") and if I try to change its color for example (lets say
> 'red') and click "accept" => the morph disappear from the world and the dos
> window says : problem drawing morph <Prototype xxxx>
> 
> On Kubuntu Dapper Drake:
> 
> - the alt (left or right) click  doesn't work as expected : if I want to
> drag a morph I'm always dragging the whole application window and I can't
> drag an individual Moph anymore. If do an alt-right click I can't access 
> the
> menu to inspect the morph (I have a ~"resize" icon for the mouse cursor).
> - I have the same bug than for XP if I want to change a value in the
> inspector.
> 
> Maybe it is related to the bug you were talking about ? I can make a quick
> screencast if it helps you to visualize the problem.

Sorry about those difficulties. You've kept me busy for the afternoon. :-)

Probably no need for a screencast for these issues, but I'd love to see 
one for TK once things are working well for you.

First, so it works at all (even with smoke coming out :-)? That was my 
first concern, and implicitly I think that is answered by "yes". :-) Hooray!

For the the inspector tree updating, that was simply not finished. I had 
known about this, but I has just had not got around to fixing it. I have 
now fixed it and it is in the latest SVN. Should work for all platforms.

The non-widget morph disappearing and generating a drawing error message 
is most likely a problem with validation of whatever was entered for the 
color field. If TK can't interpret the color value of the widget, it can't 
draw it. I can't be certain that is the problem, but I think that is the 
most likely cause because I have seen it happen myself (like if I put in 
"blue" instead of "blue"). There is a color selector dialog now used under 
TK, though you need the world menu. In testing this just now, I'm finding 
the TK multi-line edit is adding an extra newline. I think this is a known 
TK issue, so I just now changed the code in SVN to strip that out, 
otherwise this will never work from the inspector? You can also use a new 
right click menu option of "edit value" which gives you a popup single 
line editor where you can enter "blue" and no newline is appended for 
sure. Please let me know if that problem persists after the latest SVN, in 
case it was from something else. I just added a way to validate (or 
otherwise alter) any changes to properties, using a 
"callBeforeSetFunction" defined in a property for a prototype, but I have 
not tested it. :-) Also, I do not know what are valid TK color options or 
how to determine this. [There is also another bug with setting colors if 
you use the color setting dialog and save the world, when it reads it in 
there will be an error and a loss of the color, though the world should 
still load properly otherwise and the inherited color will be used.]

Alt clicking is problematical under Linux because the default (for Gnome?) 
seems to be that alt click will drag the window in the window manager.
I'm thinking the dragging or resize curso behavior might be due to this.
Under Gnome, you can change Window manager preferences so that ALT does 
not drag windows (choose the "Windows" key instead).
The reason I picked "Alt" where I would rather have picked "Ctrl" is that 
Ctrl-click is used for multi-select in lists commonly, which I think is a 
common thing to want to do. I don't know of a common use for ALT (but 
maybe there is?). I don't have a good answer for this (other than changing 
the window manager preferences), although in response to this I just added 
support for setting the Meta key selection by uncommenting something in 
"options.py" so you could use Ctrl-click easily if you wanted to after 
editign that file. Still, I don't like making such a core part of the GUI 
changeable in terms of leading to confusion, so I don't know if this 
should stay). Another alternative would be to use Ctrl in all widgets 
except lists? Though that might be confusing in its own right. Maybe you 
or someone else can think of a better approach to this?
Please me know if these workarounds don't work for you.

By the way, I moved the choice of GUI to "options.py" as well.
wx should still work.

If everything seems OK with you with these fixes, I think I will soon bump 
the version number up to 1.1 and make another file release. The last 
really annoying thing I know of is that sometimes when you drop a widget 
it continues to drag; that needs more work first though; hopefully it is 
not a fundamental tk problem. I'll be curious if that is GNU/Linux only? 
Also, there is flicker in the TreeWidget from how it is used, but I think 
that is livable (I can't find an easy way to freeze it for a while like I 
did under wx). And drawn morphs are always below widget morphs but can 
sometimes be dragged if they are above them in the world morph list -- not 
sure what to do about that, other than get rid of the drawn morphs and 
make them draw in widget frames with a canvas (the likely solution). There 
is also no way to raise and lower morphs. Or the biggy new thing needed 
for HyperCard-like functionality, compositing morphs (or at least, nesting 
them). Lots more to do, but probably OK to put those off for the next release.

Thanks for your fortitude for living on the "bleeding edge" of technology, 
and I appreciate your continued interest and comments with the jump to TK. 
I now it's been a bumpy ride switching widgets toolkits, and I tried to do 
it fast to keep momentum moving on this project. I'm hoping that once the 
system is working well with TK it should be more malleable for more Python 
programmers.

--Paul Fernhout

(*) To understand the bug, renaming the input variable from "morph" to 
"originalMorph"  should make the problem more obvious:

     def duplicateMorph(self, originalMorph):
         newMorph = originalMorph.copy()
         self.addMorph(newMorph)
         newMorph.x += 5
         newMorph.y += 5
         if originalMorph.getPropertyDefinition("createEmbeddedWidget"):
             originalMorph.createEmbeddedWidget()
     World.duplicateMorph = duplicateMorph

That shows how the code used the original "morph" instead of "newMorph" to 
instantiate the new native widget, thus resultign in hooking up, say, a 
new native button to the old button's Morph prototype. So the the new 
Morph would never receive click events from the new native button, as they 
would go to the old Morph prototype directly. All the time I assumed it 
was some instead a problem with the delegation code.

So the corrected code, both that works and that is clearer.

     def duplicateMorph(self, originalMorph):
         newMorph = originalMorph.copy()
         self.addMorph(newMorph)
         newMorph.x += 5
         newMorph.y += 5
         if newMorph.getPropertyDefinition("createEmbeddedWidget"):
             newMorph.createEmbeddedWidget()
     World.duplicateMorph = duplicateMorph

A tip off to me should have been that the new morph was not offset by 5 
pixels in X and Y as with the drawn widgets. I had noticed that, but 
thought I'd look into that problem later. It was only when I started 
thinking about that anomaly instead that I found this bug. I am now 
thinking that had I looked harder at the newMorph, I might also have 
noticed that the widget field was presumably still None.