On Thu, 7 Mar 2002, Hanno Mueller wrote: > Hi, > > First of all, sorry that the original message appeared twice. I had sent > it before I was subscribed to the list, then again when I was subscribed. > Seems that the moderator approved the original message now. > > > > The problem is - these additonal keys don't bind to unused scancodes (as > > > the usual internet keyboards found in ./lib/X11/xkb/symbols/inet), but are > > > mapped on combinations of Shift+Control with a scancode already used for > > > normal keys. A few examples: > > > > > > Sleep: Shift+Control+7 > > > Eject: Shift+Control+A > > > Play:Shift+Control+F2 > > > Vol+:Shift+Control+F9 > > > etc. > > > > What do you mean? Shift+Control+7 is not a scan code. > > As I said - "Shift+Control *with* a scancode already used", in this case, > the scancode of "7". > > > Is this what you have to press in e.g. windows to "sleep"? > > The extra button of this particular keyboard labeled "sleep" creates the > keyboard events > > shift key pressed > control key pressed > 7 key pressed > 7 key released > control key released > shift key released > > So if I press "Shift+Control+7" on the same keyboard, it does the same > thin in windows as the "sleep" button, yes. > > > I told you it's an odd product! :-) > > > > What do you mean? Do you ant a different behaviour for a different shift > > or a different control key? (there are two of each) > > I want a different keyboard symbol coming out for "7" when it is pressed > with "Shift+Control". In this case, XF86Sleep. > > > > Also have a look at compat/group(ctrl_shift_toggle) for group shifting > > with ctrl-shift. Maybe make something similar, but replace groupe toggling > > with switching of group or of shift level. (I'm just thinking a loud) > > Yes, I looked at that for inspiration. I had the same idea, butoriginally > hoped that there may be an easier way of doing it. > > > > > So, is there a _simple_ way to tell xkb to translate > > > > > > Shift+Control+7 => XF86Sleep? > > > > Usually those things are much easier to define at the application level > > (e.g: window manager). Actually, configuring any window manager to execute > > a certain command on a certain key combination is usually *very easy* > > Wandering off-topic here, but... > > Oh, I wish it was. Actually, it's not quite *that* easy. In most cases, it > is very poorly documented (I spent the last two evenings reading the > Debian testing documentations of fvwm2, fluxbox, blackbox, WindowMaker, > KDE2.2...)
KDE, as usual, does not allow the user to easily do such things. Blackbox (and maybe fluxbox as well) has a very minimalistic approach, and I wouldn't be surprised if it would have relied on another program for such operations. A quick freshmeat search gives me: http://freshmeat.net/projects/hotkeys/ http://freshmeat.net/projects/khotkeys/ > > E.g., I haven't yet figured out how to attach running a command like > "eject cdrom" or "increase mixer volume" to a keyboard shortcut in the KDE > 2.2 window manager. One can only attach keyboard shortcuts to KDE events > like "close window" or "maximize window", but that's it. > > Also, I'm still looking for a way to remap key presses to different > behaviour depending on the application that has the window manager's > keyboard focus. > > E.g., mp3blaster uses a different "fast forward" shortcut than mplayer, > but they both don't allow configuring the keyboard shortcuts unless you > change the applicationsat the source level. > > AFAIK, no window manager allows to do this kind of remapping keys in the X > event queue. > fvwm? icewm? (maybe) Those are simple two WMs I know good enough. What you should look at is the window class and window name. > Ironically, the (in my opinion) ugliest window manager of them all - fvwm2 > - is the one that is documented best and easiest to configure to handle > such special keys. > Careful not to start a flame war on such a sensetive subject :-) The default configuration of fvwm in distros is indeed ugly, but given enough times... (I figure that there are some cool screenshots in www.fvwm.org as well ;-) ) > > > Note that there isn't exactly an "event" XF86Sleep (you don't really need > > it uness you have a laptop or so. If you have a desktop, "sleep" usually > > gets in your way, and the sooner you disable APM, the better) [ snip ] > And I don't want to discuss APM here, but I'm talking about an Intel-based > set-top-box where power management and suspend to disk *do* make sense. > Haven't had a single problem with APM in five years of running Linux... (I'm talking about the times I accidentally pressed this button on windows ;-) ) Cheers -- Tzafrir Cohen /"\ mailto:[EMAIL PROTECTED] \ / ASCII Ribbon Campaign Taub 229, 972-4-829-3942, X Against HTML Mail http://www.technion.ac.il/~tzafrir / \ _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
