L
luc.saffre
Hello,
I thought that I should ask here for comments on a blog entry that I
wrote some weeks ago. I am sure that other people have been thinking
about this, but I didn't yet find them.
The Python standard library unfortunately doesn't provide a module that
gives unique names to common keyboard events.
Even Tkinter had to write a complex parser to find out which keyboard
event the programmer actually means. The parser literally plays a
guessing game. If you want an event to happen when the user presses for
example the key combination Shift-F7, then you (the programmer) are
free to call this key S-F7, Sh-F7, Shift+F7,... and many more. Tkinter
will understand you! This is artificial intelligence! At run-time,
while the user is waiting! What a strange approach!
wxPython is also funny. Here is an excerpt from the wxMenu::Append()
documentation:
The item string for the normal menu items (not submenus or separators)
may include the accelerator which can be used to activate the menu item
from keyboard. The accelerator string follows the item label and is
separated from it by a TAB character ('\t'). Its general syntax is any
combination of "CTRL", "ALT" and "SHIFT" strings (case doesn't matter)
separated by either '-' or '+' characters and followed by the
accelerator itself. The accelerator may be any alphanumeric character,
any function key (from F1 to F12) or one of the special characters
listed in the table below (again, case doesn't matter):
wxPython has a lot of constants to name common key events. For example
the «page down» key is called wx.WXK_PAGEDOWN. But if you specify
PAGEDOWN in a wxMenu::Append() string, it won't work. Because for
wxMenu::Append() you must call this key PGDN.
I don't blame neither Tkinter nor wxPython, but these funny
observations show that a standard method to speak about keyboard events
would be useful.
I agree that the subject is not trivial, and that there are more than
one possible ways to implementat such a module. But as long as I don't
find a better solution I'll use my selfmade module:
http://svn.berlios.de/wsvn/lino/trunk/src/lino/forms/keyboard.py?op=file&rev=0&sc=0
(Original entry is at http://lino.saffre-rumma.ee/news/356.html)
Luc
I thought that I should ask here for comments on a blog entry that I
wrote some weeks ago. I am sure that other people have been thinking
about this, but I didn't yet find them.
The Python standard library unfortunately doesn't provide a module that
gives unique names to common keyboard events.
Even Tkinter had to write a complex parser to find out which keyboard
event the programmer actually means. The parser literally plays a
guessing game. If you want an event to happen when the user presses for
example the key combination Shift-F7, then you (the programmer) are
free to call this key S-F7, Sh-F7, Shift+F7,... and many more. Tkinter
will understand you! This is artificial intelligence! At run-time,
while the user is waiting! What a strange approach!
wxPython is also funny. Here is an excerpt from the wxMenu::Append()
documentation:
The item string for the normal menu items (not submenus or separators)
may include the accelerator which can be used to activate the menu item
from keyboard. The accelerator string follows the item label and is
separated from it by a TAB character ('\t'). Its general syntax is any
combination of "CTRL", "ALT" and "SHIFT" strings (case doesn't matter)
separated by either '-' or '+' characters and followed by the
accelerator itself. The accelerator may be any alphanumeric character,
any function key (from F1 to F12) or one of the special characters
listed in the table below (again, case doesn't matter):
wxPython has a lot of constants to name common key events. For example
the «page down» key is called wx.WXK_PAGEDOWN. But if you specify
PAGEDOWN in a wxMenu::Append() string, it won't work. Because for
wxMenu::Append() you must call this key PGDN.
I don't blame neither Tkinter nor wxPython, but these funny
observations show that a standard method to speak about keyboard events
would be useful.
I agree that the subject is not trivial, and that there are more than
one possible ways to implementat such a module. But as long as I don't
find a better solution I'll use my selfmade module:
http://svn.berlios.de/wsvn/lino/trunk/src/lino/forms/keyboard.py?op=file&rev=0&sc=0
(Original entry is at http://lino.saffre-rumma.ee/news/356.html)
Luc