[Python-3000] PyGUI in Py3K stdlib, more details

[Greg Ewing]

Bill Janssen wrote:

> 1)  I'd add some kind of standard analog value control class,

You're in luck - I've just almost-finished adding a Slider control.

> 2)  There needs to be some kind of combobox multiple-value choice
>     widget

Yes, there are several more controls like this that I would
like to add at some point, once I get the basic infrastructure
in place.

> 4)  The widget class hierarchy should probably be re-worked a bit to
>     use more abstract mix-in classes.  For instance, the PyGUI Container
>     class should probably be abstract (rather than inheriting from
>     Component). This would make it easier to implement new components
>     in pure Python.

Not sure I follow you here. Any pure-Python component is going to
be subclassed from either View or Frame, which are already Containers.
The only thing it would make easier is creating a Python component
that *wasn't* a Container, which is a somewhat purist thing to want
to do, since if you don't want to add subcomponents you're at
liberty not to do so. :-)

If you're thinking that you could take e.g. a Button, mix it
with Container and then add subcomponents to it, that wouldn't
work. It's a deliberate design decision that most of the
predefined components are *not* Containers, because adding
subwidgets to them is not easily supported on some platforms
without adding considerable overhead to all instances of them.

The current design was arrived at after a lot of experience spanning
about 5 different implementations. While it might be a bit cleaner
conceptually for Component to be a mixin, I'd be very reluctant to
reorganise the hierarchy at this stage without some very careful
thought.

> I think I see why the current implementation exists,
> because the toolkit dates from the pre-grand-type-unification days,

I don't think that has much to do with it; mixins worked just
as well with old-style classes as long as you kept them
orthogonal. It's just that the current hierarchy made sense
and expressed the constraints I wanted to impose.

> 5)  There should probably be a new class to permit rendering into a
>     PDF stream, for printing.

There will be some kind of support for printing at some stage.
Whether it will promise to produce PDF or not depends on what
sort of support there is for this across the target platforms.

> An editable styled-text widget would be interesting, instead of the
> simpler editable text widget that already exists.

Yes, that's another thing I have in mind. I need to find out
what's available on Windows before I get too carried away with
this, however.

> It would also be useful to have pure-Python implementations of all the
> widgets, to make porting it to a new platform dirt simple.

That's a possibility too, although it could be a lot of work,
especially for the more advanced things like rich text editing
and table/tree views.

> By the way, I would not include the OpenGL widgets currently in PyGUI
> into the standard GUI.  At least, not yet -- they are still clearly
> being experimented with.

As far as I'm concerned, the whole thing is still being experimented
with. I'm still making changes to the API now and then as I gain
experience with what works well and what doesn't. The OpenGL part
isn't really any less stable than the rest -- it just looks that
way. :-)

Thanks for your comments,
Greg