>>>Mike Meyer <[EMAIL PROTECTED]> 10/14/05 5:39 pm >>> $"Adriaan Renting" <[EMAIL PROTECTED]> 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
I think to some extent it's a general problem with cross-platform toolkits, altough I agree that I think the way Trolltech solved it for OS X might be sub-optimal, depending on how the command key is supposed to work. 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. 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? Adriaan Renting. -- http://mail.python.org/mailman/listinfo/python-list
