Shortcut Translation Tables #44
Comments
|
Cycle Applications is done in dev. May have to resolve Change Workspace last, gnome defaults to vertical layouts unless an extension is installed. Also will have to enable the caret detection system-wide (general gui) otherwise Wordwise will conflict with Change Workspace shortcuts going in either vertical or horizontal. Early dev build has most of the shortcuts resolved besides Changing workspace and minimize window (Ctrl+H is used by many apps.. so remapping it to another combination may be difficult to do..). |
|
Just to make note of a meaningful difference between xfce4 vs gnome or kde. Xfce4 does not typically support multiple hotkeys for a function of xwfm4, however other extensions and commands for non-native xwfm4 actions is supported for multiple hotkeys. Still it isn't much help in assigning multiple hotkeys for any DE action. This becomes somewhat meaningful due to the terminal keymap that defaults the Cmd position to Ctrl+Shift. It is seemingly not possible to retro-actively reset modifier keys after the destination key has been pressed - any remapping happens in a way that is disconnected from the keys you're actually pressing. This means remapping a modifier AFTER the destination key is pressed it initiates a tap on the modifier key you want (and may ignore the original modifier - if you set it to clear itself), but you can't really swap the modifier. I may make a blog like post later better explaining this issue, if anyone thinks they have a solution on fixing that behavior in xkb then please reach out to me as I'd love to have a real solution for it. I can still do what I need to do, but it would make things a good bit easier to configure. |
|
@rbreaves firstly, thank you for the work you're doing here. I can see this is in active development, but my initial impression has been positive 👍 I note above you say cycle application is done in dev so perhaps the following issue is already resolved. Context Shortcut Keypress Current Focus Issue Expected behaviour |
|
@mozmorris Yes lol, the app cycling in master would likely be in reverse while using the terminal, and I have been doing so many commits I honestly couldn't remember if I had included that in master at all just yet. That isssue is resolved even now on the dev branch, and I think the current commit is stable for Ubuntu 19.10, and now even GalliumOS (although I have one ticket saying otherwise atm). You can try the current dev release if you'd like. I will be testing 2 or 3 OS's and making sure they all work and getting some KDE stuff going before merging it with master as it will bring online the rest of the most commonly used OS shortcuts. Also while the reversed app cycling has been resolved for the terminal on Gnome, I was not able to fix it on xfce4 (galliumOS) and any fix I can come up with atm would be worse than leaving it cycling backwards. I believe KDE won't be an issue either because like Gnome I can specify multiple shortcut keys for any given action, xfce4 does not allow that. |
|
@rbreaves +1 on the awesome work on this. There are a couple of other little issues I can see, not sure if this is the right place to bring them up so sorry in advance...
|
|
@mlbaquerizo That is odd behavior for Firefox to not be defaulting back to using wordwise shortcuts while the input caret is active. I will have to do some testing later to see if I can replicate that in either master or dev. It could be an issue with either something about the polling of IBus for the caret status or the execution of xdotool even. I am not sure about the backtick issue, it's not something I have been looking at that specifically. I may have messed with it some though in dev while working out how to best deal with Cmd+Tab. Cmd+Tab is challenging in general though because we're really working with Ctrl+Tab (using Cmd key) and the real Ctrl+Tab in both Linux and macOS tends to cycle in app tabs, while Alt is for apps in Linux and Cmd is for Apps in macOS. What I end up having to do is re-remap Cmd+Tab (ctrl+tab) to Alt+Tab essentially and re-remap Ctrl+Tab (super+tab) back to Ctrl+Tab lol. It feels kinda hanky - but it works under Gnome and xfce for the most part - with enough work, but KDE is proving to be difficult as it doesn't like it when the real Alt key isn't being used. (Resetting KDE to actually use Ctrl vs Alt for app switching via the proper KDE rc file similar to using gsettings for Gnome to set a shortcut hasn't panned out) Also app switching gets even more difficult under the Terminals, I believe the reverse cycling is broken on Terminals and will likely remain that way for awhile until I or someone else can find a way to resolve it. That is relatively minor though, I think. And the only other alternative I can think of would be to completely change the keymap up and not place Ctrl where the Cmd key goes - but I refuse to do that just over app switching lol, because that can of worms is much worse and would lead to nothing good. |
|
@mlbaquerizo I think the caret/wordwise issue you experienced in Firefox is something that can sometimes happen, but hopefully very rarely. I duplicated it once just now, but it could be because I was doing it very quickly too (if you are fast enough the caret polling won't catch up as it polls at 0.5 seconds). I could try lowering that value, but I feel like that could cause issues with a function I am using from the x11 library that waits for changes to occur as I had already tried other values too like 0.1, 0.2 and 0.3. I assume that function just needs a certain amount of time to fully initialize and if you try re-initializing too quickly it will crash the program in unexpected ways. It's a hard thing to balance tbh, because I am trying to do 2 things at once but only for the web browsers - monitor what program has the current focus and whether the caret input is active or not. The are no other apps where the caret input status needs to be monitored, afaik - but if there are it is easy enough to support going forward. |
|
it seemed to have been a constant occurance for me. |
|
@mlbaquerizo That select-all issue has been fixed in the dev branch as of yesterday. It unfortunately was introduced while implementing a feature request and only impacted Chrome or chromium based (electron) apps. Kinda a big bug I admit, but it has been resolved. See this ticket for more details #52 and anything after commit b904235 should have the bug fixed.Concerning the Firefox issue you are having, it may be related to your specific distro needing some additional packages for IBus to fully function. If you can provide me with more info on what distro you are using the log output of the service that could help me resolve the issue for you. display service log Also read output of the input caret while the service is running Be even more useful to delay for 5 seconds so you can highlight an input field in firefox and see how it reads back while the input field is active. The caret should be reporting back with 1 while an input field of a browser is active, but if it says anything else while the input field is active then that part of the keymapping will fail to work. |
|
The select-all issue is fixed in dev. Thanks! Running Manjaro 19.0.2 Gnome edition And as you can see |
|
@mlbaquerizo IBus appears to be surprisingly difficult to get fully configured on Manjaro Gnome. The main issue is that IBus not only needs to be installed and set as the default method, but the Panel extension needs to be there - but isn't and I have not been able to figure out what package or thing needs to exist or be set for the Panel to be there. To set your IBus as the default method you can manually do this and logoff and back on. (I would have merged this as a fix already, but the panel being the other element prevents me from making any updates on this issue.) You can do your own testing, if you want, by running these two commands out of the caret_status.sh file. A more general command, not involving the panel, but I still can't seem to get any output in the terminal with it either org.freedesktop.IBus can be inspected using d-feet, but that hasn't told me much. If anyone has any ideas it would be appreciated and I'll merge the fix in. |
|
Moving all further discussion to a separate ticket. #59 @mlbaquerizo It looks like the ~/.bashrc file should be using xim, that lines up with PopOS and probably others when they are configured to use IBus. It seems Firefox is jailed in a way that only allows for xim to work with it. This still doesn't resolve the actual problem though, at least not for me - the input caret is still not being detected, I suspect the Panel is still missing. I am not sure why it looks like Pop_OS has the IBus service running twice, but it does work fine in Pop_OS. Pop_OS 19.10 Manjaro Gnome 19.10 |
|
Switching windows within a particular window group on XFCE and DE's that do not support it directly. Map Ctrl+ |
Attaching an excel doc for others that may want to identify additional system level shortcuts they'd like to see. Kinto Translation Table.xlsx
Kinto v1.0.7
Kinto GUI
Ctrl = Cmd Position
Super = Ctrl Position
Kinto Term
Ctrl+Shift = Cmd Position
Ctrl = Ctrl Position
Information on how to contribute is in the ReadMe.
Base
Wordwise
Terminal
Browsers
System Level
Browsers
The text was updated successfully, but these errors were encountered: