move pinned apps has no threshold

[stefan123t]

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

[stefan123t]

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, Stefan

[ghost]

Yes this is annoying... do you test if this happen on the dev branch?

https://github.com/jake-phy/WindowIconList/tree/develop

[stefan123t]

Salut Lester,

Thanks for your hint. I will try the dev branch tomorrow. I have checked the master branch today.

Kind regards, Stefan

Sent from my iPhone

On 13 Apr 2015, at 20:14, Lester Carballo Pérez notifications@github.com wrote:

Yes this is annoying... do you test if this happen on the dev branch?

https://github.com/jake-phy/WindowIconList/tree/develop

— Reply to this email directly or view it on GitHub.

[stefan123t]

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 ? Though disabling Show thumbs had no impact on the NetBeans IDE window icon, maybe thumbs are simply delayed due to the drag behaviour =^/

Kind regards, Stefan

[stefan123t]

I just found out that NetBeans IDE is unable to be pinned. Could be because I added a desktop file to my panel for starting it.

~/Desktop $ cat NetBeans\ IDE\ 8.0.2.desktop [Desktop Entry] Comment=The Smarter Way to Code Terminal=false Name=NetBeans IDE 8.0.2 Exec=/bin/sh "/media/Storage/netbeans/netbeans-8.0.2/bin/netbeans" Type=Application Icon=/media/Storage/netbeans/netbeans-8.0.2/nb/netbeans.png

Could it be that I am seeing a problem with user desktop starters being referenced by WindowIconList now ?

Kind regards, Stefan

[stefan123t]

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. I think cinnamon now gets bloated and maybe even restarts itself, how can I trace that ?

Here is a screenshot of the problem with NetBeans IDE icon.

Kind regards, Stefan

[stefan123t]

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: Description-en: data abstraction library based on GLib -- GObject Introspection libgda is a (relatively small) database abstraction/access library integrated on the GLib object model. It can be used as a metadata extractor, to get information about all database objects in a common way, and as an ODBC-like wrapper to access data in different engines through an easier API. . This package contains introspection data for libgda.

Why would WindowIconList start gda or is this some bug ?

Kind regards, Stefan

[ghost]

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. I will see if is the problem is the cinnamon patch for the popup menu (to be open on the press event). Configurable Menu have a different implementation that not use this code.

[stefan123t]

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! Still it would be worthwhile to mention the GDA dependency in the release notes or readme and fix the long list of entries in the popup menu!

Kind regards, Stefan

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).

[stefan123t]

I was shouting too early, the issue still occurs. I will wait for the results of your try without the cinnamon patch, i.e. popup menu (press event).

Cheers, Stefan

[ghost]

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. But see i have a lot of things to do, i don't know when i can, but i will try. Thanks also to you for track the problem, and found the possible cause.

Regards.

[stefan123t]

Dear Lester, thanks for your update. Would you mind pointing to the part of code where you evade the cinnamon patch and what you do to circumvent it ? It is my understanding of the cinnamon patch that the applets need to take care of the inverted logic too. Kind regards, Stefan

[ghost]

https://github.com/lestcape/Configurable-Menu/blob/master/configurableMenu%40lestcape/applet.js#L6704

[stefan123t]

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 linuxmint/Cinnamon@27d0c9c linuxmint/Cinnamon#3109

@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, Stefan

[ghost]

@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: https://github.com/jake-phy/WindowIconList/blob/master/WindowListGroup%40jake.phy%40gmail.com/specialMenus.js#L406

[ghost]

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.

[stefan123t]

Dear Lester, the cinnamon issue #4044 (https://github.com/linuxmint/Cinnamon/issues/4044) I opened has some update from Cobinja: The applet uses a timer to show the preview window (which is also used to display the app name when no app instance is running). The issue is that during the menu opening process, the mouse button release is not handled properly, so the applet thinks that the button is still down, and starts the dragging. It's a regression introduced by 0b7cbf8

@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, Stefan

[ghost]

@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.

[jake-phy]

Hi fellows. are these bugs still happening? I have risen from the dead per-say and want to finish this app out.

[ghost]

@jake-phy yes this bug, can happend, but rigth now only in some context. Please see: https://github.com/linuxmint/Cinnamon/pull/4279

And see the comments here: https://github.com/linuxmint/Cinnamon/issues/4044

[jake-phy]

So i have been not been able to duplicate this no matter what i tried.

[ghost]

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: https://github.com/linuxmint/Cinnamon/blob/965179a87e05be8fa610b579863f90601f1ecce1/js/ui/popupMenu.js#L1481 in this way:

    on_paint: function(actor) {
    },

and also remove this line: https://github.com/linuxmint/Cinnamon/blob/965179a87e05be8fa610b579863f90601f1ecce1/js/ui/popupMenu.js#L1453

[jake-phy]

Ok but if I don't need to override the on_paint function, I should be good right?

[ghost]

@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.

[jake-phy]

Alright I'll do some more testing. So far I haven't been able to make it work.

[jake-phy]

Alright so I have figured out how to consistently duplicate the problem. Working on the fix.

[ghost]

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.

[jake-phy]

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.

[ghost]

Thats good.

[jake-phy]

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.

[ghost]

@jake-phy https://github.com/jake-phy/WindowIconList/blob/5e67bffd97c87dadbbae13a8b6ab7680a1a56119/WindowListGroup%40jake.phy%40gmail.com/applet.js#L317

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?

[jake-phy]

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

[ghost]

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;

[jake-phy]

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.