francois schnell wrote: > Maybe you could go for a little smaller frame than 850 in height : on a > 1024*768 setting I can't catch the the "save button" and it wil help me for > screencasts :)
Good idea. I shrunk the example to 800x600, and repositioned and shrunk some widgets to make that all fit, so as to make screencasts / screenshots of the example world easier. The changes are in SVN. If you need space to work, you can always enlarge the window after it is running. Anything to help keep those great screencasts coming. :-) > BTW I just love now the fact that I can drag and reorganize completely all > the elements of the interface (buttons, inspector) in term of position, > size, etc. Cool. Glad you like it. That is the ultimate promise of the system. At this point, in theory, you should be able to bootstrap it completely using just itself. In practice, I find myself still editing the original source files for now. I'm not sure at what point I would make the switch over. I have a feeling I have to think more deeply about issues related to multiple worlds sharing code, and also a difference between application code prototypes and library code prototypes, perhaps with a writer that doesn't write out library prototypes but puts a reference to them and the version of the library to load from when the world reloads. Still, you can now "shoot yourself in the foot" by deleting the inspector widgets (or doing a "clear"). What I want to have is worlds talking to worlds, so your inspector can be in another world, where it is not operating on itself (you could then have another inspector operating on it in another world of course, recursively). I've just been reading about the TK "Send" command, which allows you to execute arbitrary TCL code in another TCL/TK application running in the same X session. That sounds like what I wanted to do with PataPata in terms of having worlds send Python code to each other. I had been worried about the security issues and wanting to have a Python sandbox for such code, but if TCL/TK has been doing this for more than a decade (with me reinventing this wheel :-) then it seems like doing that with Python should be acceptable as long as I do some minimal security equivalent to what TCL/TK does. [Which also means that all Python Tkinter apps may have been accepting this risk already for a very long time, too.] I could perhaps use the TCL "send" facility to get started; I need to look into that, though I read somewhere the TCL/TK Win32 may not support Send, it seems, so if that is true I definitely want something that does. Still lots to think about and do there. > 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. > BTW I could maybe present your work in the Python section of > the > Libre Software Meeting in July in France if you're OK with that and if you > feel it's not too soon. > > It's a kind of "big bazaar" in a French University and there's a Python > section too organised by the French Python User Group (AFPY). I could apply > for a small presentation (there maybe won't be a lot of people since there > are lots of // tracks in this meeting but it could interest some python > users/developers). > http://www.rmll.info/?lang=en That would be fantastic. I'm still a little nervous PataPata is not finished or polished enough to have too many users right now. You've been tolerant of the bumpy ride (thanks); most people probably would not be. But maybe if you presented PataPata/PySqueak as an experimental work in progress? Or just a fun thing to try to see what is possible in Python using a prototype-programming paradigm? As opposed to presenting it as a finished work to use to build the next great misson-critical application. :-) Anyway, I don't want to discourage you from presenting on it. I think that would be great, and a few more interested people trying it on different platforms, say the Mac or FreeBSD, would be wonderful. And if a few of them wanted to build something on top of it or make improvements to the core, that would be great. I'm just trying to encourage you to keep the audience's expectations low for now, both because it is a work-in-progress and also mostly because I don't have the time myself to provide technical support to more than a handful of users right now. :-) Still, everything is in sourceforge, so there is lots of potential for collaboration there, including others taking it in new unexpected directions. === possible future directions === I think if I could have a Jython version where you could do a one click on a web site and get a Python/Jython PataPata prototype development environment runnign on your system, then that might be something realy worth reporting. :-) I was encouraged by the fact that when you and Andre tried it, the Java Webstart system worked as advertised and even gave you 3D images (if you have Java installed and OpenGL drivers properly configured). But adding such an extra platform also entails a bit more thinking and refactoring related to abstracting out cross-platform issues. That is the opposite of the advice I gave Johannes about committing to pyCairo in the "elementary graphics" thread, I know, :-) but I think a specific graphics library choice is easier to insist on then to insist on a single choice of an event driven widget set choice. For example, I would expect pyCairo probably doesn't require X11 be installed on the Mac. Here are pyCairo's Mac dependencies, by the way, but I am not sure what in practice that means for installation difficulties of a binary package? http://www.hmug.org/pub/MacOS_X/BSD/Development/Languages/python/pycairo/ I'm still tempted to make pyCairo an important part of PataPata down the road, but likely without a GTK requirement (since I think Brad has a good point on GTK issues for the Mac for now), especially if any Mac users chime in on the feasibility of an easy installation for just that part. It sounds like, from your report, and my experience, that using just pyCairo under Wind or GNU/Linux requires just a fairly easy install. Anyway, the widget sets were surprising easy to hook up, at least for the basics, so it seems to me that it might be possible, without too much trouble, to have cross-platform support for wx, tk, Jython/Swing, GTK, and Cocoa/Mac, at least as far as the basics of handling a button which clicks, a text field that you can get the current value, popup message boxes, and so on, which might then be enough to make simple cross-platform HyperCard like stacks. Obviously, people might want to do native things with the particular widget set they choose to use, but providing at least some simple cross-platform support for the most common things might making porting easier later. So, as I write this, I find myself, at some reluctance, following the "worser is Better" philosophy of design: http://www.jwz.org/doc/worse-is-better.html "The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing." :-) > BTW I can now also change values and method without any problems with your > new version. Thanks for the feedback that that part works. I'm thinking the original issue was from the tk text-entry extra newline issue, which I worked around. --Paul Fernhout _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
