libunity support gobject-introspected languages

[Mikkel Kamstrup Erlandsen]

libunity should support other languages than C and Vala via GObject Introspection. It already compiles a typelib that takes it a long part of the way, now we just have to make it work. This is a meta bug to track the related tasks.

Core tasks:

 1) Don't leak Gee in the public API. Gee does not support GI (DONE in libunity-3.4.2)

 2) Make sure Dee-1.0 works well with GI:
   - Partially blocked by https://bugzilla.gnome.org/show_bug.cgi?id=638915

 3) Make sure Dbusmenu-Glib-0.4 supports GI:
   - Broken. See https://bugs.launchpad.net/dbusmenu/+bug/713099

 4) Don't use nested namespaces in libunity. GIR doesn't support this. Done in libunity revno 37 (to be released on 3.4.4)

Optional tasks to add a bit of finesse to the APIs:

 P1) Python overrides for libunity, dee, and dbusmenu-glib (dee has some already)

 M1) Check Mono status of GI support

 S1) Seed support

 G1) GJS support

[Mikkel Kamstrup Erlandsen (kamstrup)]

With the latest round of Dbusmenu fixes and libunity-3.4.2 I can actually do in python:

from gi.repository import Unity
dir(Unity)

But whenever I try and use any of the classes there I get some odd errors. Eg.

>>> appman = Unity.AppInfoManager.get_instance()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/pymodules/python2.7/gi/module.py", line 263, in __getattr__
    return getattr(self._introspection_module, name)
  File "/usr/lib/pymodules/python2.7/gi/module.py", line 160, in __getattr__
    wrapper = metaclass(name, bases, dict_)
  File "/usr/lib/pymodules/python2.7/gi/types.py", line 226, in __init__
    set_object_has_new_constructor(cls.__info__.get_g_type())
TypeError: must be a subtype of GObject

or

>>> dir(Unity.LauncherEntry)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/pymodules/python2.7/gi/module.py", line 263, in __getattr__
    return getattr(self._introspection_module, name)
  File "/usr/lib/pymodules/python2.7/gi/module.py", line 136, in __getattr__
    interfaces = tuple(interface for interface in get_interfaces_for_object(info)
  File "/usr/lib/pymodules/python2.7/gi/module.py", line 76, in get_interfaces_for_object
    interfaces.append(getattr(module, name))
  File "/usr/lib/pymodules/python2.7/gi/module.py", line 263, in __getattr__
    return getattr(self._introspection_module, name)
  File "/usr/lib/pymodules/python2.7/gi/module.py", line 160, in __getattr__
    wrapper = metaclass(name, bases, dict_)
  File "/usr/lib/pymodules/python2.7/gi/types.py", line 228, in __init__
    register_interface_info(cls.__info__.get_g_type())
TypeError: must be an interface

I will look into it

[Ken VanDine (ken-vandine)]

Bumping this up to high since it is blocking ubuntuone's integration

[Martin Pitt (pitti)]

Mikkel, which parts of the description are actually still open? It seems that 1 is fixed, 3 is fixed upstream. 2 seems halfway fixed, do you need help with https://bugzilla.gnome.org/show_bug.cgi?id=638915 ?

Do you need some other help with this? I'm happy to help out with P1, but I don't want to get into mono or javascript (M1/G1/S1).

[Mikkel Kamstrup Erlandsen (kamstrup)]

With the latest gobject-introspection 2) appears to fixed. I have only done very simple testing though, so it needs to be ratified.

That said I've seen some regressions introduced with the latest GI as well; marking methods that previously worked well as introspectable="0" in the GIR. I'm just having a quick stab at that, and I'll file it upstream when I've gathered some more intel.

Martin, If you want to work on P1 for dbusmenu I think that would be great. I'll look at the P1 for libunity myself as I work on the problem from comment #1.

[Martin Pitt (pitti)]

