After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 631009 - Port to GTK3
Port to GTK3
Status: RESOLVED FIXED
Product: libchamplain
Classification: Core
Component: General
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: libchamplain-maint
libchamplain-maint
: 632695 (view as bug list)
Depends on:
Blocks: 637557
 
 
Reported: 2010-09-30 14:10 UTC by Guillaume Desmottes
Modified: 2011-03-14 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use gtk3 and clutter-gtk 1.0 (7.54 KB, patch)
2010-10-12 05:51 UTC, William Jon McCann
none Details | Review
Remove python bindings (133.45 KB, patch)
2010-10-12 05:51 UTC, William Jon McCann
none Details | Review
Libchamplain window with it's width determined by an HPaned (wide) (504.98 KB, image/png)
2011-01-01 20:47 UTC, Robert Bruce Park
  Details
Libchamplain window with it's width determined by an HPaned (narrow) (400.73 KB, image/png)
2011-01-01 20:48 UTC, Robert Bruce Park
  Details
Test paned with libchamplain (1.84 KB, text/x-csrc)
2011-01-02 00:21 UTC, Jiri Techet
  Details

Description Guillaume Desmottes 2010-09-30 14:10:56 UTC
libchamplain-gtk should use GTK3 in order to be GNOME 3 ready.
Comment 1 William Jon McCann 2010-10-12 05:51:38 UTC
Created attachment 172159 [details] [review]
Use gtk3 and clutter-gtk 1.0
Comment 2 William Jon McCann 2010-10-12 05:51:40 UTC
Created attachment 172160 [details] [review]
Remove python bindings

For GNOME 3 bindings should be generated using introspection
Comment 3 Laurent Bigonville 2010-11-29 15:43:35 UTC
Hi,

any progress in applying this patch?

Cheers
Comment 4 Jiri Techet 2010-11-30 18:05:44 UTC
Hi, sorry for the delay, I should have more time for libchamplain later this week. I've just been too busy recently.
Comment 5 Jiri Techet 2010-12-20 23:28:15 UTC
What's the easiest way to test libchamplain with GTK3? I've tried to use jhbuild but I get some errors during the build. Is there some easier way to get GTK and all the libchamplain dependencies compiled or one really has to use jhbuild?
Comment 6 Laurent Bigonville 2010-12-21 07:50:11 UTC
Which distribution are you using?

