On 22/10/10 01:47, Robert wrote:
But perhaps long time and debugging to get real world usability (Win). One could use the (bugfixed) existing behaviour, plus __getattr__ on the ._win Component member etc for first and hope for platform independent behavior later (some 90%+x auto-translate code).
I don't understand what you're talking about here.
py2exe and cxfreeze don't find the PyGUI autoloader stuff, one has to collect&pull some 80+ paths by extra function.
Yes, that's a bit of a problem. For apps intended to be py2exe'd, it might be better to explicitly import things from the relevant submodules, e.g. 'from GUI.Windows import Window' rather than from 'GUI import Window'. That way, py2exe will be able to find the modules that you use, together with the ones they depend on.
will try and go into it a little more. Further notes so far: currently no pythonic speedy late import is done for expensive stuff throughout the library to exploit the dynamic binding (like e.g. done in above .patch in GetDummyDoc).
I'm not sure if that helps much. If you're using ScrollableViews in your application at all, you're going to need a dummy doc template at some point, so you might as well get the overhead out of the way early on. This might be a difference in philosophy -- it annoys me when an application pauses randomly during its operation to load stuff up, so I tend to design things so that everything that is almost certain to be used is imported at startup. If you have an application that only rarely uses ScrollableViews, you can deal with that by delaying your import of the ScrollableView class until you need it.
A simple app pre-imports almost the whole mess, 80+ GUI mods plus pywin fully 1:1,
I'm not sure if there's much that can be done about that. There's quite a lot of infrastructure shared by all component classes, and the intertwinedness of the generic and platform-specific code requires splitting it into quite a lot of modules. Maybe the code could be pre-processed to fold things together into larger modules for installation, although I'm not sure how much that would help -- the total amount of code loaded would be the same.
(the __init__.py autoloader thus doesn't save a lot)
The purpose of the autoloader isn't so much to delay importing as to avoid importing things that won't be used at all. Currently the amount of optional stuff is a relatively small proportion of the whole, but that will change as more features are added.
No one should write a new GUI-lib which does not use AbcDef for method names.
We have another philosophical difference, then, because I believe that no-one should write a Python library that doesn't follow PEP 8 conventions, unless it's exposing a pre-existing API.
The menus seem to be a litte too automatic,
Yes, I know, and I'm thinking about ways to make it easier to customise them.
The string style constants/events etc. ... may disapear without trace if a letter is typed wrong
I acknowledge that more could be done to validate these.
(difficult for auto-completers, pychecker, ...).
Yeah... I just like them better than named constants, somehow. I think it's because they're automatically context-sensitive, so it avoids the need to give them unique prefixes. I don't use auto-completion, so that aspect of it didn't occur to me. Perhaps I could compromise by providing named constants for them as an alternative.
Didn't come to the new auto layout features (like wx / glade) so far ..
PyGUI does have auto layout features, it's just that they don't work quite the same way as they do in wx or gtk. There's an assumption that you will be laying things out once when you create the window, and after that it's just a matter of moving and resizing things sensibly when the user changes the window size. I'm thinking about ways to make more dynamic layouts possible, but there are some tricky aspects to it, such as the possibility of infinite loops occurring if layout changes can propagate both up and down the hierarchy. -- Greg _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32