After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732470 - AppIndicator scroll-event always reports ScrollDirection UP, never DOWN
AppIndicator scroll-event always reports ScrollDirection UP, never DOWN
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: introspection
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2014-06-30 10:15 UTC by Peter Levi
Modified: 2018-01-10 20:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Peter Levi 2014-06-30 10:15:03 UTC
I am using AppIndicator via Python. On Ubuntu 12.10 and up (14.04 is still affected, not sure about 14.10) when I listen for scroll event signals, the direction is always reported as UP, never as DOWN - even when scrolling down. This was working on 12.04.

This problem seems to be in the Python bindings, as scroll events in appindicators work fine in C and Vala.

My application Variety depends on this functionality, here is the relevant bug report for it: https://bugs.launchpad.net/variety/+bug/1071598
The bug has also been reported here: https://bugs.launchpad.net/indicator-application/+bug/1075152 and here: https://bugs.launchpad.net/ubuntu/+source/libappindicator/+bug/1071738


Here is sample code to demonstrate the problem (OK on Ubuntu 12.04, buggy on 12.10 and up):

from gi.repository import Gtk, Gdk, AppIndicator3

if __name__ == "__main__":
    menu = Gtk.Menu()
    quit = Gtk.MenuItem("Quit")
    quit.connect("activate", Gtk.main_quit)
    menu.append(quit)
    menu.show_all()

    def scroll(ind, steps, direction):
        print steps, direction
        if direction != Gdk.ScrollDirection.UP:
            print "Things seem ok"

    indicator = AppIndicator3.Indicator.new('testscroll', '', AppIndicator3.IndicatorCategory.APPLICATION_STATUS)
    indicator.set_status(AppIndicator3.IndicatorStatus.ACTIVE)
    indicator.set_icon("/usr/share/pixmaps/firefox.png")
    indicator.connect("scroll-event", scroll)
    indicator.set_menu(menu)
    Gtk.main()
Comment 1 Simon Feltman 2014-06-30 16:58:32 UTC

*** This bug has been marked as a duplicate of bug 693664 ***
Comment 2 Peter Levi 2014-07-27 13:45:17 UTC
I don't think this is a duplicate of Bug 693664 ("Scrolling down over a StatusIcon emits lot of "scroll up".")

First, the AppIndicator scroll-event never outputs Down, as in it is in that bug - it is _always_ Up. In Ubuntu 12.04 when this worked, the value for direction was an integer (0 or 1), and from 12.10 onward this integer is packed as a Gdk.ScrollDirection, which for some reason is always UP - I suppose the problem lies somewhere in this change.

Second, the suggested workaround in the other bug does not apply here at all. It is to use get_scroll_deltas() of the Event to determine scroll direction/amount. This is not possible here, as AppIndicator's scroll-event does not pass an Event object to the handler, it passes only the emitting indicator object, step and direction - no way to get to the underlying Event form here.

Sorry, I am not familiar with the way python gi works to help further. This comment from jconti at https://bugs.launchpad.net/indicator-application/+bug/1075152 might be relevant:

"The problem is the annotation to scroll-event in http://bazaar.launchpad.net/~indicator-applet-developers/libappindicator/trunk.13.10/view/head:/src/app-indicator.c

It is type Gdk.ScrollDirection. This was a change between 12.04 and 12.10. If you drop the annotation it will work by unpacking an int instead (as can be seen in the example output from 12.04 above).

So ultimately a problem in the python gi, since it doesn't seem able to deal with the ScrollDirection enum, but the trigger is the annotation in libappindicator. (Though I haven't tested in 13.10 yet)"
Comment 3 Christoph Reiter (lazka) 2014-07-27 14:31:12 UTC
I can confirm the bug on 13.10 and I can confirm that it seems to work in pgi there, so probably a pygobject bug.
Comment 4 Christoph Reiter (lazka) 2014-07-27 17:50:22 UTC
This shows the problem as well:

######################################

import signal
from gi.repository import Gtk, Gdk, GLib, AppIndicator3

def scroll(ind, steps, direction):
    print steps, direction

