kde-4.5.5: partially lost fn keys on a wireless keyboard, right click only works on workspace 1

Duncan 1i5t5.duncan at cox.net
Sun Jan 23 11:16:26 GMT 2011


gene heskett posted on Sat, 22 Jan 2011 16:08:48 -0500 as excerpted:

> 2 questions actually...
> 
> I am an incurable fan of mc for a file manager.

So am I! =:^)

> However it appears
> recent updates to kde, now at 4.5.5, seem to have installed some key
> gobblers and the only Fn key that works in mc is the F10=quit key.  All
> of the others I have been reduced to using the mouse for, and I have a
> similar complaint when trying to control some of my home brewed scripts
> with htop, which can use a mouse but is extremely slow at recognizing a
> mouse click on the kill=F9 buttun.

FWIW I skipped the 4.5.5 update as I'm on Gentoo and updating would have 
meant building it.  I decided 4.6.0 was only a couple weeks away, 4.5.4 
was working fine, and none of the fixes in the changelog for 4.5.5 looked 
worthwhile enough to bother with that update, so I stayed on 4.5.4 until 
4.6.0 is released, scheduled for later this week (Jan 26, my B-day as it 
happens! =:^)

However, I've not had any such problems here and believe me, if I had have 
had them I'd have been crying bloody murder and reverting back to an 
older, working version, for sure, because as I said, I'm a heavy mc user 
here, too!

> The configure (drakethis and drakethat) menu's do not appear to address
> this specific issue.  32 bit pclos-2010 install on a quad core phenom,
> kernel 2.6.37.

FWIW, the drake* apps are distribution-family (from mandrake, now mandriva) 
specific.  The kde config method is using kcontrol, aka system settings 
(which is so hopelessly generically labeled as to be nearly worthless, not 
to mention that it's hardly accurate since most of the settings as kde 
ships it are kde specific and user specific anyway, *NOT* system settings, 
but that's what they renamed it to for kde4, tho the kde3 kcontrol remains 
more accurate).

So I'd suggest looking around in kcontrol aka system settings for kde 
config, as that's what people here will know.  For the drake* stuff, you'd 
post to your distribution's mailing lists, since that's what they'd know.

> Where should I go looking to be able to negate this unwanted Fn key
> gobbling for the first 9 keys?

You're running mc (and presumably htop as well) from a terminal window, 
presumably konsole, correct?  There's several levels at which things might 
be screwed and you can try to address this.  As I've not experienced the 
issue here, I can't say which one is triggering your problem, so you'll 
probably have to experiment a bit with all of them until you get things 
working correctly again.

0) Before you start, it's a good idea to see if the problem is in your 
user config or in the system-global config.  Try setting up a new user (or 
when kde isn't running, rename your ~/.kde or other user-specific kde 
settings dir), then launch kde with the blank kde config and see if the 
problem persists.

It's also worth checking for sure that it's not a hardware issue.  There's 
an X diagnostics app called xev (short for X-event) that, when run from 
konsole (or another terminal window app), will popup a window.  Moving 
your mouse around and/or hitting either mouse or keyboard buttons will 
cause it to report the triggered events on its stdout -- the terminal 
window.  Try hitting your function keys and ensure they're reported /as/ 
function keys, not function-control (stuck control key), not unrecognized, 
etc.  It shouldn't be difficult to get the hang of using xev for this sort 
of diagnostics, altho moving the mouse causes a **LOT** of events, that 
will quickly scroll anything else out of the terminal window.

Finally, consider installing and trying another terminal window app, xterm 
or gterm (if you have gnome installed) or something.  If mc works fine in 
it, still running under kde, pay particular attention to #2 below as it 
would appear to be your konsole config at fault.

The below assumes that it's either a user issue or that at least you can 
adjust the user config to fix the problem, if it's a global issue.

