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
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
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
Date: Thu, 14 Jul 2016 16:10:07 +0200
Subject: Re: [Mixxx-devel] FW: Multiple language keyboard mapping
To: jordi...@hotmail.com
CC: 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
Here is the source:
https://people.freedesktop.org/~jeremyhu/analyzer/tifa-linux32/20120705-2000/libX11/report-aneU1a.html
<https://people.freedesktop.org/%7Ejeremyhu/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
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/%7Eaeb/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/%7Eaeb/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
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
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
<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
<mailto:Mixxx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
