-
Notifications
You must be signed in to change notification settings - Fork 26
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
move pinned apps has no threshold #91
Comments
I tried to record something with xev > xev.log. As soon as I move over an icon in the WindowIconList, I can see the following in my xev.log, even without a button pressed. FocusOut event, serial 34, synthetic NO, window 0x3800001, mode NotifyGrab, detail NotifyNonlinear When I move the mouse pointer across the icons I do see the following which kind of repeats the sequence. FocusIn event, serial 34, synthetic NO, window 0x3800001, mode NotifyUngrab, detail NotifyNonlinear KeymapNotify event, serial 34, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 34, synthetic NO, window 0x3800001, mode NotifyGrab, detail NotifyNonlinear Could it be that the app automagically captures the mouse pointer for some reason ? Kind regards, |
Yes this is annoying... do you test if this happen on the dev branch? |
Salut Lester, Thanks for your hint. I will try the dev branch tomorrow. I have checked the master branch today. Kind regards, Sent from my iPhone
|
I have installed developer branch and I like the changes to the menus. However the problem is not fixed yet, though it seems to limit itself to one application window icon "Netbeans IDE 8.0.2" for the time being. Yesterday (using master branch) almost all application window icons, including Nemo, Firefox, Gnome Terminal and GEdit were impacted. This seems to correspond with my observation that the issue worsened over the day, when my memory and cpu usage increased. I am now able to cancel the drag using my ESC key (twice). When I am still over the NetBean IDE icon it will trigger the drag again. When I am outside the icon it will cancel drag, regardless of any other icons I might be over now. It does not trigger drag on other icons. Could it be that calculating the thumbs is somehow triggering this behaviour, because Gnome Terminal and Firefox have thumbs come up quicker in my observation ? Kind regards, |
I just found out that NetBeans IDE is unable to be pinned. ~/Desktop $ cat NetBeans\ IDE\ 8.0.2.desktop Could it be that I am seeing a problem with user desktop starters being referenced by WindowIconList now ? Kind regards, |
Bummer, now Firefox Icon also suffers from the problem again. Note: the screenshot replaced the mouse pointer (grabbing hand with link icon or x icon depending on position on window icon list applet or outside) with the default pointer. Actually even worse I can see plenty of Install GDA entries in the Firefox RMB menu. Here is a screenshot of the problem with NetBeans IDE icon. Kind regards, |
when selecting one of the "Install GDA" menu entries it will open a shell to execute the following command: sudo apt-get install gir1.2-gda-5.0; echo press enter and restart cinnamon; read n1 apt-cache has the following: Why would WindowIconList start gda or is this some bug ? Kind regards, |
Gda packages is used to provide firefox actions on the firefox window list menu and yes only is executed the debian installation type. if you have another different packages manager install the package your self. |
Dear Lester, I think the issue could be closed for the developer branch; since I have installed the GDA package it does not go havoc on me anymore. Thanks alot for the current developer version with its nice options! Kind regards, PS: Would you want me to open another issue for the pinning of applications using .desktop Starters which are not in /usr/share/applications/*.desktop ? I believe I have seen a similar issue for Cinnamon panel too. Funny observation is that these Window Icons are not grouped, here a self created .desktop Starter which I added to my panel for starting yEd graph editor (a Java desktop application). |
I was shouting too early, the issue still occurs. Cheers, |
I see that also this occurs on the cinnamon windows list applet... I'm using right now the default cinnamon configuration... The thanks is for @jake-phy, i only like his work like you and how i evade the cinnamon patch on configurable menu, i think that could be apply to this applet what i do, if this is the cause. Regards. |
Dear Lester, thanks for your update. |
I suspect it has something to do the way cinnamon acts on events. Here are some references to similar issues in Cinnamon that have been resolved: linuxmint/cinnamon#3116 @lestcape Lester kindly mentioned that it may have something to do with the way this is handled in Configurable-Menu which WindowIconList is derived from, am I right Lester ? lestcape/Configurable-Menu#50 Kind regards, |
@stefan123t, yes this need to be relate with it, but WindowIconList, don't implement the same of Comfigurable Menu, as i know... the problem is the number of things that windows list do with the popupmenu. Is difficult then find where we need change a behavior and why this problem occurs. Yes, the mouse press is the cause, but this not mean that we can not fixed the problem, just is more difficult. see: |
I suspect the possible solution is to call the parent mouse press after a while and not automatically to be sure that is the user intention. Currently what happens is that the mouse release occurs outside the actor and this causes cinnamon think that we want to move the actor instead. Another possible solution could be move the icons only when we go into a special state as having the panel of cinnamon(as example), but I think is to much and also i think that this problem have a solution, just i have not time. I'm trying to implement a global menu, and this required a big change on the cinnamon popup menu api. So, yes, if the problem is the popup menu i will fixed, but i think is more complex than that. |
Dear Lester, @lestcape, the description sounds fairly reasonable, as you already checked into the code mentioned above, maybe you can double-check to see what needs to be fixed in WindowGroupList ? Kind regards, |
@stefan123t You could test if the change could resolve the problem? If not resolve the problem, is because the problem is not in the commit that we thinking is, and could be another different bad effect of the changed of the mouse signal. I really can not test this for a long time, because all what i do will be affected with this change, so i need to stop the depveloment of what i'm doing to test this, and really i can stop this in this moment. Regards and thanks. |
Hi fellows. are these bugs still happening? I have risen from the dead per-say and want to finish this app out. |
@jake-phy yes this bug, can happend, but rigth now only in some context. Please see: And see the comments here: |
So i have been not been able to duplicate this no matter what i tried. |
See, if your applet popup menu is slow and inside the applet actor you try to capture the mouse release signal to do something, then your applet are a candidate to reproduce the bug. There are a way to prevent the bug and this is, not use the cinnamon general behavior, because in this behavior they eat the release event when the released was occurs inside the popupmenu actor. So, the solution that i use inside configurable menu is add a variable to store the popup menu state (isOpening), when a "mouse pressed" occurs inside the applet actor, I change the state of this variable (isOpening = true). Inside all items that have a release event i ask the state of isOpening. If isOpening is true then i don't execute the code and instead i change the state of the isOpening to false. When the release event occurs outside the items I also change the state of isOpening to false. This will be a warranty to not execute accidentally a code. To disable the cinnamon general behavior (because now the current applet have a way to control this) I override this function:
and also remove this line: |
Ok but if I don't need to override the on_paint function, I should be good right? |
@jake-phy of course, but you need to be pretty sure, because the bug occurs sporadically. Just only when the mouse is released inside the popup menu and this is not normally, because the popup menu need to be rendering in this current moment and just inside the mouse position. A thing that not occurs always. |
Alright I'll do some more testing. So far I haven't been able to make it work. |
Alright so I have figured out how to consistently duplicate the problem. Working on the fix. |
If you say a sustained click and then release the mouse over the popup menu, this does not work in general because the on paint event is like a clock. After two paintings is considered that if the mouse is released over the popup menu this was intentionally, so the release event will not be eat in this case. What you can see manually is just the effect (the idea behind), but this not mean that will be applicable, just will be if your popup menu is slow. |
Which the thumbnail is. If you click on the appbutton and drag up into the thumbnail you can cause it to eat the release event almost everytime and then appbutton will drag when it is hovered over next. I think I finally understand what is going on and how to fix it. |
Thats good. |
Alright this should be fixed. I did it a little unconventional but it seems to work good. Can you take a look Lester and see if you see any problem? The fix would be the _RemovePossibleDrag function. |
I really don't have time now. Sorry... See also Configurable Menu is out of cinnamon 2.8 and i have not time to fix it. I know how fix this problem permanently and if your attempt will not fix the problem let me try when i have time. Can you please show me where was your fix? |
Ahh yes thanks for pointing that out. Sorry the fix is: https://github.com/jake-phy/WindowIconList/blob/develop/WindowListGroup%40jake.phy%40gmail.com/applet.js#L418 |
Jumpp... You have a timer thats need to work ok on my opinion, just i don't understand pretty well how is working... I supposed that what is needed was a timer for return to the normal state when the applet or "any of his actors" have not the focus (something similar) but there are things that i can not see. I suppose you also need to capture the drag-end and abort the timer if you have not the focus. Also i don't know if really you need to check the focus in all childrens, and if is needed iterate over the childrens is not a good option, if you have a function to know that. The focus is a clutter actor, so you can use actor.contains(focus) thats will search if the actor contains a children actor, that is the focus. global.stage.key_focus give you the current actor that have the focus and is similar to global.stage.get_key_focus(); Also you have global.display.focus_window; |
I haven't been able to figure out the actor.contains(focus) but the drag is working good now. I'm going to close for now. |
Dear jake-phy,
I really love this app, actually it is my most used app throughout the day, besides the calendar/clock in cinnamon.
I have the problem that when clicking on the list I frequently get into move pinned app mode instead of opening/minimizing the selected app window. I know this may have to do with mouse and timing issues, so anything you can suggest that helps me to debug this annoying malfunction is appreciated.
Would it be possible to implement a special move pinned apps timeout in your app that only after holding the button for an prolonged threshold time the move pinned app action/event is triggered ?
Kind regards,
Stefan
The text was updated successfully, but these errors were encountered: