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
