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



----- "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]