UI toolkits for Python

[Mike Meyer]

"Adriaan Renting" <renting at astron.nl> writes:

>>>>Mike Meyer <mwm at mired.org> 10/14/05 5:39 pm >>> 
> $"Adriaan Renting" <renting at astron.nl> writes: 
> $[On Qt] 
> $>I don't know how it performs on OSX, I think it works fine, as Qt is 
> $>available on OSX. 
> $ 
> $Qt on OS X is halfway there. It looks - and acts - like an aqua 
> $application. However, to support the Command key, they hacked things 
> $so that it is reported to the upper layers as the Control key. This 
> $means that there's no way to get to use the control key in the UI for 
> $qt apps on OS X. 
> $ 
> $This really rapes apps with configurable shortcuts. For instance, LyX 
> $comes with a couple of emacsish bindings. You can turn them on, but 
> $you have to use Command-key instead of Control-key, which pretty 
> $thoroughly defeats the purpose. 
> $ 
> $          <mike 
>
> You have the problem that some keyboard layouts have OS specific
> keys (Windows key, menu key on some PCs, Command key on apples)
> which you can't support in a cross-platform way. If using
> Command-Letter is the standard way of having keyboard shortcuts in
> OS X, then I think I can understand why they choose this
> implementation,. I suppose the Command key is more integrated into
> the OS as is the Windows key in Windows. I think it would be nice if
> you could choose the mapping.

It's quick and dirty and does the right thing for applications that
follow the UI guidelines on Windows and OS X. Generally,
Command-lumberjack on OS X does the same thing as Control-lumberjack
does on Windows or other CUA platform. If you want to let users bind
keystrokes, then they're out of luck.

> The basic problem is that a widget toolkit that supports
> control/shift/alt/command as meta-keys can not be cross-platform, as
> the command key has no equivalent in windows or linux. How do the
> other widget toolkits handle this, do they ignore the Command key?
> What does Linux PPC/YellowDog do with the Command key?

I really can't say, but it seems like the obvious way to do it is to
have the lower levels define the appropriate bucky bits for all
platforms. No platform will generate all those bits, but so what? That
just means youv'e got some symbols defined that won't be used on some
platforms. Actually, since there undoubtedly exists systems that can't
generate all the bucky bits for any given platform, that's "some more
symbols ...".

But I'm not a GUI designer, so there may be reasons for not doing it
that way that I can't see.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.