Bug 2535 - Navigation layer of Neo-layout broken in MDs trunk
Summary: Navigation layer of Neo-layout broken in MDs trunk
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: Trunk
Hardware: PC Linux
: Low normal
Target Milestone: ---
Assignee: Mike Krüger
Depends on:
Reported: 2011-12-16 03:15 UTC by knittl89+bugs
Modified: 2015-11-16 06:09 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description knittl89+bugs 2011-12-16 03:15:56 UTC
It's not possible to use the navigation layer[1] functionality of the Neo layout in the text editor of a current MonoDevelop build. It works fine in other panes, such as "project explorer".

The commit that breaks compatibility with Neo is c827464abb033569ec9f346482aa3c2b6f2c06af "[TextEditor] Better mapping of keyboard input", which comes after a bunch of "gtk hacks/workaround unification/simplification" commits.

I was unable to revert this single commit due to conflicts with the current master version. I'd be happy to test any patch that may fix this issue. I guess the problem is related to handling of keyboard modifiers (Neo has more modifiers than an average keyboard: shift, mod3, mod4 (activates the navigation layer) and a combination of these.

[1]: http://neo-layout.org/grafik/tastatur3d/hauptfeld/tastatur_neo_Ebene4.png
Comment 1 Mike Krüger 2012-01-03 08:53:47 UTC
Ah another neo user ^^
(I've to admit that I don't use the navigation layer, otherwise I would've complained eariler)
Comment 2 Marenz 2012-02-03 13:39:28 UTC
I use this feature like every .. minute. As in, all the time. I don't use the normal arrow keys at all, so this hits me very hard.

Would be really nice to see a fix :)

I tried it in version 2.8.2 where it still worked. But what did not work, even in that older version, was selecting things with shift and the arrow keys of the neo navigation layer. Maybe, if you fix this, this could be taken care of as well?

Monodevelop seems to be a pretty neat alternative to the eclipse monster that terrorizes us every day!

Comment 3 Marenz 2012-02-06 09:14:28 UTC
I take back what I said, the shift-select _does_ work in the old version. Must have been another problem, maybe old neo version in the testing system.
Comment 4 Mike Krüger 2012-04-15 03:15:26 UTC
Closing that one - it's an upstream bug. You can read about it in the neo faq:


It's very annoying - we can't really fix neo atm :( - but if someone could fix that in GTK it would be awesome.

(That's why I work on linux and mac)
Comment 5 knittl89+bugs 2012-04-15 05:01:18 UTC
Hi Mike,

as far as I understand, this is not really WONTFIX. The FAQ you linked from our Neo page talks specifically about the kbdneo2 driver (native Windows driver). I  use MonoDevelop exclusively on Linux with the xkbmap driver. Other GTK+-applications work fine with all 6 layers of Neo (e.g. Pidgin, gedit).

Only part of layer 4 is missing in MonoDevelop, the navigation block on the left hand side – the integrated numpad on the right hand works flawlessly.

As noted in the initial bug report, it worked in MonoDevelop before commit c827464abb033569ec9f346482aa3c2b6f2c06af "[TextEditor] Better mapping of
keyboard input"

I will re-open this bug, since auto-completion (for instance) is a PITA without my beloved layer 4 (too much hand moving), it worked before, works in other GTK+ apps and does not seem to be only in GTK+
Comment 6 Mike Krüger 2012-04-15 05:04:49 UTC
Ah k - then you're right, I thought you were running on windows :/ for some reason.
Comment 7 Mike Krüger 2012-04-15 05:30:29 UTC
fixed in master
I'm the only neo layout user, therefore I think I should fix that :)

bwt. nice - I never used layer 4
Comment 8 knittl89+bugs 2012-04-15 05:38:13 UTC
many many thanks! I can confirm that the fix works (at least on Linux)

Now I can be productive again :)
Comment 9 Mike Krüger 2012-04-15 05:46:59 UTC
I'm a neo layout user, but layer 4 was unknown to me.

Somehow I thought you were referring to windows - was my fault, I should've read more carefully.

I work often on mac there layer 4+6 don't work there - therefore it's a linux only fix (on windows neo layout is really broken for GTK :( ).
Comment 10 Mikayla Hutchinson [MSFT] 2012-04-17 10:27:07 UTC
That fix looks like a hack. We should make the text editor check all the composed accel variants, instead of having it use different variants on different platforms.
Comment 11 Mike Krüger 2012-04-17 10:31:09 UTC
Hm, I think the whole input system looks like a hack right now.
The think is that layer 4 is broken on mac anyways. The thing is you can't make a choice on the variants - all variants given it the case are valid.

Which ones to take ?

btw. why do we this decomposing ? It's just something that's broken in gtk - the keys received as application should alway be correct.
Comment 12 Mikayla Hutchinson [MSFT] 2012-04-17 10:56:13 UTC
Exactly, *all* variants are valid. That's why we decompose and recompose, to see the ways that the key input could legitimately be interpreted.

When checking whether a key/shortcut matches the input, it should be checked against *all* composition variants, instead of assuming one is "correct".
Comment 13 Mike Krüger 2012-04-17 11:59:34 UTC
it assumed the first one was correct - where in the neo case the last one was correct. I don't know how should this work ?

in one case you insert l in the other it's caret up - which one is the right thing to do ?
Comment 14 Mikayla Hutchinson [MSFT] 2012-04-17 12:55:01 UTC
It assumed the first decomposition was correct because that matched the old behaviour before I added the multiple decompositions in the keyboard mapping method. I just didn't port the text editor to handle all the decompositions.

Dunno why it inserts l. I assume l+Modifiers.None isn't actually one of the decompositions. My guess would be that it fails to find a command that matches the key+modifier, and falls back to the "unicode value" - which is the fully composed key - regardless of unconsumed modifiers.
Comment 15 Mike Krüger 2012-04-17 15:33:11 UTC
the value in the neo layout case is:

I hit modfier key + 'l'
Input event:
HardwareKeyCode: 26 (the one from 'l')
Key:      Up (nothing to do with 'l')
Modifier: Mod3Mask
Group:    0

The decomposed keys are:

[KeyboardShortcut: Key=l, Modifier=None]
[KeyboardShortcut: Key=Up, Modifier=None]

Where the 'up' thing is correct - when I've this output it's not possible to make a sane choice which is the right one - you took the 1st - I took the last, but both approaches are wrong :(.

btw. I still do not know in which cases the keyboard input processing is needed.
Comment 16 Mikayla Hutchinson [MSFT] 2012-04-17 16:12:23 UTC
OK, the decomposition in MD is buggy, that should be decomposed to:
[KeyboardShortcut: Key=l, Modifier=Mod3]
[KeyboardShortcut: Key=Up, Modifier=None]
Comment 18 Mikayla Hutchinson [MSFT] 2012-04-17 18:49:44 UTC
That looks fine, though I still need to fix the missing mod3 modifier.
Comment 19 Mike Krüger 2015-11-16 06:09:28 UTC
Closing (works for me with 6.0/linux)