Neo 2.0 as a separate keyboard layout or a variant of "de" and handling of "rules" files?

[Daniel Stone]

Hi,
Sergey is the maintainer of the XKB dataset, but I think I can answer
most of these (again), so.

On Sun, Oct 05, 2008 at 03:40:21PM +0200, Bernd Steinhauser wrote:
> Lately it came up for discussion on the Neo-Layout mailing list, if 
> maybe Neo could be a separate keyboard layout, which might allow it to 
> add variants of it to X.org, too.
> (For example Neo 1.1, which is currently the Neostyle variant of de 
> could be kept as the neo1.1 variant of Neo, and a One-Hand Neo (usable 
> with one Hand only, similar to ENTI-key++), as well as a Neo 3.0 are 
> planned, plus there are smaller variants for special purpose, too, 
> similar to the "nodeadkeys" variant for de.)

You can have a neo-onehand variant, neo2, neo3, etc (providing it
actually makes sense to have all these: it's already a pretty marginal
layout by the looks, so do you need to split it further?).

> Now the main question was if such a change (to add it as a separate 
> layout instead of a variant) would actually be allowed.
> There sure would be advantages for the Neo users, but maybe you X.org 
> people say that that is a no go and it should be kept in "de", even 
> though it doesn't have anything in common with the standard de layout.
> 
> The README file doesn't explicitly state, that there may be no 
> non-language keyboard layouts, instead it says, that the name must be 5 
> to 8 characters, but maybe in reality you would try to prevent the 
> addition of such a layout?

Yes.

> So... thoughts on that?

As I explained to you on IRC, the layout namespace is currently
locale/language-based.  Adding random other variants (especially ones
that seem to have no particular grounding: they're not
government-endorsed as is Finland's new Kotoistus layout, and I don't
believe they ship by default with Windows or OS X?) doesn't help this
at all.

> The next question is about the handling of the rules files.
> It seems that all major desktop environments only read out the base* or 
> the xorg* files.
> Now when a user wants to add his own, custom, layout, he has to replace 
> these files, which causes problems if he uses a package management 
> system, since those files would most likely replaced, if he 
> reinstalls/updates the package.
> The alternative is to not modify these files, but then it is not 
> possible to use the layout switching capabilities of the desktop 
> environment.
> To improve this situation, I would suggest to not use rules *files*, but 
> rules *directories*.
> For example, there could be a xorg.d directory instead of the xorg* 
> files, which contains the respective .xml and .lst files.
> The difference is, that the actual layout list is not read from a single 
> file, but from all files within that directory.
> That would it make possible for a user to place his custom keyboard 
> layout into a .xml and a .lst file within that dir and make it available 
> for the desktop environment.

Creation of new layouts is an extremely niche task, and given that we're
already failing at startup time due to excessive I/O (seeking in
particular) on XKB files, adding still more probably isn't the way to
go.  Most people would be working on variants of existing layouts,
assuming that people aren't inventing new locales or languages, so
they'd need to deal with the package management system in order to not
get the layout file stomped on upgrades anyway.

I'm sure Sergey would be happy to take the patch for the variant,
though.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20081005/91d50e75/attachment.pgp>