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

[Giovanni Bajo]

Bill Janssen <janssen at parc.com> wrote:

>> A control which displays and allows to interact with several lines of
>> widgets (e.g. labels, images...).
>> For example a buddy list in an Instant Messaging client.
>
> This seems like part of the application UI to me, not a toolkit issue.

No. The toolkit *shall* provide the controls. An application *shall not*
reinvent the wheel. Please, do not try to defend PyGUI behind necessary. PyGUI
*is* missing literally hundreds of features compared to PyQt or wxPython, and
your minimizing this difference won't make programmers less angry when they
don't find what they are used to find in a GUI toolkit.

>> You cannot assign a
>> global key shortcut to every command, while you can assign a local
>> hotkey to any menu item.
>
> This seems like creeping featurism to me.
> I can see the accessibility
> argument, but it is basically asking for the ability to drive an
> interface designed for use with a pointing device, without using a
> pointing device.  I'm not sure this is a reasonable constraint.

It is. Every GUI toolkit has this, every GUI program people use in the world
have this feature. Even if *you* believe it's not important, please accept the
fact that thousands of people might need it, and all other GUI toolkits provide
it for a reason.

> Global hot keys are the interface for a user without a pointing
> device; menus are the interface for users with a pointing device.
> This seems like a reasonable design.  Trying to mix modes is asking
> for complexity...

I don't care if it's a reasonable design. This is not how application works
under Windows or Linux. If I cannot reproduce the way native applications work
under Windows or Linux, the toolkit is trash to me. I'll keep my PyQt.

>> Well, a status bar is a container which can contain many things and
>> sits ...
>> It can probably be implemented using a Container, though. =
>
> Yes, it sounds like it is variable enough to be part of the
> application UI, rather than a standard component.

No, it should be a standard component because it's used by almost any non-toy
application, and it's mad to require that every application reinvent the wheel.
Every serious GUI toolkit has a statusbar. Again, you're making joke of
yourself with this kind of answers. Have you *ever* written a real-world
production-ready GUI application, which went through serious QA? It really
looks like you didn't, if you answer like this.

 >> In wxWidgets, the GUI system is able to calculate the minimal size
>> needed by each and any widget, and to prevent the user from resizing
>> the window below the calculated minimal size. =
>
> I'm not sure that this is effectively possible in all cases, but the
> "set_bounds" method on Container could probably be extended to
> optionally do this.

It has to be automatic. The *default* way to construct a widget must be so that
(if it's resizeable) it can't resize behind its limit. Otherwise, it's simply a
bug. Keep any one of the KDE applications and look at how it behaves. Did I
mention PyQt is already ready, powerful, complete *today*.

>> All that is not to say that "PyGUI s*cks" (it doesn't seem to ;-)),
>> but that there are a few important things lacking compared to more
>> mature (and possibly bloated!) GUI systems.
>
> Right.  I think that the question is, just what is missing, that is
> really necessary.


No. Anything *might* be necessary to someone. I don't want to add a label
because there is no statusbar. Or to tell my users "don't resize the dialogs
too small because my toolkit can't do the right thing, it's not necessary after
all".

The real question is why we should care about adding to the stdlib a GUI
toolkit which is light-years newer and more incomplete that any other mature
toolkit. I think this whole thread is pointless as it's clear that PyGUI is not
ready for being part of the stdlib. Let's discuss more mature toolkits, if we
have to.

Giovanni Bajo