(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>:
> 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
> To: jordi...@hotmail.com
> CC: mixxx-devel@lists.sourceforge.net; 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>:
>
> 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
>
> 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
> Date: Sat, 25 Jun 2016 11:18:48 +0200
> To: bzk0...@aol.com
> CC: 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>:
>
> 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/). 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> 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
> 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
> 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
> 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
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
