Re: [libxkbcommon] Pull request - many changes
> Ah. Well, the plan is to extend libxkbcommon to allow more than four > groups - this is already mostly done. XI2 already supports higher > groups, so the bulk of the work would be in fixing the XKB wire > protocol. As long as redirect actions remain supported, this will indeed remove the need for overlays. I am a bit pessimistic about the time it takes for such enhancements to be supported by applications (about one year ago, I still had to work with an XKB unaware application...) > Interesting - which problems does this cause exactly? In xterm, for example, when you press Shift+the key that has KP_Add on a higher level (for example, on Level 5 as in de(neo)), it will increase the font size, rather than entering the character. This is not a bug, it is just a loose definition of default keybindings, and can be fixed in the Xresources. But there are other Xt applications with similar problems. Andreas ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [libxkbcommon] Pull request - many changes
Hi, On 17 March 2012 16:24, wrote: >> At the moment it just means they won't work in Wayland, but support >> might (might) be removed from the X server at some stage too. Is >> there any reason you can't just use a locked group or level rather >> than an overlay? > > I currently use overlays to have five layouts in my keymap, which is not > possible with using groups alone. Admittedly, this is more for fun than > really useful, but I have seen that some people require more than the > four groups that XKB supports. Overlays allow to work around this > restriction. Ah. Well, the plan is to extend libxkbcommon to allow more than four groups - this is already mostly done. XI2 already supports higher groups, so the bulk of the work would be in fixing the XKB wire protocol. > Another use of overlays you will see when you try to put control keysyms > or keypad keysyms (such as Next and KP_Add) on a higher level of a > "usual" key (see, for example, de(neo) in xkeyboard-config). This > creates trouble with various applications (for example, Xt applications > such as xterm). If one uses overlays instead of levels, these problems > can be worked around. Redirect actions are an even more powerful > alternative, but they are harder to use. Interesting - which problems does this cause exactly? Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [libxkbcommon] Pull request - many changes
> At the moment it just means they won't work in Wayland, but support > might (might) be removed from the X server at some stage too. Is > there any reason you can't just use a locked group or level rather > than an overlay? I currently use overlays to have five layouts in my keymap, which is not possible with using groups alone. Admittedly, this is more for fun than really useful, but I have seen that some people require more than the four groups that XKB supports. Overlays allow to work around this restriction. Another use of overlays you will see when you try to put control keysyms or keypad keysyms (such as Next and KP_Add) on a higher level of a "usual" key (see, for example, de(neo) in xkeyboard-config). This creates trouble with various applications (for example, Xt applications such as xterm). If one uses overlays instead of levels, these problems can be worked around. Redirect actions are an even more powerful alternative, but they are harder to use. Andreas ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [libxkbcommon] Pull request - many changes
Hi, On 17 March 2012 15:21, wrote: >> And the changed you made are much better; especially removing geometry >> (by far the ugliest part) and overlays and radio groups (what the hell >> are those again?). Also removing atoms from the public API. > > Overlays are a very useful feature (I do not say this theoretically, I > actually do use them). I would regret it very much if they would not be > supported anymore. As I do not know what libxkbcommon is used for, I > wonder what will be the consequences of this removal? Do I have to > worry about the future of this beloved XKB feature? At the moment it just means they won't work in Wayland, but support might (might) be removed from the X server at some stage too. Is there any reason you can't just use a locked group or level rather than an overlay? Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [libxkbcommon] Pull request - many changes
> And the changed you made are much better; especially removing geometry > (by far the ugliest part) and overlays and radio groups (what the hell > are those again?). Also removing atoms from the public API. Overlays are a very useful feature (I do not say this theoretically, I actually do use them). I would regret it very much if they would not be supported anymore. As I do not know what libxkbcommon is used for, I wonder what will be the consequences of this removal? Do I have to worry about the future of this beloved XKB feature? Andreas ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [libxkbcommon] Pull request - many changes
Hi, On 16 March 2012 16:54, Ran Benita wrote: > On Sat, Mar 10, 2012 at 02:00:46PM +, Daniel Stone wrote: >> Great stuff - thanks again! I've pushed this, along with a bunch of >> other changes I've made, now. > > Great, thanks! > > And the changed you made are much better; especially removing geometry > (by far the ugliest part) and overlays and radio groups (what the hell > are those again?). Also removing atoms from the public API. Ha, yeah, some absolute loss in there. > Does all of this mean that there are no plans to use libxkbcommon in > the server or Xlib? I imagine the library can be a lot nicer to use > without clinging to the old interface and legacy stuff. I'm still planning to use it in the server, provided it's OK that people are willing to accept the limited subset of the full XKB spec that xkbcommon offers. In fairness though, a lot of stuff was never actually fully implemented, so it probably won't actually make any difference ... >> Out of interest, what were you planning to work on? > > Just streamlining it for a couple applications. You can see for example > some hacks I did to get the library working nicely (with my config, at > least): https://github.com/dvdhrm/kmscon/blob/master/src/kbd_xkb.c > (This is a WIP project by David Herrmann - wasn't updated to latest > changes yet). Obviously it contains errors and shouldn't be done by the > application developer. I'll try and make an example patch now. > > There's also plenty of janitorial work left to be done, if you want > it/have time to review it. Oh, nice! That looks really good - some of the stuff (e.g. deriving the actions from the compat map, updating the vmodmap, etc) is now unnecessary as it's done in xkbcommon. Always happy to review anything. :) Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [libxkbcommon] Pull request - many changes
On Sat, Mar 10, 2012 at 02:00:46PM +, Daniel Stone wrote: > Hi Ran, > > On 3 March 2012 22:40, Ran Benita wrote: > > [I know the normal procedure is to send the patches for review in > > reasonable chunks to the list, however I won't have time the following > > weeks, and I don't want them to get lost. So I'll try my luck now.] > > > > I set up a github repository with my libxkbcommon patches. The first few > > were sent to the list and some were reviewed (up to branch 'fixes'). The > > next one's were not (branch 'fixes-cont'). > > > > [...] > > > > The intention is to have a clean slate before doing some actual > > changes to libxkbcommon (which I hope to do when I have time in the > > future). > > Great stuff - thanks again! I've pushed this, along with a bunch of > other changes I've made, now. Great, thanks! And the changed you made are much better; especially removing geometry (by far the ugliest part) and overlays and radio groups (what the hell are those again?). Also removing atoms from the public API. Does all of this mean that there are no plans to use libxkbcommon in the server or Xlib? I imagine the library can be a lot nicer to use without clinging to the old interface and legacy stuff. > Out of interest, what were you planning to work on? Just streamlining it for a couple applications. You can see for example some hacks I did to get the library working nicely (with my config, at least): https://github.com/dvdhrm/kmscon/blob/master/src/kbd_xkb.c (This is a WIP project by David Herrmann - wasn't updated to latest changes yet). Obviously it contains errors and shouldn't be done by the application developer. I'll try and make an example patch now. There's also plenty of janitorial work left to be done, if you want it/have time to review it. - Ran ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [libxkbcommon] Pull request - many changes
Hi Ran, On 3 March 2012 22:40, Ran Benita wrote: > [I know the normal procedure is to send the patches for review in > reasonable chunks to the list, however I won't have time the following > weeks, and I don't want them to get lost. So I'll try my luck now.] > > I set up a github repository with my libxkbcommon patches. The first few > were sent to the list and some were reviewed (up to branch 'fixes'). The > next one's were not (branch 'fixes-cont'). > > [...] > > The intention is to have a clean slate before doing some actual > changes to libxkbcommon (which I hope to do when I have time in the > future). Great stuff - thanks again! I've pushed this, along with a bunch of other changes I've made, now. Out of interest, what were you planning to work on? Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
