Bug 1026

Created attachment 654 [details]
(second attempt to attach after the first attempt failed without explanation: have I mentioned how much I despise Bugzilla?)

*** Bug 1709 has been marked as a duplicate of this bug. ***

What is an appropriate usability test for this patch? The only "modern" keyboard I have is with a Thinkpad T400. What needs to be reconfigured in KControl to test this patch?

(In reply to comment #3)
> What is an appropriate usability test for this patch? The only "modern"
> keyboard I have is with a Thinkpad T400. What needs to be reconfigured in
> KControl to test this patch?

See this link
http://askubuntu.com/questions/19558/what-are-the-meta-super-and-hyper-keys

In particular:

"The Meta key is not found on modern keyboard, it's use is sometimes emulated with AltGr (on some international layouts) or the right Alt key on the others"

Try adding

Option      "XkbOptions" "altwin:left_meta_win"

to the keyboard options in your xorg.conf, and restarting X. That'll make the left windows key a meta key.

I rebuilt tdebase with the patch. I'm doing something incorrectly. I created /etc/X11/xorg.conf/10-keyboard.conf:

Section "InputClass"
  Identifier "system-keyboard"
  MatchIsKeyboard "on"
  Option "XkbOptions" "altwin:left_meta_win"
EndSection

After I start konsole the left windows key does not function like the Alt key. For example, after starting midnight commander in konsole, pressing Left_Win+h should open the history dialog but only prints the letter h.

Ideas?

Are you sure those options are being applied? /var/log/Xorg.$DISPLAY.log should report the keyboard options in use, e.g., here:

[   156.939] (**) Option "xkb_options" "altwin:left_meta_win,altwin:super_rwin,altwin:hyper_prtsc,keypad:pointerkeys,grab:break_actions,lv3:enter_switch,compose:paus"

(You can have multiple keyboards, so it is possible, though unlikely, that the match is failing.)

Does xev state that the key being pressed is Meta_L?

KeyPress event, serial 41, synthetic NO, window 0x2e00001,
    root 0x2c8, subw 0x0, time 254086373, (150,121), root:(199,266),
    state 0x0, keycode 133 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

If that's not true, the patch isn't going to do anything because you don't have a Meta-anything being generated for the patch to pick up on.

Here, the effect of the patch is that both left-win and alt manifest as 'Alt' as far as keyboard shortcuts and the like go.

I am testing this on a Thinkpad T400 and a Logitech wireless keyboard.

With both systems xev indicates the Left Windows key is working and the xorg log indicates the 10-keyboard.conf file is being loaded. Same results as you posted.

My build log indicates the patch is being applied.

In mc, when I press Alt+H the history dialog appears. When I press Left_Win+H the letter h appears.

I disabled the konsole menu accelerators (patch from bug 1701) and that made no difference anyway.

I think the additional behavior of 'meta' should be enabled/disabled by an option checkbox.
Some users may want to have meta and alt doing different things, so they may later open a bug report against this change, if applied.

>I think the additional behavior of 'meta' should be enabled/disabled by an option checkbox.
Although I am unable to get this working correctly at my end, I agree with the suggestion. If we push the suggestion further, should users be able to define any key they want to assign as a meta key?

Moreso, should the GUI dialog in KControl->Keyboard Shortcuts->Modifier Keys be revised to support this feature for all apps rather than just Konsole? Just thinking out loud.... :-)

(In reply to Darrell from comment #10)
> >I think the additional behavior of 'meta' should be enabled/disabled by an option checkbox.
> Although I am unable to get this working correctly at my end, I agree with
> the suggestion. If we push the suggestion further, should users be able to
> define any key they want to assign as a meta key?

The actual Meta key binding is handled by the underlying system (not TDE); I don't know if anything other than the options already present would be supported by xev and friends.  At the very least I've never seen a configuration dialog in Gnome, etc. that would allow the user to select some random key as the Meta key.

> Moreso, should the GUI dialog in KControl->Keyboard Shortcuts->Modifier Keys
> be revised to support this feature for all apps rather than just Konsole?
> Just thinking out loud.... :-)

Which feature?  Passing the Meta key through?  That seems to be Konsole-specific.

From what I can gather this patch is simply allowing the Meta key to be used by an active command-line application inside Konsole (such as Emacs or vim)?  If so, I'll just push as-is.