1) Application level.  In mc's options menu, select Learn keys...  At 
minimum you can use this for diagnostics, to see which keys it actually 
detects.  If worse comes to worse and it's not detecting certain keys you 
use a lot, you can try remapping them, here, as well.  But that's likely 
to be difficult if it's not seeing the function keys at all, as there's 
simply not enough other easily remembered combinations that aren't already 
used for something else.  But as I said, at least you can use it to see 
what's detected, running this after changing settings elsewhere, to see if 
it detects them properly, again.

2) Terminal window level.  Again, I'm presuming you're using konsole.  If 
you use a different terminal window app, see what sort of configuration it 
might have.  Meanwhile, I suspect this is actually where your problem is.

In konsole, select settings, configure profiles.  Then select the 
appropriate profile and hit the edit profile button.  In the resulting 
edit profile dialog, switch to the input tab.  I'm guessing this is what's 
screwed up altho as I said I'm not sure since I haven't seen the problem 
here.

FWIW, I haven't actually screwed with this much, as I've not needed to.  
Hopefully, you can fix the problem by simply selecting a different set of 
keybindings.  FWIW, here, I have the Default, (XFree 4), keybindings 
selected.  If I hit edit and move down to the function+anymodifier 
section, here's what it looks like:

F1+AnyModifier		\EO*P
F1-AnyModifier		\EOP
F10+			\E[21;*~
F10-			\E[21~
F11+/-			(as F10 but 23 instead of 21)
F12			(as F10 but 24)
F2			(as F1 but Q instead of P)
F3			(as F1 but R)
F4			(as F1 but S)
F5			(as F10 but 15)
F6			(as F10 but 17)
F7			(as F10 but 18)
F8			(as F10 but 19)
F9			(as F10 but 20)

There's a test area that you can use, too, if you need to modify any of 
these.  As I said, I think/am-hoping this is all that's messed up, and if 
you're lucky, all you have to do is switch keybindings profile, here, 
without even editing any of them.  As mentioned above, you can go into mc 
and test to see what it's recognizing, if you switch something around here.

3) KDE global hotkeys level.  Here's where kcontrol aka system settings 
comes into play.  Under common appearance and behavior, shortcuts and 
gestures, check all three applets and see if any of them are set to 
function keys that might be robbing them from mc.  This bit I've 
customized somewhat, so it just might be that I've not seen the problem 
due to my customizations overriding something else.  But it doesn't seem 
sane to me that they'd setup unmodified function-key shortcuts by default, 
for precisely the reason you're seeing -- they're too likely to conflict 
with another app that uses them.  So I really doubt it's this level, 
unless something got really screwed up somewhere.

My bet is still on #2, because I do remember having issues with that a 
long time ago, back on kde3, at one point.  All I remember is fiddling 
with the konsole keybinding profiles and trying mc's learn-keys thing, 
until I got it sort of working again.  But I think I might have been the 
one that messed it up for myself that time, fiddling with konsole's 
keybindings in the first place.  Which is why I've not touched it since.  
As long as it works, I'm not going to bother that bit.

> Secondarily, since the last update, I only have a right click menu for
> desktop settings on the first workspace.  No reaction to a right click
> on any other workspace, which of course are black, no background pix.
> 
> How can this be fixed?

The mouse button on desktop actions are configurable now, per desktop.  
Click on the toolbox (aka cashew) for each desktop and select desktop 
settings.  In the resulting dialog, select mouse actions on the left, and 
then setup the actions you want.  You can set separate actions for left/
middle/right and scroller triggers, with modifiers (ctrl/alt/meta/shift) 
as well if desired, so there's quite a few mouse actions available to 
assign stuff to, if desired.  The "standard menu" action is the 
traditional context menu, so that's what you'll probably want to assign to 
the (unmodified) right button.  AFAIK that's /supposed/ to be the default, 
but with 4.5, there's a bug and the default only gets assigned to the 
first one.  You have to assign it to the others yourself.  With 4.6 
hopefully that bug is fixed, tho I hope/expect that it'll leave the 
setting alone if someone's already customized it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.




More information about the kde mailing list