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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
