[Pygui] [python-win32] and PyGUI notes - Re: PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems

[Greg Ewing]

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