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
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
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 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
From: 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
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>:
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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
