The status property is stored and handled in various formats, causing confusion and binding breakage

Bug #668389 reported by Sense Egbert Hofstede
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libappindicator
Confirmed
Medium
Unassigned
libappindicator (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Binary package hint: indicator-application

The 'status' property of an Application Indicator in libappindicator is stored in various ways and is handled in various ways. This makes it inconsistent and also makes it harder for bindings to work everywhere automagically without writing custom workarounds.

AppIndicatorStatus is a type, and enum value type with three enum options for the three statuses. Enums are actual numeric values and they get a nick assigned here as well.

The 'AppIndicator:status' property is created as a GParamSpecString and stored in string format, following KDE's standard nicks.

In C you set the status by passing an enum integer of the AppIndicatorStatus type to the method app_indicator_set_status(). From this value the method gets the enum value and takes the value nick from that. It stores the enum integer of the AppIndicatorStatus type in the internal private structure and sends the nick as an argument to the status-changed signal.

The method app_indicator_get_status() returns the internally stored enum integer of the AppIndicatorStatus.

The get_status and set_status methods are thus not compatible with the type of property told to GObject when registering the status property. The value stored in the internal private structure isn't either.

The method app_indicator_set_property() does use a string: it takes the nick value and fetches the enum value for that and stores that internally. The app_indicator_get_property() method returns the nick value. This is compatible with the property's type and with the DBus specification of KDE, which talks to the get_property and set_property methods given to GObject.

In regular C applications this wouldn't be a problem because applications use the set_status and get_status methods to manipulate the status. They can use the enum type for that. However, in bindings the enum type is translated to the language's variant, but the get_property and set_property do not accept the integer values, they need strings.
This causes problems in the automatically generated constructor in C#.

I would recommend using the enum type everywhere and changing the property type to the enum type to make sure the type is used. Otherwise in some bindings and in some cases people will have to use the nick values. Nick values have to hard-coded in the code, and when they would change or be extended, they would stop working.

Everything said above also applies to categories.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libappindicator1 0.2.9-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-23.36-generic 2.6.35.7
Uname: Linux 2.6.35-23-generic i686
Architecture: i386
Date: Fri Oct 29 11:14:30 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
ProcEnviron:
 LANGUAGE=nl_NL:nl:en_GB:en
 LANG=nl_NL.utf8
 SHELL=/bin/bash
SourcePackage: indicator-application

Revision history for this message
Sense Egbert Hofstede (sense) wrote :
Ted Gould (ted)
Changed in indicator-application:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Ted Gould (ted)
Changed in indicator-application (Ubuntu):
importance: Undecided → Low
status: New → Triaged
affects: indicator-application (Ubuntu) → libappindicator (Ubuntu)
affects: indicator-application → libappindicator
Ted Gould (ted)
Changed in libappindicator:
assignee: Ted Gould (ted) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.