fix a crash hapenning since updating Ubuntu 18.04 #10
Conversation
Depending on which C++ standard library headers have been included there might an abs(float) function already declared in the global namespace, so the definition in this file conflicts with it. This cause a build failure with GCC 7, which conforms more closely to the C++ standard with respect to overloads of abs. Including <cmath> and adding a using-declaration for std::abs ensures that the standard std::abs(float) function is available. This solution should be portable to all compilers.
…ll allow mtrack to be used with easystroke
French translation update
switch from fork to g_spawn_async
Remove abs(float) function that clashes with std::abs(float)
Remove unnecessary requirement for device to be absolute
|
wow, cool! thanks for working on easystroke! |
|
Yes! Thank you very much for working on easystroke! It is my absolute favourite! ... And since I heard, that it is not running on Debian Stretch any more ... I'm afraid to upgrade. I can not imagine having a system without easystroke. The KDE-Gestures are not nearly as good as easystroke. Thanks again! |
|
hmm, looks like the package was orphaned and removed from debian which is a pity, does not even show up here: https://pkgs.org/download/easystroke other distros still have it though, it's still in ubuntu! I will try to look through the source packages the maintainers use, maybe there are more fixes the package maintainers already did. As things look right now, somebody would need to step up and care about easystroke, its a software which has no real counterpart or replacement (on Linux), it's unique. I will try to attract some developers via reddit, let's see what happens! edit: Jonathan Wakely [email protected] has made some nice patches made for fedora: gcc 7 support, boost 1.66, gnome3 fix... so this looks great! |
|
Thank you revast! ... That is wonderful of you! |
|
Me neither, I can apply patches and such, but then it ends mostly. Well, reddit is a good place to poke around and attract people, there is even guys actively searching a project where they can contribute. It would definitely help if you would write something to reddit (r/linux r/opensource ..., be it an article about easystroke to praise its benefits, or a call for developers. I have now looked into the patches arch provides, too, so it would be nice to collect these patches, sort out the dupes, and make a new pull request here for a starter. unfortunately the original author does not seem to be active any more. I will still try to contact him though. Then, if you look around here on github, there is also some interesting stuff: a patched, semi-maintained version (!) I think I will try to contact hThoreau first.. a port to OSX: multi touch support: and some more repos with fixes. |
|
Wow! Thank you once more! I am glad, I am not the only one loving easystroke! I honestly do not understand, why not everyone is using it. The only reason I can come up with is, that most people simply don't know it and the luxury it gives you. |
|
yeah, spreading the word is definitely needed! Maybe it's also a good idea to make a video how it works (or some animated gifs), I guess most people don't get it by a mere text description. As I said before, it would be cool to add all the patches to one place, maybe its best to make pull requests to hThoreau's repo. He only has added one patch till now btw. Also, it would be very cool to share the configs. I use it since 10 years, so I think I know how to use it most efficiently, but maybe you or somebody else have found a better way I am not aware of? not all gestures work in practise, some are too similar etc.
|
|
You wrote: "As I said before, it would be cool to add all the patches to one place, maybe its best to make pull requests to hThoreau's repo. He only has added one patch till now btw." I'm not familiar with this kind of stuff. Can you add all the patches to one place and make such a "pull request"? ... And would this in the end bring easystroke back into the official Debian-repos? And hey my friend, I have good news for you! You can pimp your easystroke quite a bit further, if you want! I realized, that it's kind of inconvenient to use something other than straight lines. For instance your "W" for the web-browser. Takes IMO to long to draw. And that’s why I use time-out-gestures, where you don't release the button at the end of the gesture (marked with an "x" in my list). "4" and "5" is pressing the gesture-button and scrolling up and down for the system-volume. The rest are mainly little scripts with a wmctrl in it, to bring up those windows, e.g. "wmctrl -x -R dolphin.Dolphin". But my absolute favourites are the "minimize" and "un-minimize"-gestures. Just wipe down to minimize a window and wipe up to un-minimize, i.e. bring it back up. The "un-maximize"-gesture is for keeping the window on the screen but maximize and un-maximize it. The xcalib-gestures are for screen-brightness up and down. And BTW, your "copy and paste" ... With synchronized clipboards a middle click is enough for both.
|
|
ok, I think you have to make some video, I don't get it how you use it ;-)
Pull requests are no rocket science, they a part of how to deal with software using git. (we are here on GIThub ;-) but this also works on gitlab) The idea of git is, that when using it, everyone has the whole code of a program as local copy. Now if you change something, and do NOT have direct access to the repository, you can make a Pull Request, and this request then shows up in the Pull Request section (in that we are writing right now, because THjaeger does not have the Issues activated) of the repository. It shows the differences between the versions as diff files (the attached files, "commits" on top), and estimates if the changes are compatible with the master version in the Repository. So if you happen to have curiosity about git and maybe patch, I would bet you'll gonna figure out this in a day. Now about the Debian repository: that is another beast in terms of investment of time. Packages in Debian are just accepted if there is a Maintainer. This maintainer has to be registered, and go through the whole process of getting the package accepted, so no simple upload and done.. He has to deal with all the Bugs he gets reported, eventually send them upstream to the original developer, take care of maintenance about the packaging mechanism of Debian, because things change here also, get deprecated for example.. (they have rather strict rules, and use software, which controls that these rules are followed ("Debian policy, Linitian") )And you gonna have to do this for ALL supported platforms, and these are a LOT. But Debian also has something like a "Waiting List" ("needs Packaging") where people can request that a software they love should be included into Debian. But this just happens if somebody or one of the Debian maintainers teams steps up and takes over the job. This "Waiting List" especially is filled with software where there is no proper Debian source packaging in place, which is NOT the case with easystroke. So with easystroke, we could just package it up (including the patches, because Debian source packages have an mechanism for that, too), go through the registering process at Debian, and send it to review for inclusion. Not a piece of cake, but not so much work as when starting from scratch. The documentation is also quite fractured, so the most important links would be: Guide for Debian Maintainers So while this is a good idea, it's now best to get easystroke back in terms of being maintained at all, and deal with the packaging afterwards. Its good to see that on other distributions, easystroke is still included, that gives hope that we can get it into Debian as well. As I can tell for sure, unmaintained software gets removed fast from Debian, so taking care of this would be priority number one. Next would be to make it more popular, as it seems many people do not know what it is capable of. |
|
Ok, just a quick reply regarding time-out-gestures: In the easystroke GUI you go to the "Advanced"-Tab and enable time-out-gestures. And then ... when you record a new gesture ... you draw the line with the gesture-button pressed. Only that this time you do NOT release the button at the end of the gesture, but keep it pressed down. That*s all! The rest of your post I need to read again and try to understand. |
|
I have now written a mail to THjaeger, lets see what happens. It would be great to have all efforts bundled in one place, without forking it to another repository. Then we also would for example not have to deal with the maintainers of the distribution packages which would have to be contacted if a new maintained repository is established, and the google search also would have to link to the right repository. What I also have recognized that there is also the old easystroke project on sourceforge, and people are still writing bug reports into the mailing list there.... what would not be the Problem in the first part, but the sourceforge page is also still #1 hit in google search... So if THjaeger answers, I would also request him to delete or update the sourceforge page to point to github... By the way, the Wiki here in this Repository is editable, so if you happen to have something you would like to add, feel free to do so - for example documentation about time-out gestures! I found that user dragon788 edited the Tips and Tricks page last year. As for my gestures, I tried to make them as obvious as possible, because they are also part of the default install of a Linux distribution I make. |
|
I'll try to put all the patches I found here, just for reference: First, the ones from this Repository:
Then, the ones from the Distributions: Distribution package status: Great overview of where easystroke is packaged:
It's strange BTW that the package is maintained in Ubuntu, but TOTALLY absent in Debian, i will ask the Ubuntu maintainers about that.. maybe there is a quicker way of getting it back to Debian... Debian easystroke related discussions:
the others from pkgs.org are just repeat.
others: from the forks:
In my quest I also found this: This guy has made a bridge from easystroke to osc: I have now also opened an issue at https://gitlab.com/hThoreau/patched_easystroke, asking for opinion, and will try to add the patches which make most sense, there. If that does not work out, of the forks on github, https://github.com/markdstjohn/easystroke/commits/master has the most patches applied. |
|
for the non-tech savvy, here is an already built quick package from Git Master plus these patches: easystroke_0.6.0-0ubuntu8_amd64.deb for people who do not want to install packages from outside the debian packages mechanism,or people who use other distributions, I also provide the already patched sources with the used patches: unpack. Let me know if this works ;-) |
|
Hi dkondor, please see my edit above - that's why I wrote dirty hack ;-) I just tried again with wayland and gestures are recognized, although the displacement issue occurs there even with the original display scaling. As far as drawing modes involving compiz are concerned, they won't work for me. Enabling dbus plugin in compiz will make compiz fail, so that's not an option. Currently the only drawing method working for me is "Default". Cheers, |
|
Hi @roooots, I've added a branch to address this: Unfortunately, this only works with integer scaling factor. I haven't yet found an API that returns a fractional scaling factor (and I'm on Ubuntu 18.04 where I can only set integer factor anyway). I'll try to look into this a bit more. Also, it needs more work to handle different monitors with different scaling factors separately; currently, it uses the scaling factor of the primary screen for everything. Nevertheless, it would be great if you could test it and report what your experience is. Thanks for the note on Wayland -- I'll experiment with that as well :) Regarding compiz, there are possible multiple issues with dbus and a separate issue with the annotate plugin: Some of these are fixed in the launchpad git master: I don't know when these will make into Ubuntu packages, but you can experiment with them as well :) |
|
@roooots I've created a PR related to your issue: I suggest to continue discussion there, since we do not have an issues page for easystroke :) |
|
Thank you guys for working on this!
<3
Am 19.06.2020 um 07:11 schrieb Daniel Kondor:
…
@roooots <https://github.com/roooots> I've created a PR related to
your issue:
markdstjohn#8 <markdstjohn#8>
I suggest to continue discussion there, since we do not have an issues
page for easystroke :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKWWPLP3RJCHASMI47EVTB3RXLXPLANCNFSM4FWVGGWA>.
|
Yes, thanks for continuing to work on this! I am having a "crash" problem with easystroke that causes KDE to go to the login screen. The Xorg logs don't seem to have any info. Would the patch for compiz fix this? Would someone else's github page be a better place to comment? |
|
Hi @jschroed, Regarding your problem, it might be a difficult one: normally, any bug in easystroke should not crash the whole desktop, so probably you are facing a bug in X or your window manager that might be triggered by easystroke. I suggest the following steps:
These steps could help isolate where the problem is. In case the crash keeps occurring regardless of window manager, it can be a bug in the X server. In this case, it might be worth reporting at the relevant page for your distribution. If it is easy to reproduce with easystroke, maybe I can help creating a simplified test case demonstrating the bug. If the problem seems to be related to compiz, this is my experience so far with the bugs I mentioned:
To use any of these patches, you would need to compile compiz from the launchpad git repositories. I don't really have experience how to make a binary package out of them There could be other problems as well. Your experience may be improved if you enable the Crash handler plugin (under 'Utility' in CCSM), that can have compiz restarted (or an alternative window manager started) if a crash happens instead of logging you out. |
|
Hi dkondor,
Creating a simple test case might be the best option but there could be an Xorg fix that prevents the crash that Arch has that KDE Neon (Ubuntu based) does not have. I suspect that there is something that easystroke is doing that it’s quite right that is causing the problem. (I know there is multi-monitor issues with easystroke.) Edit: Fixed the crash in KDE NEON by installing "xserver-xorg-hwe-18.04". KDE Neon uses X.Org X Server 1.19.6 by default. With the HWE package, the version was 1.20.8 and did not crash (but still had the disappearing cursor issue). 1.20.8 is the same version I have installed in Arch Linux. I added a bunch of printf debug statements in easystroke but couldn't find a cause. I couldn't find anything that easystroke was doing wrong. The problem happens after grabbing a button "XIGrabButton" while the active window was the System Tray and then right clicking and moving to another monitor. It seems that the XIGrabButton does a passive grab and waits for state changes to be reported. The crash then happens while waiting for things to change (e.g. button press or window change). The glitch/crash could just be a bug with the X.Org XIGrabButton function. I'm open for suggestions for investigating but it's less of an issue since it's not crashing. More logging/debugging with easystroke and X.Org could be done. Otherwise, a simpler executable could be created that causes the issue and reported to X.Org. Bisecting X.Org might be difficult but reviewing the release notes again might reveal something. (I may spend less time on this now that it's just a glitch instead of a crash.) |
|
Hi, I'm on Ubuntu 18.04 with the HWE Xorg (1.20.8) and GNOME, and don't see any of the problems so far. I remember other, completely unrelated cases of the mouse cursor disappearing randomly, so there could be some general issue in the X server regarding mouse and grabs. I would say, we might regard the crash as an Xorg bug that was fixed in the latest version. For the disappearing cursor, it would be great to investigate if this is an issue in easystroke or in the X server or with KDE. I'll install the KDE packages and experiment when I have a bit more time. Based on what you say, in the disappearing mouse case, could it be that easystroke starts a grab and then does not "ungrab" properly? At least for me, the normal behavior seems to be that easystroke hides the cursor during drawing the gestures and it reappears only after that. |
Yes. KDE on Arch Linux as well. (I have only tested on KDE installs.)
It seems to me that the passive grab that easystroke is valid. It is as if easystroke sends a request to Xorg to "let me watch the mouse cursor". It is while in this state that the mouse cursor disappears (or Xorg crashes in earlier versions). There does not seem to be anything actively going on with easystroke while in this state. Another thing that we could try is to recreate the issue with a new program. Like you suggested earlier, a simple program that calls the grab function might worth investigating. |
|
It such a good feeling to see you guys care about Easystroke!
Unfortunately I can not contribute to such technical issues, other than
saying: Big big Thank you to you!
:-)
Am 07.07.2020 um 17:58 schrieb jschroed:
…
Hi,
thank you for the detailed explanation. Just to confirm, on Arch
Linux, are you using KDE as well?
Yes. KDE on Arch Linux as well. (I have only tested on KDE installs.)
Based on what you say, in the disappearing mouse case, could it be
that easystroke starts a grab and then does not "ungrab" properly?
At least for me, the normal behavior seems to be that easystroke
hides the cursor during drawing the gestures and it reappears only
after that.
It seems to me that the passive grab that easystroke is valid. It is
as if easystroke sends a request to Xorg to "let me watch the mouse
cursor". It is while in this state that the mouse cursor disappears
(or Xorg crashes in earlier versions). There does not seem to be
anything actively going on with easystroke while in this state.
Another thing that we could try is to recreate the issue with a new
program. Like you suggested earlier, a simple program that calls the
grab function might worth investigating.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKWWPLIWFSRPLVEVCOGA2J3R2NA23ANCNFSM4FWVGGWA>.
|
Some observations regarding the disappearing-mousepointer-issue. I am using the right mouse button for initiating gestures and I am seeing the same behaviour of the mouse pointer disappearing if I use the right mouse button to open context menus of applications. However, not all applications are affected, which could give an indication for further debugging. The bug occurs with nautilus and caja (the latter is handling my desktop); it won't occur if I right-click on the contents (!) of a document openend in libreoffice, a text file opened in pluma or the contents of a mate-terminal, but it will occur if I right-click on the menu bar of these three applications. The pointer usually won't disappear instantly, but after what I measured to be roughly 2-3s. Rarely, the pointer does in fact disappear almost instantly, while in other rare cases it will disappear after roughly 5-7s. With my testing, it will only reappear if:
As with disappearing, reappearing does not happen instantly but after roughly 1s after one of the above triggers has activated. I've discovered something even more interesting, which is reproducible: On an empty (that is, free of windows) desktop, open a mate-terminal and execute
where x and y are screen coordinates on the desktop of a point outside the current terminal, that is, on the "bare" desktop without any additional windows and "3" is button no. three, that is my right mouse button. What happens is: The mouse pointer jumps to the set location and the right-click menu pops up. A first, the tip of the mouse pointer is situated a few pixels below and right of the top left corner of the right-click menu. After roughly 2-3s (with that same exceptions as described above) and without any further user action, the pointer will jump a few pixels so that the tip is now located exactly at the top left corner of the right-click menu. However, although easystroke is running, the pointer won't disappear! I currently don't have any idea how that relates to the bug we're discussing here, but the similarities in terms of delay are obvious. By the way: the bug occurs no matter what "Method to show gestures" I am using, so using dkondor's patched compiz and setting easystroke to use compiz' annotate etc. doesn't make any difference. It won't occur when using the middle mouse button for gesture drawing. Maybe my observations will spur some ideas how this can be debugged... Cheers, |
|
Hi all, here's an important update on the disappearing-mousepointer-issue: At least with my setup it appears to be specific to Radeon/AMD GPU and corresponding drivers. I did not encounter this issue when using the IGP of my Intel CPUs during the last years. Yesterday, I switched from an AMD to a NVidia GPU and the issue does not appear anymore. It would be great if those affected by the bug would give a short feedback on what GPU & drivers they are using. So maybe next steps would be trying to figure out to what extent the Radeon driver itself affects this issue. That is, if there is any difference between using the mesa vs. the proprietary AMD driver and if driver versions do have an effect. I also suspect this issue to be X-specific, so it would be helpful if anyone would give a quick test with wayland a go. @jschroed: Did you check Xorg.0.log for any meaningful warnings or errors that might give a hint on possible conflicts? Cheers, |
Good thinking. I have AMD on my desktop machine with Arch. It's a really old unsupported card. (I have an Nvidia card and a newer AMD card that I could try but I probably won't get around to it.) I believe it is using Mesa since from what I've heard the proprietary drivers have been discontinued. Laptop (KDE Neon):
Yes, I checked the Xorg.0.log but there wasn't anything in there that seemed related to the crash. There wasn't anything around the time of the crash either. I didn't check the log extensively but I didn't see anything when I did look. |
Revert back commit c328ef3 -- it makes things worse for me
With this patch applied, I also very rarely (once every few months) encounter gesture-related crashes. I couldn't tell if it was at the start or end of a stroke. I think it even was just a regular click of the gesture button. Either way, it doesn't seem to be fully fixed just yet. |
|
Right, just had another X crash. It happened at the end of a stroke. |
|
Hi all, |
|
I really wonder why not anybody take over this project?! As it's I really love easystroke and use it since years now... would be a pitty to have such a cool piece of software abandoned. |
|
I absolutely agree and because my coding skills are very limited, I would be willing to contribute via a donation aimed at providing sufficient supplies of coffee, beer and chocolate. I'm serious about that! |
|
Yes, please, don't let this wonderful tool vanish!
Am 22.11.2021 um 18:22 schrieb roooots:
…
I absolutely agree and because my coding skills are very limited, I
would be willing to contribute via a donation aimed at providing
sufficient supplies of coffee, beer and chocolate. I'm serious about that!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKWWPLKAEPIBTFBUQYIK3O3UNJ36TANCNFSM4FWVGGWA>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
In my opinion "https://github.com/berkeleybross/easy-gesture" seems to be still pretty active with a fork of easystroke. |
|
EasyStroke makes my life so much easier, at work and at home. I love setting up keyboard shortcuts so my hand never has to leave the pen (tablet). |
|
After the "easystroke-git" in AUR triggers a successful action, it will cause the meta key in KDE to fail. You must click the trigger button again. I use manjaro and plasma 5.24.5 I can't fix it. I hope these feedback can help you aur中的easystroke-git在触发成功一次动作后,会导致KDE 中的meta键失效,必须再次点击一下触发键,我使用的是manjaro 和Plasma 5.24.5.我没有能力修复它,希望这些反馈能帮到你们. |
maybe try https://github.com/berkeleybross/easy-gesture, its an actively maintained fork. If you encounter the bug too, raise an Issue there. |
|
FYI I've created binary packages for Ubuntu with the patches that work reliably for me: |
你在干什么?? 瞎回复啥呢? 账号被盗了? |
1 similar comment
你在干什么?? 瞎回复啥呢? 账号被盗了? |
Since updating my laptop to Ubuntu 18.04, easystroke keeps crashing. Running it in gdb shows that the crash happens in Stroke::drawEmpty_ (win.cc:143), because it gets called with size == 0. The size in question comes from the tray icon's size, as it is called from Win::set_icon() (win.cc:280). For some reason, icon->get_size() there returns 0 (even though there seems to be a valid tray icon). This then results in the crash later.
Simply testing if the icon's get_size() returns 0 and skipping the icon->set() call if it does seems to fix the problem for me with no other adverse effects.