(In reply to Timothy Pearson from comment #11)
Tim, please don't push as-is.
As I wrote in comment 9, it would be better to have an option to enable/disable the Meta key being used by an active command-line application inside Konsole.
Some users may like the enabled behaviour, but others may not. So the need for an option.

I will work on adding an option in Configure Konsole.

(In reply to Michele Calgaro from comment #12)
> (In reply to Timothy Pearson from comment #11)
> Tim, please don't push as-is.
> As I wrote in comment 9, it would be better to have an option to
> enable/disable the Meta key being used by an active command-line application
> inside Konsole.
> Some users may like the enabled behaviour, but others may not. So the need
> for an option.

OK.  I don't use the affected command-line applications so I am not the correct person to do any usability analysis of this feature.

I am temporarily setting this bug back to NEW because bug 2016 has a bigger priority for me at the moment. I will come back to this bug at a later stage.

Back to this bug :)

Nix,
I have been looking at this bug report to add a config option. I have got most of the code ready (both for Konsole and konsole_part), but I can't find a way to test it properly.
I also tried you patch "as is", but Meta_L doesn't seem to do anything special.
I have the left Win mapped as Meta_L, as repoerted by xev:

KeyPress event, serial 39, synthetic NO, window 0x3e00001,
    root 0xa1, subw 0x0, time 4383098, (183,641), root:(186,665),
    state 0x0, keycode 133 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

In Midnight Commander, is I press Meta_L+h, h is simply displayed.

What exactly happens on your system? Can you give a concrete example I can test on my computer and the expected output?

I like the idea of using the Meta as Alt key in the konsole_part, since usually Alt is used for activating the menu of the application that use the part (ex. Konqueror, Kate).

Nix, could you also let me know what settings you use in Konsole -> Settings -> Keyboard? Just in case ;-)

Created attachment 2040 [details]
tdebase patch

This patch adds an option to the Konsole -> Settings -> General page to handle the Meta key as Alt key. It also adds the same option in konsole_part (right click -> Settings -> Meta key as Alt key).
If enabled, the Meta key is treated as an Alt key.

Even though initially I didn't consider this function very useful, I have now found two good use case:
1) running MC in konsole_part, Alt+H is usually intercepted by the menu of the application incorporating the part. Using this option is a good alternative to Alt+H.
2) in Konsole, this option can be used in combination with the "Enable main menu accelerator keys" option. The key combinations (ex. Alt+H) broken by the second option can now be replaced by using the Meta.

This patch also updates the Konsole -> Settings -> General page docbook, since several options were missing.

Before I push it to GIT, please test and let me know if you find any problem. To test, you need to make sure that you have a Meta key (refer to previous comments for that).

Looks like there is something more to do.
When opening new applications (konsole, konqueror, kate) the patch works and the Meta key is handled as an Alt key.
But after rebooting the computer saving a session with those application already opened, the Meta key is not handled correctly in the restored windows.
I will need to look at this again, something is still missing.

Back on this bug again.

Created attachment 2056 [details]
updated patch

Nothing wrong with the original patch. Instead it seems there is a bug in Qt/TDE (or X) where the Meta button flag is not handled correctly on windows that are automatically restored after a reboot. The updated patch manually tracks the status of the Meta button and works correctly even after a reboot.

Description of the mentioned bug
--------------------------------

It seems that Qt/TDE (or X) do something strange when handling the Meta button in between sessions.
Normally Meta is handled correctly: for example on a new Konsole, the sequence Meta+h gives the following (B= and A= is the state of keyboard modifiers before and after the event).
<KeyPre> State: B=0x0000/A=0x0800 Key: 0x1022 (0,0)  -> Meta key pressed: 0x0800 is TQt::MetaButton
<KeyPre> State: B=0x0800/A=0x0800 Key: 0x0048 (1,104) -> h pressed
<KeyRel> State: B=0x0800/A=0x0800 Key: 0x0048 (0,0) -> h released
<KeyRel> State: B=0x0800/A=0x0000 Key: 0x1022 (0,0) -> Meta released

On the same Konsole, automatically restored after a computer reboot we get:
<KeyPre> State: B=0x0000/A=0x0800 Key: 0x1022 (0,0)
<KeyPre> State: B=0x0000/A=0x0000 Key: 0x0048 (1,104)
<KeyRel> State: B=0x0000/A=0x0000 Key: 0x0048 (0,0)
<KeyRel> State: B=0x0000/A=0x0800 Key: 0x1022 (0,0)

Notice how in the second case the state of Meta button is "lost" when h is pressed (B=0x0000 instead of 0x08000) and how the state after the release of Meta is 0x0800 which corresponds to Meta being pressed. Shift and Ctrl instead works fine.

Just for reference, the widget used in Konsole (TEWidget) uses an eventFilter function to handle events, but even moving the code to standard key event methods doesn't change the behavior.

Created attachment 2057 [details]
improved patch

Improved patch which also handle the case where the terminal emulation loses the focus with the Meta key pressed and regain the focus with the Meta key not pressed.