category = AppIndicator3.IndicatorCategory.APPLICATION_STATUS
indicator = AppIndicator3.Indicator.new('testscroll', '', category)
indicator.connect("scroll-event", scroll)
indicator.emit("scroll-event", 0, Gdk.ScrollDirection.UP)
indicator.emit("scroll-event", 1, Gdk.ScrollDirection.DOWN)
indicator.emit("scroll-event", 2, Gdk.ScrollDirection.LEFT)
indicator.emit("scroll-event", 3, Gdk.ScrollDirection.RIGHT)
GLib.unix_signal_add(0, signal.SIGINT, Gtk.main_quit)
Gtk.main()
Comment 5 Simon Feltman 2014-07-28 00:36:30 UTC
(In reply to comment #2)
> I don't think this is a duplicate of Bug 693664 ("Scrolling down over a
> StatusIcon emits lot of "scroll up".")

Peter,
Thanks for the update. Do you get an assertion with "G_VALUE_HOLDS_ENUM" when using the scroll wheel on the indicator?

I've verified this bug also occurs when poking at the scroll event with dbus:

import dbus
bus = dbus.SessionBus()
# ":1.1983" will change, you can use d-feet to find this in the session bus.
# or call the whole thing with d-feet using: 1, "vertical"
# as the method args.
testscroll = bus.get_object(':1.1983', '/org/ayatana/NotificationItem/testscroll')
scroll = testscroll.get_dbus_method('Scroll', dbus_interface='org.kde.StatusNotifierItem')
scroll(1, 'vertical')
scroll(-1, 'vertical')

# Result:
./bugs/732470.py:42: Warning: g_value_get_enum: assertion 'G_VALUE_HOLDS_ENUM (value)' failed
  Gtk.main()
1 <enum GDK_SCROLL_UP of type GdkScrollDirection>
1 <enum GDK_SCROLL_UP of type GdkScrollDirection>


The issue seems to be related to libappindicator using a GI annotation for the scroll-events direction with (type  Gdk.ScrollDirection), whereas the signal is created using G_TYPE_UINT as the GValue argument type [1]. Emitting 'scroll-event' either with dbus or Python as Christoph has shown passes a GValue holding an integer. When pygobject receives the signal, it tries to marshal this GValue as an enum based on the introspection information (using g_value_get_enum) which is what causes the assertion shown above. Beyond the assertion warning, g_value_get_enum() also returns 0 which ends up being GTK_SCROLL_UP (very similar to bug 693664).

We could hack around this in pygobject by also accepting integer types as valid enum values, but I believe the root of the problem lies in libappindicator using an annotation which differs in fundamental type than what the signal describes for its GValue marshaller (G_TYPE_ENUM vs. G_TYPE_UINT).

[1] http://bazaar.launchpad.net/~indicator-applet-developers/libappindicator/trunk.14.10/view/head:/src/app-indicator.c#L526
Comment 6 Peter Levi 2014-07-29 07:37:57 UTC
I confirm on Ubuntu 14.04 I get "Warning: g_value_get_enum: assertion 'G_VALUE_HOLDS_ENUM (value)' failed   Gtk.main()".
Comment 7 henczati 2014-09-01 15:53:43 UTC
+1 on Lubuntu/LXDE.

Desktop Environment: LXDE
OS: Lubuntu 14.04 amd64

$ apt-cache policy gir1.2-appindicator3-0.1 indicator-application indicator-application-gtk2 libappindicator1 libappindicator3-1 libindicator3-7 libindicator7 lxpanel-indicator-applet-plugin | sed '/^[^ ]/ {n;p}; d'
gir1.2-appindicator3-0.1:
  Installed: 12.10.1+13.10.20130920-0ubuntu4
indicator-application:
  Installed: 12.10.1+14.04.20140407-0ubuntu1
indicator-application-gtk2:
  Installed: 12.10.0.1-0ubuntu2
libappindicator1:
  Installed: 12.10.1+13.10.20130920-0ubuntu4
libappindicator3-1:
  Installed: 12.10.1+13.10.20130920-0ubuntu4
libindicator3-7:
  Installed: 12.10.2+14.04.20140402-0ubuntu1
libindicator7:
  Installed: 12.10.2+14.04.20140402-0ubuntu1
lxpanel-indicator-applet-plugin:
  Installed: 0.6.1-0ubuntu3
Comment 8 GNOME Infrastructure Team 2018-01-10 20:43:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pygobject/issues/74.