Re: [VMPK-devel] Cross-platform raw layouts

[Mechanical s. <rep...@gm...>]

For clarity here, I'm calling the OS's rules for converting keycodes 
into characters "keyboard layouts", and VMPK's rules for converting 
keycodes/characters into musical notes "note layouts".

On 2012-07-30 09:07, Pedro Lopez-Cabanillas wrote:
> In my view, there is a different problem much more important than the
> multiplicity of keycode sets: VMPK's keyboard maps are hard to customize. [...]
> We should implement a better keyboard map editor. A dialog
> graphically showing the most common computer keyboard dispositions, with a
> mechanism to show and assign a musical note to each key.
This would be a great enhancement, but UI seems orthogonal to the note 
layout format. Unifying the formats would make sharing easier 
immediately, without prejudicing the longer-term project of the 
graphical editor.

Considering that you (like most people) "hate to edit XML files by 
hand", a new format need not even be XML. A note layout is really just 
an n-by-2 array; a simple text format would suffice. Less convenient 
than a GUI, of course, but easier than syntax-error-prone XML.
> The dialog should
> allow to export the maps in several formats: raw (OS specific) and
> optionally alphanumeric (language specific) maps, all of them compatible
> with the current keyboard maps used by VMPK. There may be of course a new,
> common and independent format, that could be shared among users.
As it stands, we effectively have 3 raw note layout formats (Windows, 
Mac, Linux) as well as 1 non-raw format for each computer keyboard 
layout in existence. I feel this proliferation of formats is confusing 
to users. Suppose I want to create and use a note layout. Now, first I 
have to learn the difference between raw and non-raw modes. To load the 
layout, I have to figure out which of the 2 separate text fields to pick 
a layout is the one I want. And even if I choose right, it may behave 
incorrectly without warning (e.g. if I switch keyboard layout, or if I 
try to use my note layout on a different OS). In particular, having the 
redesigned editor UI try to support exporting to all these formats is 
confusing.

All this is not necessary. The advantage I see of a unified 
cross-platform format is that it removes the chief disadvantage (OS 
dependence) of raw mode. The only other disadvantage I've noticed (of 
the current implementation) of raw mode is that there are some UI corner 
cases to work out. For example all key input in the main window gets 
stolen (preventing typing in the channel/octave/transpose widgets and 
disabling standard keyboard shortcuts to navigate menus). But this is a 
quibble, and fixable in principle. So it potentially lets us standardize 
on one single note layout format to rule them all. (Of course, we'll 
keep supporting importing the previous formats. In particular I expect 
automated conversion of non-raw note layouts is possible by querying the 
OS, so hopefully the transition wouldn't break much.)
> The sharing
> method for keyboard maps and instrument definitions needs also a second
> thought. I was thinking about something along the lines of KDE's "Get Hot
> New Stuff!" (http://data.kstuff.org/).
Why not just use that? Does it pull in too many KDE libs?

Best regards,