Hi Daniel, hum.. it seems I finally need to retire this AOL email address, at least for mailing list communication ;) seems spam filters are just too sensitive to those (damn you spam-bots!). Switched address now.
Ok I kinda expected that I was missing something about the problem you are facing here. So just to understand it. Aren't the physical scan codes those which represent the actual position on the keyboard? Those are then translated to symbolic keys using the layout in the OS? On this physical qwertz keyboard here I get consecutive numbers of scancodes when pressing qwertz (24-29). By coincidence I also have a spanish qwerty lying here, which gives me the same sequence of scancodes when pressing qwerty, i.e. the same physical locations. So probably what is needed is a possibility to map hotkeys which shall be tied to a physical key location to scancodes, and have text entry and other, not physically anchored hotkeys (like undo, cut, copy, paste) translated by the keyboard layout as set by the user. Looking shortly at the code in mixxxkeyboard.cpp and the QKeyEvent documentation, it seems this is not possible because Qt/Cocoa will not report the physical scan codes on OS X. Searching for discovering actual physical scancodes and how they're mapped on OS X reveals that it's rather a mess and there seems not to be such a thing as standardized physical keycodes between mac keyboards and models. Once more bitten by Apple's stupid platform specifics.. *angerfist* I'll keep searching for a way to get physically located key information on OS X, but it seems that in order to support Apple systems reliably, one has to reimplement keyboard layouts in order to do that reverse mapping. Best, Patric On 06/25/2016 11:18 AM, Daniel Schürmann wrote: > 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 https://lists.sourceforge.net/lists/listinfo/mixxx-devel
