-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent long press right click #4
Comments
Hello Zyell! How are you! I can see you are back from holidays! Hope you had a good time. |
Hello! Thanks! My vacation was incredible! I truly enjoyed it. :-) No worries, I have tried pymouse. I still have the same behavior I described above with one more inconsistent behavior. With pymouse if I go to long press a window that isn't in the main focus, the right click occurs at the edge of that window no matter where I press... But in order to solve the inconsistency in not bringing up the context menu, I tried initiating a left click immediately before bringing it up. This works perfectly. I thought it might have to do with movement of my finger, but no movement was detected, so very strange. Regardless, now it brings up the right click menu consistently using the uinput and pymouse. But, I cannot click on any items in this context menu... The double tap right click is not affected by this problem. So I looked into what was happening during the long press that is different. When a touch event is started a BTN_TOUCH KEY_EVT is fired with a value of 1. When you remove your finger, the same event is fired with a value of 0. During the double tap this value of 0 is fired in tandem with the right click. During the long press this happens noticeably after the right click so that the menu comes up while your finger is still on the screen. With the grab and ungrab required to keep this menu from closing, this last event isn't fired. It seems then that the system thinks you are still touching the screen, making the right click context menu unclickable. I've tried firing this event manually and I can't seem to make it work yet... I need to test on my other laptop a bit as I've only worked on my dev laptop recently. But, do you see this issue during a long press? |
Well it doesn't look like the BTN_TOUCH event is the culprit after all... Back to the drawing board! lol. |
Good morning! Well , here i go with my machine (all tests with pymouse, not uinput). About the bug that right click menus appear on the edge of the window: i was not capable to reproduce this bug. No matter how many windows i have open, right click always steal focus, brings the "touched" window in front and right click is injected. About Nautilus bugs, i can confirm the bugs you describe in my machine. I noticed that sometimes you can right click on an item but not on user spare (free space around folder and files within Nautilus) By firing a left click before right click, on the very first time nautilus right click works in files/folders but after first click on userspace then i was able to bring context menu in user space but all items (folder/files) became non clickable (either by left or right click). Further Thoughts: |
Good Evening Zyell! |
Moreover, Caja of Mate, has the same behavior as Nautilus. It seems that the bug affects GTK. |
Hello! I have been preoccupied lately, sorry, but I did do some additional tests. I found that the original implementation worked just as well as the two finger tap does. The issue is definitely related to the menu coming up while holding your finger to the screen. Also, I have seen the same behavior, that the files and folders work just fine, but the rest of the area within nautilus and the desktop fails to work. I am working on isolating what events are not being fired during the long press that are being fired during the two finger tap. Hopefully I can find an effective way to inject those into the system and fix this issue. You might be right that it is some quirk or bug of GTK... I hope to get back to testing in the next few days. Thank you for investigating this further as well!! |
Hello, First of all i have to point out that script behavior is different within Nautilus if you inject a left click before right click. Classic setup (no left click injected before right click) In this case the "bug" is related to Nautilus itself. The same more or less behavior happens on touchscreen touch evens. The super sensitive touchscreen emits ABS-X and Y change, which is actually considered to be like a "left click drag". A lot of users have been complaining about this Nautilus behavior, but nautilus teams has classified this bug as "won't fix". See this bug report: It is possible that this behavior applies to all GTK3 apps. I tested Caja and Nemo WM, and both of them behave like Nautilus. You can NOT have right click context menu while you are pressing left click and while you are dragging. On the other hand, In my XFCE Desktop (tested even using my touchpad), i am able to perform a long left click (like dragging) and as soon as right click is pressed (either in touchpad or by script), desktop context menu pops up , pausing (not cancelling) the left click action. Alternative setup (left click injected before right click) Remarks More precisely , you can see context menu of Nautilus files/folders with long press (no finger release), but on nautilus user space this is not possible since right click and left click together are not allowed. You can give yourself a try to the right click tester script if you like : How To test: Test with regular mouse or touchpad: Conclusion: Or we just need to redesign the script, but i can not figure out in which direction... |
Update:
By disabling the screen for some milliseconds i disconnect left click from Nautilus "on the hard way" and thus right click menu appears ok in Nautilus surrounding space. Actually with this hack, right click menu appears everywhere without problem. For sure this is not the right way to do coding, but it works... |
Hello Michael!! |
Hello!! Sorry, work has been crazy going into the holidays! I've been investigating a way to inject an end to the left click and drag prior to initiating the right click, but I haven't found a way to do this just yet. Looking at the events fired from evdev, this looks to be the issue. I'm just not sure at this point how to inject that. Your test for disabling the touchscreen is brilliant and confirms the issue is definitely the lack of completion of the touch event (recognized as a left click). You may be onto something with pursuing pyGTK. I'm not familiar with it, but it might be possible to inject an event. I've been trying to go through evdev, but I just haven't gotten very far with it. In the meantime the subprocess call at least works and I can't find any adverse effects. I need to clean up my code and upload here again where we stand on this. I will allow two paths for the long press to work as it once did, and using the workaround you found. I am in the middle of changing jobs right now, plus the upcoming holidays, but I will aim to get some better testing in before the end of the week! If you want to do a pull request with your testing scripts that would be great. We can start a section for testing. :-) |
…d long press workaround option from Issue #4 Thanks @gevasiliou !!
Hello! No worry about delays! We are all busy with our morning jobs and normal family business,.. About pull request, is not necessary... You got the idea, you implement it in your project, everything is fine. The only point that i would finetune in your revised code is on the subprocess call . We call xinput disable/enable only for ELAN. Maybe we should write this as:
Just to extend this workaround even in ATMEL screen and not just to ELAN. Further fine tune of script's code:
In this way , users can call the script by command line combining --pymouse (or -pm) and/or --nofingremove (or -nfr) switches (in any position). If no args are given, default values are used. We can in the future extend the args list to --tray/--notray, --touchtolerance , --calibrate , --debug and so on. If you like the idea, feel free to use part or all the args code above in your script. |
Hello! Thank you for pointing out the inclusion of the atmel device name in the workaround. I just have it use the name of the current device now to handle this generically. I have also added the command line options using the argparse library in Python. It makes handling all sorts of argument options really easy! We can easily extend it in the future. Thank you for pointing out the error and recommending the command line options! I am still looking into another option besides disabling/re-enabling the touchscreen for the long press... I'll let you know when I find something. Thanks for your help! |
Hello! |
Hello! That is a great library btw. I have used it elsewhere, but I hadn't thought of using it here, so thank you for the recommendation. Unfortunately, it didn't work... So I'm still looking! I'm continuing to dig through more detailed output from xinput and evdev. |
Ok, It just worthed to be tried :-) . By the way, i don't know if you will be able to find something usefull inside xinput/evdev signals, since this behavior is a kind of Nautilus feature and not xinput/evdev bug, a behavior that can be reproduced with a regular mouse (impossible to inject a right click inside Nautilus user space while draging = while mouse left click remains pressed). If we are lucky we might find a library that will be correctly "steal/grab" the device from Nautilus and that could be possibly a solution. Unfortunatelly the device.grab feature that we tried in the past was not sufficient, and the xinput disable method is a kind of ugly workaround.... I'm facing a different issue now with your script, and i would like your help to find out what is going wrong. How i could grab the error messages that cause the whole thing to break (terminal and rightclick.py)? If i run the script with -pymouse flag only i got a bit better behavior but still after some time of normal use rightclick script is interupted (but terminal is not closed) and i see some errors related to x imported libs (obviously imported by submodules). Sounds like X bugs by recent X11 upgrades... I have to sent you the output for this pymouse case but i would like also to find out what is wrong with uinput usage which terminates script and terminal window. |
Long press right click does not always bring up the context menu when clicking on desktop and in nautilus. Furthermore, when it does bring up the context menu, the items are not then clickable via touch. Double tap succeeds in all contexts. Long press without brining up context menu while pressed succeeds. Issue must be in the grabing and ungrabing of events.
The text was updated successfully, but these errors were encountered: