Re: ERROR:root:Requiring namespace 'Gtk' version '2.0', but '3.0' is already loaded

[Robert Park <rbpark exolucere ca>]

On Mon, Nov 22, 2010 at 10:37 AM, Jiří Techet <techet gmail com> wrote:
> On Sat, Nov 20, 2010 at 01:14, Robert Park <rbpark exolucere ca> wrote:
>> I was about to say something along the lines of "Surely the API
>> reference docs I've been reading were written by people who have
>> already done this before, right?" and then it hit me that this whole
>> time I've just been referring to the C API reference docs and guessing
>> with a great degree of success how to access those methods from
>> Python. Go figure.
>
> Yes, I'm afraid we don't have bindings-specific API documentation yet
> (and the documentation we have would definitely deserve some
> higher-level description of the library functionality).

Well, it seems I'm in a prime position to write some Python-specific
API reference docs based on the introspection bindings, doesn't it?

Does anybody know of good tools to auto-generate documentation based
on the introspection data? I'm pretty new to all this.

> OK, my bad, the truth is that I just hadn't tested it before and kind
> of assumed that having introspection support isn't enough for working
> python bindings

Oh yeah, introspection is pretty magical ;-)

> (still I assume that the auto-generated bindings
> aren't perfect - I'd guess that some tweaks are needed to make the
> python API more pythonic).

Yep. There's a couple methods here and there that return a
mostly-useless success boolean as the first element of a tuple that
otherwise contains the useful data I need. The only example I can
think of off the top of my head is ChamplainView.get_coords_at(), but
I'm sure there are others, too. It's not a big deal, just results in
slightly ugly code like this:

(lat, lon) = self.map_view.get_coords_at(int(x), int(y))[1:3]

Ideally it would look like this instead:

(lat, lon) = self.map_view.get_coords_at(int(x), int(y))

I know, huge difference, right? I noticed a few weeks ago there was a
commit on git.gnome.org that cleaned up many examples of this in the
Gtk bindings.

> Anyway, cool it works, I've just tested it
> with your application (nice app by the way!).

Thanks ;-)

>>> (By the way, for libchamplain 0.8 we
>>> still don't have any python bindings so we need someone to look into
>>> this.)
>>
>> That's... worrisome. What is the status of introspection support in 0.8?
>
> We don't have the the static python bindings only - introspection
> should be working and the introspection-based bindings probably too.

Oh, ok. Well in that case I'm not worried. Static bindings are dead,
don't waste your time on a Sisyphean effort like that. Introspection
is the way forward.

>> I think that's fairly indicative that the problem lies somewhere in
>> pygobject and not libchamplain. J5's attitude seems to essentially be
>> "yep, fedora 14 ships with a pretty broken pygobject, just develop
>> against fedora rawhide and you'll be ok."
>
> Yep, that was my impression too.

I'm hoping to get a Rawhide system up and running so I can play with
the newest versions of everything, but I've just been busy the last
few days.

-- 
http://exolucere.ca