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
I am curious to know what you think!
Kind regards,
Jordi
------------------------------------------------------------------------
From: ferranpujolcam...@gmail.com
Date: Sat, 25 Jun 2016 23:43:28 +0200
Subject: Re: [Mixxx-devel] Multiple language keyboard mapping
To: jordi...@hotmail.com
CC: 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
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/). 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
<mailto: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
<mailto: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
<mailto:Mixxx-devel@lists.sourceforge.net>
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