(In reply to Michele Calgaro from comment #24)
> Created attachment 2057 [details]
> improved patch
> 
> Improved patch which also handle the case where the terminal emulation loses
> the focus with the Meta key pressed and regain the focus with the Meta key
> not pressed.

Has this received any testing?  I'd like to push if it's ready to go.

Thanks!

> Has this received any testing?  I'd like to push if it's ready to go.
I have been using the patch for several weeks so far without problems, so if we want, I could push to GIT.
Nevertheless in addition to the problem explain in comment 23, I noticed another little strange thing. In MC, using Alt+p+p+p+p... allows to move back in the list of commands one by one. Using Meta+p+p+p+p.... that doesn't happen, i.e. the first time is works correctly but the following "p"s just comes up as "p" in the command line at the bottom. So we have to use Meta+p, then again Meta+p, then again Meta+p and so on.
I reckon the root cause is the same as the problem of comment 23 (the Meta key state being inconsistent).
Before pushing I would like to make sure of that. Then we can push, close this bug and open a bug again tqt3 and the meta key.
As you know, recently I have been pretty busy and had little time for TDE. I should have some more time after the coming week, at least in the evenings and weekends.

Sure thing.  If you can give me a simple reproducible test case for the TQt3 malfunction I can try to trace the problem into the bowels of TQt3.  Unfortunately being able to replicate the problem in Konsole is not a simple test case at all--ideally I'd like a snippet of code (e.g. as would be used in a TQKeyEvent) that I can insert into a debug program for analysis, along with a clearly defined proper behaviour and a clear definition of the observed malfunction behaviour.

I don't normally ask for this kind of information, but I have never used the Meta key and the likelihood of me just screwing up my system configuration and not encountering the bug (or getting hung up on rabbit trails) is very high as a result.

Thanks!

Hi Tim,
I will see (during the week) if I can come up with a code snippet that can replicate the problem, but I expect that to be quite difficult.
First, the problem comes up *after* exiting and reentering in TDE, for example after a computer reboot (see comment 23 for a detailed example).
Second, the problem is that it is the sequence of TQKeyEvent generated when pressing Meta on the keyboard that is wrong.

An easier way would be to temporary modify the keyboard mapping (through xmodmap) for testing: it's a temporary change and even better you could do that in a VM testing environment, so no risk to mess up your system keyboard config. I can provide a xmodmap setting file which maps Ctrl to Meta if you want. After applying the patch, just follow closely comment 23 for a reproducible test sequence.

Not sure yet if the problem is in Tqt3 or in the session management code.

(In reply to Michele Calgaro from comment #28)
> Hi Tim,
> I will see (during the week) if I can come up with a code snippet that can
> replicate the problem, but I expect that to be quite difficult.
> First, the problem comes up *after* exiting and reentering in TDE, for
> example after a computer reboot (see comment 23 for a detailed example).
> Second, the problem is that it is the sequence of TQKeyEvent generated when
> pressing Meta on the keyboard that is wrong.
> 
> An easier way would be to temporary modify the keyboard mapping (through
> xmodmap) for testing: it's a temporary change and even better you could do
> that in a VM testing environment, so no risk to mess up your system keyboard
> config. I can provide a xmodmap setting file which maps Ctrl to Meta if you
> want. After applying the patch, just follow closely comment 23 for a
> reproducible test sequence.

OK, sounds good.  I have used testing VMs quite often; I have not however used the Meta key so I don't know exactly what I'm looking at. :-)

> Not sure yet if the problem is in Tqt3 or in the session management code.

This is why I wanted a reproducible test case with a simple debug application.  Technically, the problem could even be in Konsole and/or its interaction with the rest of TDE, but tracing it there will be quite difficult.

For information: This patch has long been added to my R14 preliminary-stable-builds. So all who use them have this patch applied. Unfortunately, I have not tested the problems mentioned by Michele.

Created attachment 2086 [details]
xmodmap setting file

In my previous comment I incorrectly mentioned Ctrl to Meta mapping. I meant to say CapsLock to Meta. The attached file does the trick. To use it run "xmodmap PATH/TO/FILE/Xmodmap" from console. If you have different keycodes, you may have to modify line 12 and 13. To check that it worked well, use xev and check the code keys. Pressing and releasing CapsLock should give something like:

KeyPress event, serial 39, synthetic NO, window 0x4800001,
    root 0xa1, subw 0x0, time 48701022, (605,259), root:(608,283),
    state 0x0, keycode 66 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x4800001,
    root 0xa1, subw 0x0, time 48701089, (605,259), root:(608,283),
    state 0x20, keycode 66 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False


Then follow comment 23 for the reproducible test case. Let me know if you need more info on testing.

I have pushed the patch since I have been using it for a long time. Nevertheless the problem explained in the above comments remains open.

The question now is what to do with this bug.
1) close the bug and file a new bug vs. QT or TDE session manager related to the problem
2) leave the bug open and remove the blocking dependency to bug 2014, since the original intent to add support for "meta as alt key" has been achieved.

I am in favor of the second option, so the details of the problems are not dispersed in multiple bugs. What do you think?

(In reply to Michele Calgaro from comment #32)
> I have pushed the patch since I have been using it for a long time.
> Nevertheless the problem explained in the above comments remains open.
> 
> The question now is what to do with this bug.
> 1) close the bug and file a new bug vs. QT or TDE session manager related to
> the problem
> 2) leave the bug open and remove the blocking dependency to bug 2014, since
> the original intent to add support for "meta as alt key" has been achieved.
> 
> I am in favor of the second option, so the details of the problems are not
> dispersed in multiple bugs. What do you think?

Agreed; removing from R14 block list, renaming title, and resetting to NEW.

Not sure what changed and when, but the problem with Meta not working in existing consoles seems to have disappear. I have being monitoring this for a while and haven't noticed any unexpected behavior.
Therefore I am closing the bug.