handle click events and modifiers

[ghost]

Currently, libayatana-appindicator only handles scroll events, and shows a menu on left or right click. pasystray uses middle-click for muting and ctrl+scroll/middle-click for volume-change/muting microphone. These work with GtkStatusIcon, but can't work with libayatana-appindicator (see pasystray#44 and pasystray#102). It would be useful to handle and transmit these events so that applications can have specific behaviors on specific actions.

[sunweaver]

@vblo: I have been on hiatus regarding Ayatana Indicators for a while. I am slowly coming back and will take a closer look at this.

Is it possible that the cause of this issue is not in libayatana-appindicator, but in the renderer (i.e. XFCE indicator plugin, mate-indicator-applet, etc.)?

The mate-indicator-applet in Debian recently received a patch for something like your issue:
https://salsa.debian.org/debian-mate-team/mate-indicator-applet/commit/59c7765b0184df27ebafa06c169d88ef11e03d5c

What renderer for Indicators do you use for testing pasystray? Please provide that feedback. Thanks.

[ghost]

Thanks for your time.

I can confirm that my renderer (wmdocker) is not responsible for the issue: the same renderer handles middle-clicks and the ctrl modifier when pasystray uses GtkStatusIcon rather than libayatana-appindicator.

The problem is that:

• scroll_event takes as parameter a GdkScrollDirection but not a GdkModifierType so there is no way to find out whether the ctrl key was pressed during the scroll event
• on a middle-click no distinction is made on the modifier keys that were pressed and the only possible action is to activate the menu item that was set by a previous call to app_indicator_set_secondary_activate_target

I'll try to make a PR so you see what would be needed.

[sunweaver]

On Mi 28 Aug 2019 13:34:07 CEST, vblo wrote: Thanks for your time. I can confirm that my renderer (wmdocker) is not responsible for the issue: the same renderer handles middle-clicks and the ctrl modifier when pasystray uses `GtkStatusIcon` rather than `libayatana-appindicator`.

Please note that rendering GtkStatusIcon is a completely different thing from rendering an indicator.

The problem is that: - `scroll_event` takes as parameter a `GdkScrollDirection` but not a `GdkModifierType` so there is no way to find out whether the ctrl key was pressed during the scroll event - on a middle-click no distinction is made on the modifier keys that were pressed and the only possible action is to activate the menu item that was set by a previous call to `app_indicator_set_secondary_activate_target` I'll try to make a PR so you see what would be needed.

Ok. Thanks. That will help tremendously. However, the different renderers (e.g. wmdocker) need to know how to handle that. I need to check if modifier keys are part of the SNI specs in the first place. We should not hack stuff in that is not part of the proto standard. Greets, Mike

…

-- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: [email protected], http://das-netzwerkteam.de

[ghost]

I just checked the specs and it seems that modifier keys are not part of it. However the secondary action can be anything, which would at least implement part of the second item.

[ghost]

Do you now where I should start if I want to suggest the addition of modifiers handling to the specs?

Cheers,
Valentin

[sunweaver]

On Mi 28 Aug 2019 15:11:53 CEST, vblo wrote: Do you now where I should start if I want to suggest the addition of modifiers handling to the specs? Cheers, Valentin

No, not really. It would have to be adopted by all SNI implementations out there. The KDE people started SNI, so maybe they might know which road to take on this. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: [email protected], http://das-netzwerkteam.de

[ghost]

Hi Mike,

I'm having a deeper look at the source code in order do make my PR, and I have a question.

The handling mechanisms for scroll events and that for secondary activate are very different:

• when an application wants to perform an action on scroll, it has to listen to the scroll-event signal emitted by libayatana-apindicator
• when an application wants to activate an item on secondary activation, it has to specify this item through a call to app_indicator_set_secondary_activate_target

is there a particular reason for this? Couldn't the two be handled the same way, i.e.: both through signals or both through setter methods?

Thanks,
Valentin

[farfromrefug]

@sunweaver would you accept a PR which add supports for this if it an opt in ? there are a ton of reports about this in major electron apps. And now that GTK StatusIcon is gone, libappindicator is the only choice. it is a major draw back in user experience to not be able to differentiate left and right click

[farfromrefug]

@sunweaver could we get an answer from on you or any other maintainer here? This is really important for any app.
Thanks

[Betterbird]

We're using libayatana-appindicator in https://github.com/Betterbird/thunderbird-patches/ now. For Betterbird/thunderbird-patches#111 we need to react to clicks onto the app indicator (the icon in the systray) which in our case doesn't have a menu. Sadly there is no way to get notified of such clicks.

We tried a few things, none were successful.

1. We tried to hook into status_icon_activate:
   

   libayatana-appindicator/src/app-indicator.c

   Line 1682 in f225dcc

   status_icon_activate (GtkStatusIcon * icon, gpointer data)

   
   That gets registered here
   

   libayatana-appindicator/src/app-indicator.c

   Line 1548 in f225dcc

   g_signal_connect(G_OBJECT(icon), "activate", G_CALLBACK(status_icon_activate), self);

   
   in fallback(). That function gets executed when using a simple test program like https://github.com/AyatanaIndicators/libayatana-appindicator/blob/master/example/simple-client.c, but it doesn't get executed when the library is integrated into Betterbird. Maybe that's because the simple test program runs the event loop. Betterbird of course has its event loop elsewhere.

2. With a timer we waited for AppIndicatorPrivate.status_icon to become populated to the attach a signal via g_signal_connect() to the GtkStatusIcon. This also worked in the simple test program but AppIndicatorPrivate.status_icon is never populated when run inside Betterbird.

Sadly we have very little knowledge about all this.

In comment #4 (comment) a now deleted user wanted to send a PR, but that hasn't happened.

So does anyone now how to gain access to the icon to attach a signal to it. The icon is created here

libayatana-appindicator/src/app-indicator.c

Line 2032 in f225dcc

"NewIcon",

but the call at

libayatana-appindicator/src/app-indicator.c

Line 2028 in f225dcc

g_dbus_connection_emit_signal(priv->connection,

seems to be async and we don't know how to get the icon it created.

Finally, @easyteacher, you helped us out in Betterbird/thunderbird-patches#20 (comment) after looking at libayatana-appindicator a bit, see issue #62. Maybe you can give us a hint.

Update 7th Feb 2023: Fixed wrong code references.

[lovetox]

Im maintainer of a chat application called Gajim, many users ask for the functionality to raise the application on left click, which is not possible right now.

[farfromrefug]

@sunweaver @tari01 any chance one of you can look at this? This is a real big issues that literally thousands of applications are facing. I know there has been some activity in last months which is why i took the liberty of bumping this

[DarthGandalf]

I opened #71 for this, and it works for my case... But as is, it breaks left click for everyone who didn't attach some specific handler for it. Which was impossible before that PR. Meaning, this change is quite breaking.

Need some better idea how to handle it

[sblantipodi]

• on a middle-click no distinction is made on the modifier keys that were pressed and the only possible action is to activate the menu item that was set by a previous call to app_indicator_set_secondary_activate_target

this does not work here... is it possible to listen for a secondary click like the middle mouse button?