I didn't find dee python overrides, neither in the Ubuntu packages nor in the upstream code. What did you mean there?
Also, where should we ship these overrides, in the gir1.2-dee.. package?

I'll start with fixing the transfer annotations in libdbusmenu, as quite a few of them are not introspectable due to that. Once that works, I'll play with the API and see what can be made more smooth with overrides.

[Martin Pitt (pitti)]

I'll work on the annotations and overrides in lp:~pitti/dbusmenu/fix-annotations, will do a MP once it's done.

[Martin Pitt (pitti)]

dbusmenu annotations are now fixed in the branch, the .gir looks a lot better now, and there are (almost) no unintrospectable functions any more. Still haven't tested this much from Python yet, that's still on my TODO.

[Mikkel Kamstrup Erlandsen (kamstrup)]

@Martin the Dee overrides are in lp:dee alright http://bazaar.launchpad.net/~unity-team/dee/trunk/view/head:/bindings/python/Dee.py On the question of how to package the overrides I'm quite uncertain - do we have any examples we can look at here?

[Mikkel Kamstrup Erlandsen (kamstrup)]

jdahlin helped me debug the problem from comment #1. It's because valac doesn't set the shared-library attribute on the <namespace> element in the GIR. See fx. from Gtk-3.0.gir:

  <namespace name="Gtk"
                       version="3.0"
                       shared-library="libgtk-3.so.0"
                       c:identifier-prefixes="Gtk"
                       c:symbol-prefixes="gtk">

So we can sed this in the Makefile for now, until we've cooked up a patch for valac. I'll file an upstream valac bug.

[Martin Pitt (pitti)]

Mikkel Kamstrup Erlandsen [2011-02-17 12:28 -0000]:
> @Martin the Dee overrides are in lp:dee alright
> http://bazaar.launchpad.net/~unity-
> team/dee/trunk/view/head:/bindings/python/Dee.py

Ah, thanks.

> On the question of how to package the overrides I'm quite uncertain
> - do we have any examples we can look at here?

No, I think this would be the first package which ships any. The
overrides of Glib, Gio, Gtk, etc. already come with pygobject, but
they don't fit well there either. I think shipping the overrides in
the gir* package will work fine.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Martin Pitt (pitti)]

Mikkel,

I just saw your test code in the upstream vala bug. I just wondered whether you are aware that you can use local typelibs by setting $GI_TYPELIB_PATH ? I use

  export GI_TYPELIB_PATH=$HOME/upstream/gtk/gtk:$HOME/upstream/gtk/gdk:$HOME/upstream/pango/pango

This works similar to LD_LIBRARY_PATH for *.so files. By using both you can avoid the "sudo cp" commands to the system dirs.

[Alejandro J. Cura (alecu)]

The issue from comment #1 is fixed in libunity trunk, so if I "make install" libunity I can use libunity from python intended. Eagerly awaiting for this to be packaged :-)

[Alejandro J. Cura (alecu)]

make that "from python as intended"

[Launchpad Janitor (janitor)]

This bug was fixed in the package dee - 0.5.10-0ubuntu1

---------------
dee (0.5.10-0ubuntu1) natty; urgency=low

  * New upstream release.
    - Sync problems when restarting Unity place daemons (LP: #721289)
    - libunity support gobject-introspected languages (LP: #709240)
 -- Didier Roche <email address hidden> Thu, 24 Feb 2011 20:07:48 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package libunity - 3.4.6-0ubuntu1

---------------
libunity (3.4.6-0ubuntu1) natty; urgency=low

  * New upstream release.
    - libunity support gobject-introspected languages (LP: #709240)
    - inspector's unity_running is not initialized (LP: #719769)
  * debian/rules:
    - now, try to get a more stable ABI, use a symbols file
    - whip the pyc pyo generated
    - debian/libunity3.symbols
  * ship the gir python override in the gir package, still nice some tweaking
    though
 -- Didier Roche <email address hidden> Thu, 24 Feb 2011 20:10:48 +0100

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.