Re: ERROR:root:Requiring namespace 'Gtk' version '2.0', but '3.0' is already loaded
- From: John Palmieri <johnp redhat com>
- To: Jiří Techet <techet gmail com>
- Cc: python-hackers-list <python-hackers-list gnome org>, Russell Strong <russell strong id au>, libchamplain-list gnome org
- Subject: Re: ERROR:root:Requiring namespace 'Gtk' version '2.0', but '3.0' is already loaded
- Date: Mon, 22 Nov 2010 11:59:26 -0500 (EST)
----- "Jiří Techet" <techet gmail com> wrote:
> On Thu, Nov 18, 2010 at 19:40, Robert Park <rbpark exolucere ca>
> wrote:
> > On Thu, Nov 18, 2010 at 12:35 AM, Russell Strong
> <russell strong id au> wrote:
> >> I have had another problem with F14 that you may be interested in
> as it
> >> appears to effect libchamplain
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=649134
> >>
> >> I've had to go back to F13 for now.
> >
> > This bug doesn't seem to be affecting me. My app is able to run,
> and
> > libchamplain can load some tiles, and I can navigate the map, zoom
> in
> > or out, etc. That mostly works. There are two things that cause my
> > application to crash somewhat reliably:
> >
> > * Panning or zooming rapidly (a gentle touch won't crash anywhere
> near
> > as often as rapid movements do)
> >
> > * Multiple frequent calls to ChamplainView.ensure_visible(), but
> only
> > when those calls result in the map zooming out. For example, my GPX
> > parser calls ensure_visible() 5 times per second, and I have a
> 4.4MB
> > test file that takes ~9 seconds to load. If I zoom in to a small
> area
> > and then load this GPX, the app crashes. If I manually zoom out to
> > reveal the whole area first, ensure_visible() harmlessly pans the
> map
> > around but does not do any zooming, and no crash happens.
> >
> > I have not experienced any issue in which clutter is only able to
> > paint once and then ceases.
> >
> > --
> > http://exolucere.ca
> > _______________________________________________
> > libchamplain-list mailing list
> > libchamplain-list gnome org
> > http://mail.gnome.org/mailman/listinfo/libchamplain-list
> >
>
> Hi,
>
> sorry for the somewhat late response from me. Just a few comments:
>
> - I dont use neither Fedora (even though I have been considering it
> lately) nor GTK3. I plan to test libchamplain with GTK3 a bit later
> in
> the release cycle to ensure full compatibility with it. (I kind of
> suspect that the transition to GTK3 will be somewhat hairy and the
> upcoming releases of major distros will be slightly broken.)
>
> - Robert mentions that his application works also when the package
> libchamplain-python (which I suppose to be our static python
> bindings)
> is uninstalled. Does it mean that Fedora ships with
> introspection-based python bindings as well? This is quite
> interesting
> because several people have tried to make the PyGObject-based
> bindings
> running for libchamplain without any success. Could this be ported
> from Fedora to libchamplain? (By the way, for libchamplain 0.8 we
> still don't have any python bindings so we need someone to look into
> this.)
>
> - Robert, do you experience the problems only with the python
> bindings
> or also with the C demo applications? So far it seems to me like a
> Fedora problem rather than a libchamplain bug. Correct me if I'm
> wrong.
>
> - Even though one can create a gtk application without champlain-gtk,
> I think it's better to keep it to make things like automatic cursor
> icon change work automatically out of the box.
>
> - Russell, I think you are hitting this bug:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=632785
>
> See the comments for the workarounds.
>
> Cheers,
>
> Jiri
Hi Jiri,
Gtk 3 should be fairly simple to port to. I encourage you do it sooner than later. Note that clutter as well as clutter-gtk is already 3.0 compatible. I think if you need cursor functionality you may be able to have it added to clutter-gtk. If you absolutely need to create a champlain-gtk it should be based mostly off the clutter-gtk code which already compiles against Gtk-3.0. I'm not sure if there are ABI or API issues with that but it seems like a useful thing to abstract so it works in any toolkit. As for gobject introspection I noticed that compiling from git gives me a gir file so this is upstream already. Fedora isn't in the habit of diverging too much from upstream. If anything we usually only patch in backports.
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]