On Friday 20 November 2009 00:06:47 Peter Hutterer wrote: > On Wed, Nov 18, 2009 at 01:26:10PM +0100, Dirk Wallenstein wrote: > > But honestly, I think it would be a real improvement if users could > > define their own keymaps with the full range of tools that XKB > > provides. > > I skipped the other parts, because your last sentence sums it up perfectly: > we need better configuration tools. XKB from a users POV suffers more from > the lack of configuration tools, less so from the protoco/implementation. > > For what you seem to be proposing in this thread, the focus should thus be > on the client application to enable flexible (and persistent) custom > configuration. Think of an XKB-aware xmodmap, that will be the core of it.
I don't think a command-line tool can in any form reasonably and intuitively accomplish that, with all the key types and actions. That's why I wrote Duttulm (http://sourceforge.net/projects/duttulm/). It already has some very important features. It is possible to edit an interactive visual representation of a button device, by which it will be possible to depict information about a keymap in form of key colors (key-type dissemination, behaviors, action types). Also, loading and saving to/from an XML representation is completely abstracted. The current state is described in this pdf: http://sourceforge.net/projects/duttulm/files/Duttulm/0.1/Duttulm.Introduction.pdf/download >From now on development can focus on XKB keymap specific parts. I have already put much thought into how to organize the data and how to isolate the effects of possible changes to XKB. > Once that application is working, we can re-visit and see what actual > deficiencies are in the protocol/implementation. I still think you can > can get about 80-90% there without having to touch XKB (the protocol) > itself. Yes, I thought about providing the hundred or so default actions as a selection of non-editable actions. The result would be the set of actions available through xmodmap currently, plus configurable key-types and behavior. This would be a perfect moment to re-visit protocol/implementation. I think at that stage it could also serve as a basis for an open discussion about what should or shouldn't be possible. Greetings, Dirk. _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
