Ctrl click doesn't work

[mkaito]

Hey,

I don't see anyone else talking about this, and I've seen quill18 recording a LetsPlay on YouTube where he uses the Ctrl-Click feature frequently, but I don't know what would be wrong with my installation. I've disabled all other mods and reset all options.

Yet, ctrl-clicking on a work tab column simply sorts that column, as if though ctrl wasn't presssed.

The scroll wheel doesn't ever seem to do anything except zoom the world either. This might be related?

I've got Worktab version v0.18.1.5, Rimworld 0.18.1722, running on Linux through Steam.

[FluffierThanThou]

Hey mkaito,

There apears to be some sort of bug on linux/unity that stops the ctrl modifier working. I'm aware of this (it's been reported on the Ludeon forums and steam), but I have no idea what to do about it at the moment. I've also not seen it reported anywhere else, which is odd - to say the least. It might be that I'm checking for modifiers in the wrong part of the UI loop, but then it does work on Windows (not sure about Mac, or different linux distributions).

If anyone has any further information or has found refernces to this issue elsewhere, please let me know.

[mkaito]

Maybe you could make the modifier configurable? We have access to some of the older modifiers on Linux, such as the super and meta (not alt) keys and what not.

[FluffierThanThou]

I'm relying on Unity for input, which is normally the way to go - that's what the engine is for. I'm not keen on figuring out how to get input 'manually' for different platforms, so platform dependent modifiers are pretty much out.

That said, I'm going to try and make modifiers configurable. That may take some time though, as I would also need to set up a linux environment to test on. It would help if I knew what distribution of linux you're running, so I can start to try and reproduce the issue.

[mkaito]

Unity should be able to handle those modifiers. Probably. Regardless, making them configurable would allow me to set it to something that works for me.

I'm on Arch Linux, i3wm, but that's not really as important as you might initially assume. Input handling is universally handled by libxinput, except on distributions that want to be special for whatever reason (or people using wayland). Unity would handle that kind of thing anyway. Getting yourself a Live installation of Ubuntu, or something of the sort, should be sufficient for testing, as would a virtual machine.

[mkaito]

Actually, after looking at the Unity docs, no, it does not handle old school Unix modifiers. Even so, I could at least set it to alt or shift-alt or something, I guess.

[HellishINC]

This isn't a bug that only affects Rimworld. This is a "bug" in linux it self. I don't remember the exact details or where I got the info (was maybe a year ago) but what happens is that X is capturing the input and not properly forwarding it to the program.

I don't think you'll be able to properly fix it Fluffy (unless of course you want to contribute to X :P) as it's not a game bug. So the best solution is to either change the default hotkey, expose it in an editable file or implement changeable keys.

Edit: For what it's worth the other game that I've seen this on is MC. It does not allow shift + 2. You can also see it happen in some DEs. I use i3wm with xfce on Arch and xfce will often times "swallow" the i3 hotkeys.

[FluffierThanThou]

Hey Helly, thanks for confirming my suspicions! And yeah, the plan is to make the modifiers configurable, but that's a pretty major refactor, it'll take some time.

On Sun, 14 Jan 2018 at 06:25 Helly notifications@github.com wrote:

This isn't a bug that only affects Rimworld. This is a "bug" in linux it self. I don't remember the exact details or where I got the info (was maybe a year ago) but what happens is that X is capturing the input and not properly forwarding it to the program.

I don't think you'll be able to properly fix it Fluffy (unless of course you want to contribute to X :P) as it's not a game bug. So the best solution is to either change the default hotkey, expose it in an editable file or implement changeable keys.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/FluffierThanThou/WorkTab/issues/82#issuecomment-357489683, or mute the thread https://github.com/notifications/unsubscribe-auth/ARq4MtbknEfe0r-6biwa-Lgx_8ucrB8Cks5tKY--gaJpZM4RS3Y9 .

[HellishINC]

I'm not a programmer so while I did look through some of the code I couldn't find where the default key was being declared. Would it be possible to simply change that in source and compile it? I would be willing to do so in a windows VM if it means I won't have to fully expand all job types (and thus make the headers unreadable as they all overlap).

[RenaudF]

Strangely enough ctrl+click works fine for 10x increase in the bills (ubuntu 16.04) but doesn't work in the work tab either... I have tried suggestions from https://askubuntu.com/questions/742127/ctrl-shortcuts-not-working-in-vlc but that didn't work.

[TupiNUMBooR]

I almost wrote a great story of beating this problem.

Unfortunatelly, solution was wrong.

But i noticed that, if i use window mode or second monitor, i can alt-tab out of game, then ctrl+click on work column and it behaves correct.

Just until you click something else in game, then you will have to alt-tab again.

It might be that I'm checking for modifiers in the wrong part of the UI loop

Maybe then try other places for checking modifiers?

Or maybe make it just with rmb or mousewheel?

[ishigoemon]

I seem to be having luck using ctrl+alt+lmb on Fedora 28 w/ X11. (Not using wayland, no clue if it matters.)

[CharonIDRONES]

I can also confirm that Ctrl+Alt+Click works on Debian Jessie with Gnome, but Ctrl+Click itself does not work.

[Ospish]

Fighting with this issue on ArchLinux with XFCE as desktop environment. No Unity. Clicked with Ctrl sucessfully only once from other window, tried afted reading TupiNUMBooR's Mar 29 comment. WorkTab 2.7.153, RimWorld 0.19.2009. UPD: Ctrl+Alt Click works now. It didn't before, I'm sure of that. Not sure what helped, though. :(

[Mehni]

I've noticed this just now on Windows. Completely clean install, no configs file. Ctrl + click doesn't work.

Until I hit "expand". Once all have been expanded and collapsed again, I can Ctrl+click individual expandos. Hope that helps narrowing it down.

[HellishINC]

@Hsipso Did anything on your end change? Distro? Xorg? libinput? Since you're running XFCE it's safe to assume you're also not using wayland?

[Ospish]

No, I don't remember changing anything substantial. No Wayland either.

[jlucas721]

Libinput should implement ctrl-click as a secondary mouse click (right-click for us right-handed folks) for any single button trackpad or mouse.

I installed eOS Juno on a 2008 MacBook 3,1. This laptop has a trackpad for navigation and a single button to click. The only way to access a context menu or other right-click function with the current version of libinput is to turn on Tap-to-Click and use a 2 finger tap. While this is workable, Tap-to-Click can generate many unexpected events when touching the touchpad is interpreted as a tap (for instance, 2 finger scrolling may be interpreted as a 2 finger tap). I consider this a usability bug.

It would be better if Tap-to-Click is disabled and that libinput would process a click with the Ctrl key pressed as a secondary click (ie right-click). This is the way it is done on OSX/MacOS. I think it would be safe to make this the default behavior but a toggle could be added to the touchpad control panel applet to be safe. I hope someone can figure this one out.

[jlucas721]

It does appear that not implementing ctrl-click for a secondary click is an Ubuntu design decision. I think relying on two finger tap-to-click is a less than ideal method especially for systems using apple style single button touchpads. Ctrl-click would work better. However, an acceptable work-around is:

In touchpad settings turn off Tap-to-click.
In Universal Access settings turn on Hold primary button to trigger secondary click.

A quick click will act as usual but click, hold, and release will generate a secondary click.