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. _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
