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