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

[Daniel Stone]

Hi,

On Fri, Oct 10, 2008 at 04:00:10PM +0200, Bernd Steinhauser wrote:
> Daniel Stone wrote:
> > 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?).
> 
> I think that gets very complicated and I guess that there won't be any 
> other variants in the official X.org distribution then (which is a 
> shame, even if it would be possible).

Choice complicates things, yes.

> > 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.
> 
> No, as far as I know, Windows doesn't ship Neo.
> Tbh, I don't get what you are on about with the grounding. I thought 
> this is an open source project. :)

Yes, it is an open source project, but measuring how Windows and OS X
do things is a pretty good measure of how people expect their keyboards
to behave.

> But may I ask you why don't you change the text in the README, if the 
> addition of layouts, that would not be put under a language namespace, 
> wouldn't be allowed?

Sergey?

> > 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.
> 
> All I can say, is that the current system sucks (sorry for the strong word).

It sucks if you're trying to deploy completely new layouts, yes.

> The main problem Neo has at the moment is that people have a very hard 
> time to install it.
> There are quite a few people trying it out, that don't really have much 
> knowledge of computer stuff.
> So the best way would be to provide packages for the distributions, 
> which isn't exactly possible because of file collisions.

Right.

> So yes, creating new layouts is a niche task, but you might be impressed 
> at how many people would actually be interested in doing something like 
> that and how many people would try it out. It's definitely more than 
> you'd expect.

I'm just trying to balance the startup time cost for everyone on the
planet, versus helping people create new layouts from scratch; right
now, the weight of userbase on the 'new layouts from scratch' side
isn't huge.

> And especially if it is a nice task, the last thing on earth you should 
> do is to get in their way, which is exactly what the current system does 
> and which is a pity.

It's not getting in your way for the sake of getting in your way.  It's
getting in your way because the alternative would be to slow startup
down further still, which is unacceptable.

I'm happy that you're very interested in keyboard work, and hope the Neo
experiment works out well.

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/20081010/c93b6374/attachment.pgp>