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

[Paul D. Fernhout]

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