Python GUI?

Michael Torrie torriem at gmail.com
Wed Sep 18 16:10:12 EDT 2013


On 09/17/2013 10:19 AM, Benjamin Kaplan wrote:
> Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
> Win32 on Windows). Other programs that want to hook into yours, such
> as screen readers, are familiar with the platform's native GUI
> elements- it knows what a Win32 combo box is, and it knows how to read
> the text inside it.
> 
> The other way to make a GUI is to take a blank canvas and draw on it
> yourself. This is more flexible and provides a more consistent
> experience across platforms, but unless you specifically go out of
> your way to provide hooks for other programs to jump in, all they see
> is a bunch of pixels on the screen. In addition, drawing your own
> stuff won't necessarily give you the "normal for the operating system"
> behavior on other things, like tab behavior. It's possible for
> non-native GUI environments to mimic this behavior (and QT does a
> pretty good job of this), but there's always going to be little things
> that seem a bit off.
> 
> The situation is a bit more complicated because QT is the native
> toolkit on KDE, so in that environment, QT will be more "correct" than
> wx, which would be using GTK if present and plain X11 if it isn't.

I don't think the distinction you're drawing is really all that
important.  Almost all platforms now have accessibility APIs which are a
way better way to go than relying than trying to scrape the information
by peaking into GUI structures that could change.

And on Windows, while the Win32 widget stuff you speak of is a lowest
common denominator, few modern apps use it directly anymore.  MS Office
set the the example early on by creating a new widget set for every
release (using the blank canvas method you describe!).  .Net apps using
winforms use yet another widget set.  They all now use the theming API
to draw their widgets (just like Qt does on Windows), but do their own
even processing, etc.

And it turns out that wxWidget's use of the old win32 widgets means that
some widgets just look plain old and out of place on a new Windows 7 or
8 machine, though MS has tried to make the older widgets work better
with the new theming api:

http://wiki.wxwidgets.org/WxFAQ#Why_does_my_app_take_a_Windows-95-like_look_on_Windows_.3F

My point is, the former method isn't actually the best way to go in the
long run.  The second turns out to work out better, once things like
accessibility frameworks and theming apis are in place.  Perhaps in the
future MS Windows will just provide a drawing method and a theming api.



More information about the Python-list mailing list