> It costs in terms of maintenance, certainly. There's exactly one person > in GNOME that knows libgnomekbd and libxklavier, and that's you. Well, considering that people submit useful patches to those libs, there is some shared knowledge. But in general you are right.
> We have the most dreadful options dialogue, with conflicting options[1], > we have a X server imposed 4 layouts maximum limit[2], server-driven > keyboard shortcuts with limited options[3]. That's XKB world, right. Something should be done to hide its "oddities", as everyone agrees. All I am saying is that riches and flexibility of XKB world should not be lost, if possible. A couple of notes: [1]I am not sure which options are "conflicting"? [2]As I said earlier, there can be workaround. Not perfect, but the best you can do... [3]You cannot avoid that if you deal with server-based group switching. Well, if you move group switching to the client side, you can do everything of course... > We also lacking integration with input methods that a large number of > users use (and if you want to compare those things, much larger than the > number of people that use "per window layouts"). +100500. > There will be small regressions, which we'll do our best to fix, and > there will be design decisions made to ignore particular problems and > settings (because I don't see CapsLock key placement as a requirement to > the free desktop). Filtering out some options/group is reasonable, even necessary - but if you are going to keep some of them visible anyway - let's allow people to turn the filter on/off. Costs nearly nothing, decreases the unhappiness of the advanced users. > We need to go forward (and you're merely pointing to problems that we > didn't know existed because code isn't implemented yet!). I'm sure we'll > sort those problems out in due time. Agree! Sergey _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list