[Edu-sig] PySqueak: more on the cultural divide among paradigms

[Paul D. Fernhout]

John Zelle wrote:
 > [Thoughtful outline of important design point
 > (and differences in priorities) snipped.]
> I know I'm asking a lot, but I also think it's all doable. This to me would be 
> the foundation for a "better than Squeak" Python environment. The "saving the 
> state" issue seems secondary to this basic foundation. How can we even talk 
> about saving the state of widgets that we don't "own."

On saving the state of non-Python widgets we don't own, in theory, a well 
written widget set like wxWindows should support queries on all the states 
of all widgets. Still, in practice, sometimes they assume you will 
remember externally what state you set something to, especially if they 
pass the value on to another layer (like the OS). For example, what if a 
bitmap is somehow converted into a native representation and the original 
discarded (not sure this is a problem, just making one up)? But I think 
those cases could be ignored at the start? And then treated as bugs in the 
widget set API? Clearly the most common things for having a list or text 
box selection or label, those should all be queryable. But, having not 
tried to do this, there could easily be unexpected gotchas, especially 
moving across multiple widget sets. I know in years past I have had this 
problem of missing accessors when writing code for applications that want 
to restore their exact window layout on reopening. And clearly, you could 
not move a saved image to a platform without bindings (and probably the 
same version of bindings) for the widget set the image was saved using. 
But in any case, while this is a vexing problem, and likely entails 
writing lots of widget specific code for each widget set, essentially it 
just involves creating a function for each type of widget that knows how 
to query and restore its state. However, obviously, that is a lot of code, 
and then it has to be maintained, and perhaps special cases ad widget sets 
changed. So, mostly doable I think (especially with something like wx, 
where you can submit changes to the project to fix access "bugs"), but a pain.

But I agree that if you design your own widget set using Python code, and 
it is represented by Python objects, then any major concerns about this 
save/restore issue go away. And I don't think this is reinventing the 
wheel as much as one might think, becuase any project with a compatible 
license coudl be looked at to get ideas or code for these basic widgets. 
For example, Lazarus and FPC if you can live with the LGPL license (and I 
conveniently have written a Delphi->Python translator that does 80% of the 
translation work. :-)

And I'm thinking now that even just the basics (using native fonts, like 
with a wx canvas) might be good enough for a proof of concept system, 
since you can do a lot quickly with a just text, icons, lines, and colored 
boxes (even without embedding dynamically generated bitmaps and bitblit!). 
You can build a whole development environment with mainly lists and menus 
(a wrapping text box for code is the hardest part). But it will probably 
look like the first released (1.13?) version of Squeak (until a lot of 
more work gets done). :-)

--Paul Fernhout