If you are using debian, GTK3 is in experimental
Comment 7 Craig Keogh 2010-12-21 08:57:14 UTC
(In reply to comment #5)
> Is there some easier way to get GTK and all the libchamplain dependencies
> compiled or one really has to use jhbuild?

If you apply attachment 176751 [details] [review] from bug 637557 libchamplain should build with JHBuild.

If you are having problems with JHBuild, post to gnome-love mailing list [1]. I and the JHBuild developers are trying hard to make JHBuild work first time, every time. I'd love to hear how JHBuild isn't working for you.

[1] http://mail.gnome.org/mailman/listinfo/gnome-love
Comment 8 Robert Bruce Park 2010-12-28 19:48:04 UTC
I am using jhbuild to successfully build all of pygobject/clutter/libchamplain on Fedora 14 as of a few days ago, however libchamplain does not play nice with gtk3 at all. It keeps requiring Gtk2 and causing lots of interference, mixing Gtk2 and Gtk3 code in bad ways in my app. 

Gtk code that works in an interactive python shell (without libchamplain involved) breaks when I try to use it in my libchamplain-using application, and I suspect it is because libchamplain is not playing nicely with Gtk3. 

I would really appreciate it if libchamplain could embrace Gtk3 as soon as possible. I'm essentially incapable of doing any further development of my app until this is resolved.

Jiri, what problems are you having with jhbuild? I had many problems setting it up as well but I eventually overcame them with help from Craig (and Google). Tell us the error messages you're having and we can work you through it.
Comment 9 Robert Bruce Park 2010-12-28 21:42:16 UTC
Review of attachment 172159 [details] [review]:

This patch applied cleanly to latest git, but I am still having issues where GtkChamplain.Embed() is requiring Gtk version 2.0.
Comment 10 Robert Bruce Park 2010-12-28 22:16:35 UTC
(In reply to comment #9)
> This patch applied cleanly to latest git, but I am still having issues where
> GtkChamplain.Embed() is requiring Gtk version 2.0.

Sorry I'm a little bit disorganized, but here's an example python interactive session where libchamplain's gtk2 is interfering with gtk3:

$ jhbuild run python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> from gi.repository import Clutter, GtkChamplain, Gtk

>>> Clutter.init([])
(<enum CLUTTER_INIT_SUCCESS of type ClutterInitError>, [])

>>> GtkChamplain.Embed()
<Embed object at 0x7fd887a9baa0 (GtkChamplainEmbed at 0x207ead0)>

>>> dialog = Gtk.FileChooserDialog("Open", None, Gtk.FileChooserAction.OPEN, buttons=(Gtk.STOCK_CANCEL, Gtk.ResponseType.CANCEL, Gtk.STOCK_OPEN, Gtk.ResponseType.ACCEPT))

Traceback (most recent call last):
  • File "<stdin>", line 1 in <module>
  • File "/opt/gnome/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 456 in __init__
    buttons=buttons)
  • File "/opt/gnome/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 371 in __init__
    self.add_buttons(*buttons)
  • File "/opt/gnome/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 393 in add_buttons
    self.add_button(text, response)
AttributeError: 'FileChooserDialog' object has no attribute 'add_button'
>>> 

Whereas, without libchamplain, same code works fine:

$ jhbuild run python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> from gi.repository import Gtk

>>> dialog = Gtk.FileChooserDialog("Open", None, Gtk.FileChooserAction.OPEN, buttons=(Gtk.STOCK_CANCEL, Gtk.ResponseType.CANCEL, Gtk.STOCK_OPEN, Gtk.ResponseType.ACCEPT))
Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
>>> dialog.run()

(.:9198): Gtk-WARNING **: GtkFileChooserWidget 0x2914480 is mapped but visible=1 child_visible=1 parent GtkBox 0x2972070 mapped=0

(.:9198): Gtk-WARNING **: Could not find the icon 'application-x-python-bytecode'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
	http://icon-theme.freedesktop.org/releases
-6
>>>
Comment 11 Robert Bruce Park 2010-12-30 02:40:32 UTC
More info here:

http://mail.gnome.org/archives/python-hackers-list/2010-December/msg00025.html
Comment 12 Jiri Techet 2011-01-01 16:00:15 UTC
I have managed to get everything compiled with jhbuild and applied the William's patches (thanks!). I'm a bit surprised that it compiled for you - some of the utility functions of clutter-gtk 0.10 that libchamplain used are missing in clutter-gtk 1.0. I've fixed these problems and changed the champlain-gtk version in the .pc files. I've checked the libraries that are used when running the demos using LD_DEBUG and only the gtk 3 libraries are used now. 

Everything should be committed to master so you can test if it works for you now.

However, I haven't (successfully) tried the introspection-based python bindings. When I run python, it tries to get the python bindings from the standard system paths and not from the jhbuild gnome directory - I haven't spent enough time to investigate proper jhbuild and python integration. I'll probably wait until some distro ships with gtk 3.

There also seems to be some problem with tile animations with libraries built with jhbuild - again I'm not sure if these are real issues or some library problem.

A side note - I have decided to keep champlain-gtk: it simplifies programmer's work in two ways - first it propagates the widget's size changes to ChamplainView and second it manages the cursor changes. These things (especially the resizing) would have to be implemented every time someone wants to use libchamplain in their gtk application - instead, libchamplain should just work as any other widget without any extra work.
Comment 13 Robert Bruce Park 2011-01-01 20:46:26 UTC
Jiri swoops in to save the day! Thank you SO MUCH for giving this some attention. My app runs now! There are a couple hiccups, but it can be described as functional. 

So, I wiped my libchamplain directory and checked out a pristine master just to make sure both issues (gtk3 and the transfer annotations) were solved. My app ran, FileChooserDialog opened no problems, and as far as I can tell the core functionality of my app remains intact.

*However*, there is a glitch. The champlain-gtk widget no longer appears embedded inside my application, but now appears in it's own window! 

In my application, I place the GtkChamplain.Embed object into the right pane of a Gtk.HPaned object (with the left side being a Gtk.ListStore). Previously, champlain never had trouble resizing within the HPaned and behaved quite normally there. What's happening now is that even though it's popped out into it's own window, the size of it's entire window is controlled by the HPaned that it's supposed to be contained in. I find this quite unusual. I've attached a couple screenshots just in case I'm not describing this clearly. 

The libchamplain window initially appears immediately behind my main app window, so at first I thought it wasn't loading at all, until I moved the window and saw the map behind it. It seems to have some sluggishness where it doesn't always load tiles if the window doesn't have focus, but that's a minor problem compared to having it's own window.

What could cause this? My code for instantiating GtkChamplain looks like this:

        Clutter.init([])
        self.champlain = GtkChamplain.Embed()
        self.map_view = self.champlain.get_view()
        self.map_view.set_property('show-scale', True)
        self.map_view.set_scroll_mode(Champlain.ScrollMode.KINETIC)
        self.map_photo_layer = Champlain.Layer()
        self.map_view.add_layer(self.map_photo_layer)
        
        self.photos_and_map_container = Gtk.HPaned()
        self.photos_and_map_container.add(self.photos_with_buttons)
        self.photos_and_map_container.add(self.champlain)

Pretty straightforward stuff. Is there something I should do differently to force champlain into the HPaned or is this a problem in champlain itself?

Thanks again!
Comment 14 Robert Bruce Park 2011-01-01 20:47:51 UTC
Created attachment 177331 [details]
Libchamplain window with it's width determined by an HPaned (wide)
Comment 15 Robert Bruce Park 2011-01-01 20:48:53 UTC
Created attachment 177332 [details]
Libchamplain window with it's width determined by an HPaned (narrow)
Comment 16 Jiri Techet 2011-01-02 00:21:54 UTC
Created attachment 177334 [details]
Test paned with libchamplain
Comment 17 Jiri Techet 2011-01-02 00:29:47 UTC
Strange - I've tested it by modifying one of our demos and it works for me (see the attachment). One thing I've noticed in your code is that you use add() to add the panes, but the documentation says you should use add1(), add2(), or pack1(), pack2() - see

http://library.gnome.org/devel/gtk/unstable/GtkPaned.html#GtkPaned.synopsis

I have also some problems with tile rendering - sometimes they render only if I move the contents of the window by mouse again - but I don't think the problem is in libchamplain in this case. I'll wait for some distribution to ship the new gtk3 stack and will try to find a fix only if this problem persists.
Comment 18 Robert Bruce Park 2011-01-02 02:10:51 UTC
I tried with both add1/add2 and pack1/pack2 and I am experiencing the same behavior.

I tried your demo and I see that it works perfectly as expected. That's odd, eh? Considering that the problem exists in python and not C, that somewhat suggests that the introspection is breaking it somewhere along the line, no? Can you look at the introspection annotation and see if there isn't something that could (even if unlikely) result in libchamplain popping out into it's own window?

Also, what you describe about the tiles not updating unless you move the map by mouse is exactly what I'm experiencing. Are you sure libchamplain isn't responsible? I'd hate for this to go unresolved before the release of GNOME 3. Perhaps you could file a bug with gtk and get some gtk people to figure out whether it's a problem with gtk or with libchamplain.

Thanks!
Comment 19 Robert Bruce Park 2011-01-02 04:27:01 UTC
(In reply to comment #12)
> However, I haven't (successfully) tried the introspection-based python
> bindings. When I run python, it tries to get the python bindings from the
> standard system paths and not from the jhbuild gnome directory - I haven't
> spent enough time to investigate proper jhbuild and python integration. I'll
> probably wait until some distro ships with gtk 3.

I'm not sure what you mean. All i have to do is execute "jhbuild run ./gottengeography.py" in a terminal and it runs within the jhbuild environment no problems. If I want to play with something at an interactive prompt, it's just "jhbuild run python". Does that not work for you?
Comment 20 Frederic Peters 2011-01-02 17:05:38 UTC
*** Bug 632695 has been marked as a duplicate of this bug. ***
Comment 21 Jiri Techet 2011-01-04 13:01:31 UTC
The issue with tiles not appearing is definitely important and has to be fixed before the next libchamplain release. I have created a separate bug report for it here

https://bugzilla.gnome.org/show_bug.cgi?id=638652

Regarding the GtkPaned issue, I don't have many more ideas here. You could try to rewrite the minimal example I have provided in C in python to make sure there is not something else in your application that causes the strange behaviour.
Comment 22 Jiri Techet 2011-01-04 13:03:48 UTC
(In reply to comment #19)
> (In reply to comment #12)
> > However, I haven't (successfully) tried the introspection-based python
> > bindings. When I run python, it tries to get the python bindings from the
> > standard system paths and not from the jhbuild gnome directory - I haven't
> > spent enough time to investigate proper jhbuild and python integration. I'll
> > probably wait until some distro ships with gtk 3.
> 
> I'm not sure what you mean. All i have to do is execute "jhbuild run
> ./gottengeography.py" in a terminal and it runs within the jhbuild environment
> no problems. If I want to play with something at an interactive prompt, it's
> just "jhbuild run python". Does that not work for you?

I was running it from 'jhbuild shell' assuming it was enough. I'll try 'jhbuild run' once I'm on my computer this evening.
Comment 23 Robert Bruce Park 2011-01-05 01:34:18 UTC
Yeah, I've noticed subtle environment differences between 'jhbuild shell' and 'jhbuild run' in the past, definitely worth trying with 'run'. 

I'm a bit busy next couple of days but I'll try to write the simplest possible reproducer for this in Python and see where that takes me.
Comment 24 Robert Bruce Park 2011-01-05 17:00:47 UTC
I just tried it over again with an HBox instead of HPaned and it's doing the same thing. And again with absolutely no other widgets except the Embed() object directly added to the Gtk.Window. Here is the simplest reproducer in an interactive shell:

$ jhbuild run python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> from gi.repository import Clutter, GtkChamplain, Gtk

>>> Clutter.init([])
(<enum CLUTTER_INIT_SUCCESS of type ClutterInitError>, [])

>>> champlain = GtkChamplain.Embed()
Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory

>>> window = Gtk.Window()
>>> window.add(champlain)
>>> window.set_size_request(800,600)
>>> window.show_all()
(<unknown>:18040): Clutter-CRITICAL **: Unable to retrieve the geometry of the foreign window: XGetGeometry() failed (status code: 0)

>>> Gtk.main()


This produces two windows of equal size, one totally blank, the other containing a functioning libchamplain widget. It's definitely not my app's fault that this is happening. 

The clutter error is a little bit curious. Could this somehow be a bug in clutter itself?
Comment 25 Robert Bruce Park 2011-01-09 21:08:26 UTC
Has anybody had a chance to look into this yet? This bug has essentially destroyed the usability of my app. 

I did some googling and not many people are also getting this Clutter-CRITICAL error message, but the commit that introduced the message itself popped up here:

http://git.clutter-project.org/clutter/diff/?h=wip/uprof-0.3&id=a20a509584c8f8982b6f2f5daf92d882f99e6d02

Perhaps this provides some context as to what is going wrong?
Comment 26 Jiri Techet 2011-01-11 00:14:35 UTC
I still have some problems running python from jhbuild so I haven't been able to reproduce it myself. Just one more idea - you could try to use GtkClutterEmbed instead of GtkChamplainEmbed - GtkChamplainEmbed is just a wrapper of GtkClutterEmbed so if you reproduce the bug with GtkClutterEmbed, it is likely that the bug isn't in libchamplain but rather in GtkClutter.
Comment 27 Robert Bruce Park 2011-01-12 03:00:11 UTC
Sure enough!

$ jhbuild run python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> from gi.repository import Gtk, Clutter, GtkClutter, Champlain

>>> window = Gtk.Window()
Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory

>>> Clutter.init([])
(<enum CLUTTER_INIT_SUCCESS of type ClutterInitError>, [])

>>> champlain = Champlain.View()

>>> clutter = GtkClutter.Embed()

>>> stage = clutter.get_stage()

>>> stage.add_actor(champlain)

>>> window.add(clutter)

>>> window.show_all()

(.:6580): Clutter-CRITICAL **: Unable to retrieve the geometry of the foreign window: XGetGeometry() failed (status code: 0)

>>> Gtk.main()


This produces one blank Gtk window and a second window containing the libhamplain map of the world.

I'll go file a bug against clutter.
Comment 28 Robert Bruce Park 2011-01-12 03:33:45 UTC
Clutter bug filed here: http://bugzilla.clutter-project.org/show_bug.cgi?id=2514

BTW Jiri, what problems are you having with jhbuild? Care to show me some error messages? I'd love to help you help me ;-)
Comment 29 Laurent Bigonville 2011-01-12 15:22:41 UTC
>>> Clutter.init([])

Should be GtkClutter.init("") I guess
Comment 30 Laurent Bigonville 2011-01-12 18:24:03 UTC
Just tested on natty with clutter-gtk-1.0 and it works perfectly with calling GtkClutter.init([])

I guess that the bug on clutter bugzilla can also be closed
Comment 31 Jiri Techet 2011-01-12 19:32:21 UTC
Does the development version of natty come with GTK+ 3 installed? At distrowatch it says that version 2.23.90 is used so I wasn't sure whether I could use natty for testing.

A quick question before I install natty - do you also experience the following bug?

https://bugzilla.gnome.org/show_bug.cgi?id=638652

Thanks.
Comment 32 Laurent Bigonville 2011-01-12 19:43:58 UTC
Indeed libgtk3.0-0 2.91.7-1ubuntu1 is available
Comment 33 Robert Bruce Park 2011-01-13 01:00:14 UTC
Sure enough, GtkClutter vs just Clutter is the solution. Any thoughts on why this is the case? The "Clutter.init([])" was working perfectly up until now.
Comment 34 Laurent Bigonville 2011-02-08 09:33:31 UTC
Hi,

Would be great if you could release a version with GTK3 support (even if it's not the final) so other maintainers could test it.

Cheers
Comment 35 Frederic Crozat 2011-02-08 12:38:21 UTC
FYI, latest gtk+ 2.99.x releases deprecated gtk_widget_hide_all which is still used in local-rendering
Comment 36 Jiri Techet 2011-02-09 21:58:41 UTC
@Laurent - see the email I have just sent to the mailing list. I'll make a release this weekend or early next week

@Frederic - thanks, I've just made the change
Comment 37 Laurent Bigonville 2011-03-14 16:06:49 UTC
I guess that that bug can be closed