Hi Jordi, thank you for your explanations.
I added a debug output and switched to Greek. Debug [Main]: QKeyEvent(KeyPress, 1000021, 4000000, """", false, 1) nativeScanCode: 25 Debug [Main]: QKeyEvent(KeyPress, 57, 4000000, """", false, 1) nativeScanCode: 19 Debug [Main]: keyboard press: "Ctrl+W" Debug [Main]: QKeyEvent(KeyPress, 3a3, 0, ""σ"", false, 2) nativeScanCode: 27 Debug [Main]: keyboard press: "Σ" Debug [Main]: QKeyEvent(KeyPress, 1000021, 4000000, """", false, 1) nativeScanCode: 25 Debug [Main]: QKeyEvent(KeyPress, 53, 4000000, """", false, 1) nativeScanCode: 27 Debug [Main]: keyboard press: "Ctrl+S" Debug [Main]: QKeyEvent(KeyPress, 3a3, 2000000, ""Σ"", false, 2) nativeScanCode: 27 Debug [Main]: keyboard press: "Shift+Σ" Debug [Main]: QKeyEvent(KeyPress, 3a3, 2000000, ""Σ"", false, 2) nativeScanCode: 19 Debug [Main]: keyboard press: "Shift+Σ" I have no idea what the scan codes are, but at least it would allows us to special case the Greek issue in Linux and Windows. Or we can just ignore them and live with the Greek limitations. So the issue is that we have only this information nothing more noting less. > > It looks like that there is a problem that that you translate it to > ConfigValueKbd() and the whole mapping is based on it. > > > I think I am not entirely sure what you mean by that, could you clarify? > The KeyboardEventFilter::getKeySeq() acts uses the key() part which is not significant enough. I think you need to look at text() for the unmodified and shifted keys and keep using key() for other modifiers. > > /How about change the internal () to a modifiers + > scancode class. / > > > I have mixed feelings about that. We would have to translate on each > key-press instead of translating all mappings as a whole when loading > the preset. Hah yes, that's a good point. (Be aware that sometimes timing measurements have surprising results. Mixxx has some nice benchmark facilities. ScopedTimer() ... ) How about keeping the ConfigValueKbd(), but use modifiers + text() when text() contains a valid character if not, fall back to the current modifiers + key() version? This would allow to at least distinguish the Greek unmodified keys. I would simply ignore the Shift case. > ------------------------------------------------------------------------ > From: dasch...@mixxx.org > Date: Wed, 10 Aug 2016 16:29:03 +0200 > Subject: Re: [Mixxx-devel] FW: Multiple language keyboard mapping > To: jordi...@hotmail.com > CC: mixxx-devel@lists.sourceforge.net > > Hi Jordi, > > > I have probably not entirely understand the issue, correct me If I am wrong: > > Is this your key receiving function? > https://github.com/mixxxdj/mixxx/compare/master...Tomasito665:FEAT_multiLangKbdPresets#diff-a037f3788ec89e84fd73ebdaac889681R24 > > http://doc.qt.io/qt-4.8/qkeyevent.html > > QKeyEvent should contain all info you need to translate the every key > press into a lookup index of layouts.h > It looks like that there is a problem that that you translate it to > ConfigValueKbd() and the whole mapping is based on it. > > How about change the internal ConfigValueKbd() to a modifiers + scancode > class. > This way you shift the issue described above to the mapping file. > A Greek user is very familiar in switching his keyboard between a Latin > and a Greek layout. > So he should be able to map Mixxx using English. This is than translated > into an inner modifiers + scancode representation. > The commingling keys should also be able to translate to this format. > I am not sure how usefull QKeyEvent::nativeScanCode() is though. > > Could this be a solution? > Do I miss something? > > > > > > > > > > > > > > > 2016-08-08 15:44 GMT+02:00 Jordi Ortolá Ankum <jordi...@hotmail.com > <mailto:jordi...@hotmail.com>>: > > Hi everyone, > > I have some concerns about this approach that we have been thinking > of and brainstorming on. Because although we try to cover each > keyboard layout, there are still some unseen sinkholes here and > there. One of these being the fact that some keyboard layouts have > multiple keys holding the same character. > > Greek layout problem > For example, the Greek keyboard layout (el_GR), has three characters > for the letter 'sigma': upper-case (Σ), lower-case (σ) and > lower-case in word-final position (ς). The two former ones are typed > on the Greek layout with the S key, and the latter one is typed with > the W key/*/. But here is the deal, though. QKeySequence() > uppercases every given key character and does the comparisons with > upper-case characters. So, that makes it impossible to distinguish > the key W from the key S (which both make upper-case 'sigma'), and > thus makes those keys unusable. > > With the current approach, we would make an exception for the Greek > layout in the keyboard preset XML file and would just make sure that > those two keys are not used for anything (and treat them as dead > keys in layouts.h?). But wouldn't it be strange for a Greek user to > not be able to use the keys W and S? > > Solution using virtual key codes? > I am thinking that we could maybe not map on QKeySequences, but > rather map on virtual key code combinations. I want to think that > it's possible to translate the current key sequences from the preset > XML to virtual key codes when loading the preset, but I am not sure > if it is. When loading "Shift+A" on Linux, it would translate to > "Shift+0x61", for example (I don't know if virtual key codes are > platform dependent or not). > > Solution using QKeyEvent::text()? > Another solution is to use QKeyEvent::text(), that returns a Unicode > text (one character, usually) that the key generated. This returns > 'w' when pressed without shift and 'W' when pressed with Shift. > Also, it distinguishes between all sigmas. The downside, though, is > that it will only work for non-shifted and shifted characters, but > not for key sequences with Ctrl or Alt. This is because it's not > guaranteed that the two latter modifiers are holding a valid Unicode > character. For example: > > A => 'a' > Shift+A => 'A' > Ctrl+A => ? > Ctrl+Shift+A => ? > > And also, QKeyEvent::text() returns an empty string for function > keys and arrow keys, but we could then fallback on > QKeySequence::toString(), which will return our familiar "Left", > "Right", "F1", "F2, etc... QStrings. > > Just use QKeyEvent::text() when possible? > I think that not being able to use Ctrl and Ctrl+Shift modifiers is > a no-go, which would discard the QKeyEvent::text() solution. > However, we could use it just for no modifier and shift and fallback > for Ctrl+Shift and Ctrl modifiers to QKeySequence::text(). This way > we could map to all keys, with all modifiers, on all keyboard > layouts except for Ctrl+W, Ctrl+S, Ctrl+Shift+W and Ctrl+Shift+S on > the Greek layout. > > I think that the last solution is the less painful one. Any thoughts > on this? > > (By the way, everything is working now on my branch: > FEAT_multiLangKbdPresets. It's also possible to change the keyboard > layout in your OS, reload the keyboard preset, and it translates the > key sequences without having to restart Mixxx :) The thing is that > both keys W and S are triggering both actions bound to these keys on > the Greek layout.) > > Kind regards, > > Jordi > > / > / > /* I refer to the keys W and S as the keys that are holding the > letters W and S on a US keyboard layout./ > > > ------------------------------------------------------------------------ > From: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Fri, 22 Jul 2016 09:12:33 +0200 > Subject: Re: [Mixxx-devel] FW: Multiple language keyboard mapping > To: jordi...@hotmail.com <mailto:jordi...@hotmail.com> > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > > Hi Jordi, > > looks nice! Thank you. > > Daniel > > > > > > > > 2016-07-22 0:52 GMT+02:00 Jordi Ortolá Ankum <jordi...@hotmail.com > <mailto:jordi...@hotmail.com>>: > > I made some little tweaks. The tool now produces this: > http://pastebin.com/QJ7sJaMA > > What do you think? > > - Jordi > > > ------------------------------------------------------------------------ > From: jordi...@hotmail.com <mailto:jordi...@hotmail.com> > To: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Wed, 20 Jul 2016 17:43:25 +0200 > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > Subject: Re: [Mixxx-devel] FW: Multiple language keyboard mapping > > Hi Daniel, > > Sure, we could make a KbdKeyChar struct storing a char16_t and a > bool telling the "deadness" of the key. > > struct KbdKeyChar { > KbdKeyChar(char16_t chr) : character(chr) {} > > char16_t character; > bool isDeadKey; > }; > > KbdKeyChar de_DE[48][2] = { > {{'^', true}, {'°'}}, {{'1'}, {'!'}}, {{'2'}, {'"'}} // etc > }; > > Something like this? I am not really happy with the KbdKeyChar > name though, any ideas? > > - Jordi > > > > > ------------------------------------------------------------------------ > Subject: Re: [Mixxx-devel] FW: Multiple language keyboard mapping > To: jordi...@hotmail.com <mailto:jordi...@hotmail.com> > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > From: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Tue, 19 Jul 2016 22:59:14 +0200 > > Hi Jordi, > > since memory is cheap these days, why not add an extra field for > dead keys? > > > > Am 19.07.2016 um 22:33 schrieb Jordi Ortolá Ankum: > > Hi Daniel, > > I have been thinking about how to store dead-key info in a > char16_t. It's not an integer, like a normal char, and > therefore there is no such thing as an unsigned or a signed > char16_t. So, we can't do: negative char = dead keys. > > The only option I see for now is storing them in int16_t, > but a major drawback is that it's a bit cryptic: > static const int16_t de_DE[48][2] = {{0x31,0x21}, > {0x32,0x40}, etc... } > > The good thing is that we will be able to store dead keys by > making the integer negative. Also, we can do: > QChar x = de_DE[0][0] ... > > ... which will work because of QChar::QChar(int code) being > an implicit constructor. > > But still, it's not really readable. Any ideas? > > Best regards, > Jordi > > > ------------------------------------------------------------------------ > Subject: Re: [Mixxx-devel] FW: Multiple language keyboard > mapping > To: jordi...@hotmail.com <mailto:jordi...@hotmail.com> > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > From: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Tue, 19 Jul 2016 00:32:20 +0200 > > Hi Jordi, > > (cc-ing lost mixxx-devel) > > that sounds good. > > The L" " is the wide string literal. > http://en.cppreference.com/w/cpp/language/string_literal > <http://en.cppreference.com/w/cpp/language/string_literal> > > I have just noticed that this is only correct on windows > where wchar_t has 16 bit > On Linux it has 32 bit, but the storage type of QString and > QChar is 16 bit on all targets. > > Luckily we are on C++11 so we need actually: > > static const char16_t de_DE[47][2] = {|u"1!", ...| > > Kind regards, > > Daniel > > > > Am 18.07.2016 um 18:33 schrieb Jordi Ortolá Ankum: > > Hi Daniel, > > The key left to the 1, (the <TLDE> key according to the > Xkb keycode names) is not missing, but it's not in the > right place. > > I see that I am missing the \| key (or #', for German > layout), next to Enter. I added that one. That brings it > up to 48 keys. But still, 2 missing. > > From the comments: > > The last three entries in the tables are respectively the > 102nd > key on 102/105/106 key keyboards, the extra key on > Brazilian and > Japanese keyboards and the Yen key on Japanese keyboards. > The layout-switching keys on Japanese and Korean keyboards > are > dealt with elsewhere. > > I got the 102nd key (\| on US, <> on DE), but the > missing keys are the two Japanese ones. I don't think we > need those, because since the Japanese layout is the > only one that supports those keys, we couldn't translate > from or to this keys from other layouts. What do you think? > > And what does the L mean in your example? > > PS: I see that you left out the mixxx dev group in CC, > should we keep this discussion here or add them in again? > PS: I would love to test your natural scratch, but I am > not a DJ myself neither so.. :) > > > > ------------------------------------------------------------------------ > From: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Mon, 18 Jul 2016 15:20:19 +0200 > Subject: Re: [Mixxx-devel] FW: Multiple language > keyboard mapping > To: jordi...@hotmail.com <mailto:jordi...@hotmail.com> > > Hi Jordi, > > cool, you have adopted the VirtualBox approach. > > They use 50 keys: > > https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-tables.h#L37 > > <https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-tables.h#L37> > > For example is the key left to "1" missing. > > I would write c++ code that can be instantly used in Mixxx. > Probably something like: > > static const wchar_tde_DE[47][2] = {{|L'1', L'!'}, ... > > | > |or > | > static const wchar_tde_DE[47][2] = {|L"1!", ... > > | > Kind regards, > > Daniel > > 2016-07-18 14:22 GMT+02:00 Jordi Ortolá Ankum > <jordi...@hotmail.com <mailto:jordi...@hotmail.com>>: > > Hi Daniel, > > I made a little C++ program that gets the current > Xkb keyboard map from the X server and generates a > file that is > similar to keyboard-layouts.h in VBoxKeyboard. Here > is the output, when loading just four layouts: > English (US), German, French and Russian. > > http://pastebin.com/G0cSx0qi > > It's a two dimensional signed char array, that holds > the character for every key that is interesting to > us in it's normal and shifted state. If the > character is not within the ASCII range, it puts > down a unicode character literal, just to be safe. > > Dead keys are indicated by changing the char from > positive to negative (that's why I explicitly made > the chars signed). For example, a dead key holding > an combining acute accent will be written down as: > -'\u0301'. If that key was not a dead key, it would > be just '\u0301'. > > What do you think? > (I kind of want some approval before I start to load > all 520 layouts :) ) > > - Jordi > > > ------------------------------------------------------------------------ > From: jordi...@hotmail.com <mailto:jordi...@hotmail.com> > To: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Fri, 15 Jul 2016 00:26:43 +0200 > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > > Subject: Re: [Mixxx-devel] FW: Multiple language > keyboard mapping > > Hey Daniel, > > Great! Yeah, after reading back and forth over > that comment I was just about to share my progress. > Though, I didn't get to the "R -> \x52" part, nice > that you found it! > > I will see if I can rewrite or maybe regenerate > these tables, but without truncating. Because now we > can't tell if 'e1' is: > '0x00e1 -> á' > or '0x07e1 -> α' > or '0x05e1 -> ف' > etc... > > Anyway, I think we are well on the way. I will let > you know as soon as I got something worth sharing :) > > Kind regards, > > Jordi > > > > > > > > ------------------------------------------------------------------------ > Subject: Re: [Mixxx-devel] FW: Multiple language > keyboard mapping > To: jordi...@hotmail.com <mailto:jordi...@hotmail.com> > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > From: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Thu, 14 Jul 2016 23:27:16 +0200 > > Hi Jordi, > > I think I got it. > > From the comments: > > > Note that contrary to the original tables in the > Wine source code, > > these tables simply contain the X keysym values > truncated to the > > least significant byte > > \xe1 and \xc1 are > > 0x07e1 U03b1 . # Greek_alpha > 0x07c1 U0391 . # Greek_ALPHA > > R -> \x52 > > 0xfe52 U0302 f # dead_circumflex > > https://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt > <https://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt> > > I have searched the Wine source, but the only thing > I have found is this, which looks even more useless. > > https://github.com/wine-mirror/wine/blob/47cf3fe36d4f5a2f83c0d48ee763c256cd6010c5/dlls/winex11.drv/keyboard.c > > <https://github.com/wine-mirror/wine/blob/47cf3fe36d4f5a2f83c0d48ee763c256cd6010c5/dlls/winex11.drv/keyboard.c> > > I think you actually need a lookup for QChar. Maybe > you find a way to rewrite these tables for it. > > Kind regards, > > Daniel > > > > Am 14.07.2016 um 18:52 schrieb Jordi Ortolá Ankum: > > Hi Daniel, > > Wow, that file pretty much covers up the entire > layouts palette. However, I don't quite > understand their encoding of dead keys yet. All > dead keys are encoded with capital letters, > that's as far as I have gotten. But the reason > why the capital letter P stands for dead key `, > and the S stands for dead key ~, is not so clear > to me: > > https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-layouts.h#L74 > > <https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-layouts.h#L74> > > Also, I don't understand how they encoded the > Greek keyboard layout. For example; what should > be the greek small and capital letter alpha, is > encoded as \xe1 and \xc1, two codes which I > can't really find information on. > > https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-layouts.h#L1075 > > <https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-layouts.h#L1075> > > Any idea what their encoding is? > > If we manage to make Mixxx successfully read > this file, I think that this is an excellent > choice, because it's completeness and C being > faster to iterate through than XML :) > > > -Jordi > > > > > > ------------------------------------------------------------------------ > From: dasch...@mixxx.org <mailto:dasch...@mixxx.org> > Date: Thu, 14 Jul 2016 16:10:07 +0200 > Subject: Re: [Mixxx-devel] FW: Multiple language > keyboard mapping > To: jordi...@hotmail.com > <mailto:jordi...@hotmail.com> > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > > Hi Jordi, > > that sounds good. Renaming it back to scancode > is also a good idea. > > libgnomekbd uses XkbGetKeyboard: > > https://github.com/GNOME/libgnomekbd/blob/43cd1bdd63682f521c74c0259c3357fb4953dc0f/libgnomekbd/gkbd-keyboard-drawing.c#L2043 > > <https://github.com/GNOME/libgnomekbd/blob/43cd1bdd63682f521c74c0259c3357fb4953dc0f/libgnomekbd/gkbd-keyboard-drawing.c#L2043> > > Here is the source: > > https://people.freedesktop.org/~jeremyhu/analyzer/tifa-linux32/20120705-2000/libX11/report-aneU1a.html > > <https://people.freedesktop.org/~jeremyhu/analyzer/tifa-linux32/20120705-2000/libX11/report-aneU1a.html> > > However, it looks too complicated to me :-( > > I think I have found something suitable here: > > https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-layouts.h > > <https://github.com/pombredanne/VirtualBox-OSE/blob/9a4e2bebc55506b36b6e535e4326a875727fb3aa/src/VBox/Frontends/Common/VBoxKeyboard/keyboard-layouts.h> > > Hope that helps, > > Daniel > > > > 2016-07-14 14:08 GMT+02:00 Jordi Ortolá Ankum > <jordi...@hotmail.com > <mailto:jordi...@hotmail.com>>: > > Hi Daniel, > > The layouts XML file is something I came up > with to store keyboard layout information. > If we would want to add support for an extra > keyboard layout, we would just need to add a > new layout to the XML file, instead of > having to update all keyboard presets. > (which can be done with the little editor I > made) > > The Key IDs are based on scancodes. > Actually, I first referred to them as > scancodes, both in documentation and in > code. But I couldn't find any solid > documentation on this. For example, > sometimes the key 'Q' (on QWERTY) is given > scancode 17, and sometimes scancode 16. To > avoid confusion I decided to change the > naming to "Key ID". However, I just did some > more googling and it turns out that there > are three different code sets: > > https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#scancodesets > > <https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#scancodesets> > > But only one happens to be the default > codeset, which my key ID numbering scheme is > practically a clone of: > > https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html > > <https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html> > > Now that we have this link, the Key ID > system would only need some minor tweaks to > meet this codeset specification. If so, I > could rename it back to scancodes. > > Oh, that's funny. I was actually inspired by > this 'gkbd-keyboard-display', but I didn't > know the name. I just opened it by clicking > on the keyboard layout icon on the Ubuntu > taskbar and clicking on "Keyboard Layout > Chart", which executes > 'gbd-keyboard-display' showing the current > keyboard layout. > > Where did you find about XKBGetByName? I > have been looking around on the libgnomekbd > <https://github.com/GNOME/libgnomekbd> repo, > but can't really find it. > I will be doing some more research on this. > It would be awesome if we can just use their > method, since it's been proven to work. > > Kind regards, > Jordi > > > > > ------------------------------------------------------------------------ > To: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > From: dasch...@mixxx.org > <mailto:dasch...@mixxx.org> > Date: Wed, 13 Jul 2016 21:55:59 +0200 > Subject: Re: [Mixxx-devel] FW: Multiple > language keyboard mapping > > > Hi Jordi, > > nice concept. > > Here some questions: > > Were does the "Layouts XML file" and the Key > IDs come from? > Did you consider to use the USB keyboard > scancodes or any other established system? > I am just a little afraid that your number > schema has some limitations, we are not > aware yet. > > Do you know "gkbd-keyboard-display" It does > the translation already, unfortunately it uses > X11 XKBGetByName which is not instantly > available on Windows. > > Do you know how X11 did the translation? > Maybe there is a library that can be used on > Windows as well to support the whole world > at once. > > > Kind regards, > > Daniel > > > > > > Am 13.07.2016 um 00:26 schrieb Jordi Ortolá > Ankum: > > > How about this. > * Store the mapped key along with > it's keyboard layout. > * Allow to add additional keys for > other layouts. > > > It's done! I made a keyboard layout > format, which will be used to store > keyboard layouts in an XML file so that > Mixxx can later translate key sequences > from one keyboard layout to another. I > made a little tool, with a simple GUI to > easily add and remove layouts to the XML > file. > > Also, the kbdcfg_to_kbdxml convertion > script has now a GUI. It is now capable > of transforming multiple *.kbd.cfg files > to just one *.kbd.xml file. It is also > given a layouts XML file (made with the > layouts editor tool) so that it knows > which key sequences to add and which > ones to leave out. > > I have made a detailed blog post > explaining everything :) > > > https://gsoc-mixxx-keymappinggui.blogspot.com.es/2016/07/keyboard-layouts.html > > <https://gsoc-mixxx-keymappinggui.blogspot.com.es/2016/07/keyboard-layouts.html> > > I am curious to know what you think! > > Kind regards, > Jordi > > > > > ------------------------------------------------------------------------ > From: ferranpujolcam...@gmail.com > <mailto:ferranpujolcam...@gmail.com> > Date: Sat, 25 Jun 2016 23:43:28 +0200 > Subject: Re: [Mixxx-devel] Multiple > language keyboard mapping > To: jordi...@hotmail.com > <mailto:jordi...@hotmail.com> > CC: mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > > (Sorry about my previous message, I > misunderstood what was going on). > > Maybe this key translation thing is a > little bit overcomplicated? Isn't it > better to just let the mapping creator > do the job? If a mapping does not > explicitly define shortcuts for a > layout, just don't do nothing. It is > more work for the mapping creator to > support all layouts, but it is simpler > to understand. > > 2016-06-25 20:20 GMT+02:00 Jordi Ortolá > Ankum <jordi...@hotmail.com > <mailto:jordi...@hotmail.com>>: > > Oh, dead keys. Of course.. > > Storing a mapped key, alongside with > it's keyboard layout seems to me > like a good plan. Also, overloading > a key sequence to target a specific > keyboard layout seems great to me, > especially for dead keys. > > If I understand you correctly, for > the XML it would be like this, right? > > On a de_DE keyboard layout, this > will be translated to 'z', because > of the z and y being switched for > German keyboards. > <keyseq lang="en_US">y</keyseq> > > In this case, on a de_DE keyboard > layout, it will go and find a > "de_DE" keyseq. So, no need for > translating. > <keyseq lang="en_US">`</keyseq> > <keyseq lang="de_DE">q</keyseq> > > But what if a user opens the > keymapping GUI (when the GUI is > done) and assigns an action to a key > that is not a dead key on his > keyboard layout, but is on an other > keyboard layout? I think that in > that case, we should warn the user: > "Warning: the pressed shortcut > combination: `, will not work for > keyboard layouts: de_DE". > > Any other thoughts on this? If not, > I think I can begin with the > implementation :-) > > Best, > Jordi > > > ------------------------------------------------------------------------ > Date: Sat, 25 Jun 2016 15:09:25 +0200 > Subject: RE: [Mixxx-devel] Multiple > language keyboard mapping > From: dasch...@mixxx.org > <mailto:dasch...@mixxx.org> > To: jordi...@hotmail.com > <mailto:jordi...@hotmail.com> > CC: > mixxx-devel@lists.sourceforge.net > > <mailto:mixxx-devel@lists.sourceforge.net>; > bzk0...@aol.com <mailto:bzk0...@aol.com> > > > Cool, it sounds like we are getting > close. > > Unfortunately a pure position > depended papping will not work, > because of dead keys. On a German > keyboard for instance there are some > keys like the "ˆ" which are stored > inside the OS until the next key is > pressed. They are transfered as a > complete character "â" in case of a > consecutive "a". > > How about this. > * Store the mapped key along with > it's keyboard layout. > * Allow to add additional keys for > other layouts. > > If a key event arrives and there is > a mapping for the key and it's > layout, use it. > If not, translate the key back to > the position and forth to the > primary keyboard layout, used to > create the mapping. > > For example: The user selects the > default en-US mapping. If he > switches to a de-DE keyboard. All > keys are translated to en-US, Y > becomes Z. We are able to move > mappings on dead keys to other > locations by adding dedicated de-DE > keys to the mapping. This is > required for the en-US "’" key which > is the de-DE dead key "ˆ". > > What do you think about it? > > Am 25.06.2016 1:50 nachm. schrieb > "Jordi Ortolá Ankum" > <jordi...@hotmail.com > <mailto:jordi...@hotmail.com>>: > > Hi all, > > @Patric For some reason, your > mail didn't show up at my inbox > in outlook at all, not even in > my spam box. > @Daniel: Thanks for replying, so > that I can read it now. > > If we only had access to the key > scancode, it would be perfect. > But as Daniel already pointed > out, we can't.. :/ Qt does > provide a method that gets the > job done: > QKeyEvent::nativeScanCode(), but > unfortunately it doesn't work > for OSX, because there is no way > to get the scan code from Carbon > or Cocoa. > > So, since the position info of > the key is lost, I think that it > will be tricky to support custom > keyboard layouts. However, we do > have access to the current input > locale. So, we could maybe make > a lookup-table which will tell > what the key position is for a > certain key, for a certain > keyboard layout. > > For example: > getKeyPosition(key, currentLocale); > > getKeyPosition('q', "en_US") // > will return position 17 (French > keyboards have the Q and the A > switched) > getKeyPosition('a', "fr_FR") > // will return position 17 > > https://www.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.keyboardtechref/doc/kybdtech/figures/kybdt1.jpg > > <https://www.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.keyboardtechref/doc/kybdtech/figures/kybdt1.jpg> > > This way we could have just one > keyboard preset, based on > keyboard positions (or en_US > shortcuts?). If we ever wanted > to support more keyboard > layouts, we would only have to > update the lookup table used by > getKeyPosition(), and wouldn't > have to update the keyboard presets. > > I don't know how the > implementation would be yet, and > I am not sure if it's possible > 100%, but it seems logical. What > do you think? > > Kind regards, > Jordi > > > > > > > ------------------------------------------------------------------------ > From: dasch...@mixxx.org > <mailto:dasch...@mixxx.org> > Date: Sat, 25 Jun 2016 11:18:48 > +0200 > To: bzk0...@aol.com > <mailto:bzk0...@aol.com> > CC: > mixxx-devel@lists.sourceforge.net > <mailto:mixxx-devel@lists.sourceforge.net> > Subject: Re: [Mixxx-devel] > Multiple language keyboard mapping > > Hi Patric, > > Your mail was rated as spam from > my Gmail. > > @all: see Patric's original mail > below. > > Mixxx can read the selected > Keyboard layout form the OS > independent from other local > settings. > > Mixxx should provide a default > keyboard mapping that works out > of the box for almost all users, > without swapping or disabling > hot-keys. > Unfortunately the position info > of a key is lost in the OS on > the way to Mixxx. > That's why we have to deal with it. > > It is an issue because the Mixxx > keyboard mapping is position > dependent and not value depended. > For example: on an en-US > keyboard T and Y are neighbors > (below 6) They are mapped to PFL > left deck and PFL right deck. > On a de-DE keyboard Z and Y are > swapped. This means relying on > the OS, the PFL right deck key > is moved to the very left bottom > key (where we had original hot > cue 1) > > The user will not like position > moving hot-keys if he switches > the keyboard layout during a > Mixxx run. > This might be required when > searching for tracks of local > artists. > > This becomes worse, if we assume > a Cyrillic or Inskript keyboard, > where T and Y are missing entirely. > > Any solution that keeps a > hotkeys at its position when > changing layouts will work for me. > > Kind regards, > > Daniel > > > > 2016-06-24 23:35 GMT+02:00 > Patric Schmitz <bzk0...@aol.com > <mailto:bzk0...@aol.com>>: > > Hi Jordi, > > I wonder if it wouldn't make > more sense altogether to > rely on the > OS / graphical environment > for the translation of physical > keycodes to keysyms. People > might be using exotic keyboard > layouts or can have > personally customized ones. > This cannot be > accounted for by predefined > layouts, and is in no way > related to > the locale setting. For > example on this system I'm > using the C > locale (none) with the > workman-p layout > > (http://www.workmanlayout.com/blog/ > > <http://www.workmanlayout.com/blog/>). > I also switch between intl > and standard variants during > use. > > Admittedly this is a bit > exotic, but I think you get > my point. > For Linux/X11 this would be > done using XKeycodeToKeysym from > /usr/include/X11/XKBlib.h, > don't know about other > platforms. Just > something to think about, > I'm not familiar with the > particular > problem/constraints you are > facing! > > Best, > Patric > > On 06/23/2016 12:15 AM, > Jordi Ortolá Ankum wrote: > > Hi folks! > > > > Now that I am working on > the Keyboard Controller > > > > <https://github.com/mixxxdj/mixxx/pull/966 > > <https://github.com/mixxxdj/mixxx/pull/966>> > I am re-implementing > > all aspects of the > keyboard, but in the form of > a controller. One > > of those aspects is > supporting multiple keyboard > layouts for > > different languages and > choosing the right one > depending on the > > current locale. > > > > Currently we have 12 > different files, one file > per keyboard > > layout (en_US.kbd.cfg, > es_ES.kbd.cfg, etc), from > which one is > > loaded in while booting > Mixxx (if custom mapping > isn't found). > > But now, if the keyboard > is a controller and is > listed under > > "preferences -> > controllers", it is suddenly > possible to change > > keyboard mapping > (KeyboardControllerPresets) > at runtime by > > clicking on the preset > dropdown menu. > > > > Now here is the thing. If > we keep having one file per > language, > > that means that me, having > a en_US keyboard layout, I > will also > > get the russian keyboard > layout listed as an option. > As a user I > > shouldn't be amused (no > offense to the Russians ^^, > the same goes > > for other foreign > layouts), especially > considering that I just > > wanted to go and choose > the default mapping. /But > oh, wait.. > > there are 12 default > mapping presets?/ > > > > I would say that if those > 12 different presets, which > actually > > represent the same > mapping, where just in one file: > > Default.kbd.xml, that > would be a lot clearer. I > propose to make > > the new keyboard presets > multi-language compatible > and ship just > > one file, containing > default mappings for all > languages. When the > > user selects a preset and > the XML is parsed, it would > only load > > in the mapping for the > current local keyboard > layout or default > > to en_US if the selected > preset doesn't support your > layout. If > > the keyboard layout was > changed at runtime, the keyboard > > controller would go and > see if the current preset > has mappings > > for the new keyboard > layout, and if found, load > them in. > > > > What do you think? > > > > --Jordi > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech > Expo July 15-16. Meet us at > AT&T Park in San > Francisco, CA to explore > cutting-edge tech and listen > to tech luminaries > present their vision of the > future. This family event > has something for > everyone, including kids. > Get more information and > register today. > http://sdm.link/attshape > > _______________________________________________ > Get Mixxx, the #1 Free MP3 > DJ Mixing software Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > > <mailto:Mixxx-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > <https://lists.sourceforge.net/lists/listinfo/mixxx-devel> > > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo > July 15-16. Meet us at AT&T Park > in San Francisco, CA to explore > cutting-edge tech and listen to > tech luminaries present their > vision of the future. This > family event has something for > everyone, including kids. Get > more information and register > today. http://sdm.link/attshape > > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ > Mixing software Today > http://mixxx.org Mixxx-devel > mailing list > Mixxx-devel@lists.sourceforge.net > <mailto:Mixxx-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > <https://lists.sourceforge.net/lists/listinfo/mixxx-devel> > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July > 15-16. Meet us at AT&T Park in San > Francisco, CA to explore > cutting-edge tech and listen to tech > luminaries > present their vision of the future. > This family event has something for > everyone, including kids. Get more > information and register today. > http://sdm.link/attshape > > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing > software Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > <mailto:Mixxx-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > <https://lists.sourceforge.net/lists/listinfo/mixxx-devel> > > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? > Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which > users, apps, and protocols are > consuming the most bandwidth. Provides > multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed > decisions using capacity planning > reports.http://sdm.link/zohodev2dev > <http://sdm.link/zohodev2dev> > > > > > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing software > Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > <mailto:Mixxx-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > <https://lists.sourceforge.net/lists/listinfo/mixxx-devel> > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? > Monitors network bandwidth and traffic > patterns at an interface-level. Reveals > which users, apps, and protocols are > consuming the most bandwidth. Provides > multi-vendor support for NetFlow, J-Flow, > sFlow and other flows. Make informed > decisions using capacity planning > reports.http://sdm.link/zohodev2dev > <http://sdm.link/zohodev2dev> > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing > software Today http://mixxx.org Mixxx-devel > mailing list > Mixxx-devel@lists.sourceforge.net > <mailto:Mixxx-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > <https://lists.sourceforge.net/lists/listinfo/mixxx-devel> > > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors > network bandwidth and traffic patterns at an > interface-level. Reveals which users, apps, and > protocols are consuming the most bandwidth. Provides > multi-vendor support for NetFlow, J-Flow, sFlow and > other flows. Make informed decisions using capacity > planning reports.http://sdm.link/zohodev2dev > <http://sdm.link/zohodev2dev> > _______________________________________________ Get > Mixxx, the #1 Free MP3 DJ Mixing software Today > http://mixxx.org Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > <mailto:Mixxx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > <https://lists.sourceforge.net/lists/listinfo/mixxx-devel> > > > > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth > and traffic patterns at an interface-level. Reveals which users, > apps, and protocols are consuming the most bandwidth. Provides > multi-vendor support for NetFlow, J-Flow, sFlow and other flows. > Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev <http://sdm.link/zohodev2dev> > _______________________________________________ Get Mixxx, the > #1 Free MP3 DJ Mixing software Today http://mixxx.org > Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net > <mailto:Mixxx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > <https://lists.sourceforge.net/lists/listinfo/mixxx-devel> > > > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
