Re: xkb: Switch delay to a group
Hi all, What about my patch, http://bugs.freedesktop.org/show_bug.cgi?id=865#c45? People report that it works... And I can split it into two chunks if it's difficult to review. Regards, Ilya ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xkb: Switch delay to a group
Daniel Stone пишет: The filter should get called for _any_ key press and release. So you get Ctrl+Shift and set the flag in the filter private. Then someone presses, say, B, which should cause the very same filter handler to get called _again_. You notice it's another keypress, and clear the flag. In the filter, on key release events, you just watch the number of keys currently down, and if it's currently zero, you either make the group switch or not, depending on the flag. You are right :) So, if I get some useful patches for the issue I attach them to the bug http://bugs.freedesktop.org/show_bug.cgi?id=865, ok? Sounds good. :) Ok, I've done the patch, works good for me, see http://bugs.freedesktop.org/show_bug.cgi?id=865#c45. It would be nice if someone review it. One issue with the patch: switch on release behaviour is hard coded (but can be easily turned off by xkbSwitchGroupOnRelease() function!). How to do it? The very simple and dirty way is to turn on/off via ... XkbSetDebuggingFlags() function only but it is not good. Standard XKB configuration is not good for it too. Regards, Ilya ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xkb: Switch delay to a group
Dirk Wallenstein пишет: And I just suggest to implement the option I mentioned earlier. I think it is not hard to do but I'm not entirely sure... So it would be nice if someone knowing the XKB code confirm my guess. The thing is, and I guess you have seen that, is that the handlers are missing the differentiation between Press/Release altogether. If you could fix that you can use XkbFilterRec to store a flag. I think just going more global is not the right thing to do here. Well, I considered to set up another filter via XkbFilterRec and _XkbApplyFilters() but xkbi-filters is a vector. If one need to cancel the delay switching then the vector have to be gone all round to deactivate the filter. I think another flag in xkbi-state is more natural. xkbActions.c needs a decent overhaul and I will do that as soon as I can switch to XKB programming more comprehensively (my current work has a completely different set of requirements, and I would prefer to do one after the other). I have a list of ideas, of what could be part of a future XKB, and switch-group-on-release is on there. I haven't had the canceling thing. You want to cancel the group-switch if any unrelated key is being pressed, right? Also, another modifier? Yes, you meant right, unrelated key/another modifier/whatever. But I've found out how to do it yet, the right way. But don't let this stop you from improving xkbActions.c. You might want to base that on a current version. Greetings, Dirk. I would like that option doesn't make any side effect on XKB despite itself. There are much not so clear code in XKB out there for me, like XkbCharToInt(v)... But I want to try to fix the issue. Regards, Ilya ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xkb: Switch delay to a group
I have a list of ideas, of what could be part of a future XKB, and switch-group-on-release is on there. I haven't had the canceling thing. You want to cancel the group-switch if any unrelated key is being pressed, right? Also, another modifier? Yes, you meant right, unrelated key/another modifier/whatever. But I've found out how to do it yet, the right way. Oops, it's a typo. I've *not* found out yet. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xkb: Switch delay to a group
Dirk Wallenstein ?: And I just suggest to implement the option I mentioned earlier. I think it is not hard to do but I'm not entirely sure... So it would be nice if someone knowing the XKB code confirm my guess. The thing is, and I guess you have seen that, is that the handlers are missing the differentiation between Press/Release altogether. If you could fix that you can use XkbFilterRec to store a flag. I think just going more global is not the right thing to do here. Well, I considered to set up another filter via XkbFilterRec and _XkbApplyFilters() but xkbi-filters is a vector. If one need to cancel the delay switching then the vector have to be gone all round to deactivate the filter. I think another flag in xkbi-state is more natural. xkbActions.c needs a decent overhaul and I will do that as soon as I can switch to XKB programming more comprehensively (my current work has a completely different set of requirements, and I would prefer to do one after the other). I have a list of ideas, of what could be part of a future XKB, and switch-group-on-release is on there. I haven't had the canceling thing. You want to cancel the group-switch if any unrelated key is being pressed, right? Also, another modifier? Yes, you meant right, unrelated key/another modifier/whatever. But I've found out how to do it yet, the right way. But don't let this stop you from improving xkbActions.c. You might want to base that on a current version. Greetings, Dirk. I would like that option doesn't make any side effect on XKB despite itself. There are much not so clear code in XKB out there for me, like XkbCharToInt(v)... But I want to try to fix the issue. Regards, Ilya ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: xkb: Switch delay to a group
Daniel Stone пишет: Well, I considered to set up another filter via XkbFilterRec and _XkbApplyFilters() but xkbi-filters is a vector. If one need to cancel the delay switching then the vector have to be gone all round to deactivate the filter. I think another flag in xkbi-state is more natural. That's the wonderful thing about xkbActions.c. The filter system has to be rewritten, too - it needs per-level granularity. Maybe there can be a more general approach towards canceling actions when doing that. But maybe you would want to put the focus on switch-group-on-release first. If want to try it without Press/Release knowledge inside the handler you might want to try to skip the first event. If that works together with an option to select between when to trigger the switch (press/release), that would be an improvement already. Actually, it's really not that bad. In the group-switch handler, you could just set a flag for 'maybe switch groups when all keys are up'. As the handler gets called for all key events, you could then just clear the 'maybe switch' flag when another key gets pressed. Ok, your variant is better, but still not good one; as far as I understand just clear the 'maybe switch' flag still needs to go through all xkbi-filters vector to find the one with that flag. So, if I get some useful patches for the issue I attach them to the bug http://bugs.freedesktop.org/show_bug.cgi?id=865, ok? Ilya ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
