Community
Participate
Working Groups
At present, SWT uses gnome-vfs on Linux/GNOME. gnome-vfs in turn relies on HAL which is now in maintenance mode [1]. GNOME is trying to get rid of dependencies on HAL [2] and gnome-vfs [3]. Linux distributions are working to get rid of things that depend upon HAL and in turn gnome-vfs [4, 5, 6]. It would be good to allow SWT to use gvfs instead of gnome-vfs. Compatibility with gnome-vfs should be kept for distributions which still carry gnome-vfs. Information about porting can be found here: http://live.gnome.org/GioPort [1] http://www.freedesktop.org/wiki/Software/hal [2] [Tracker] Get rid of HAL https://bugzilla.gnome.org/show_bug.cgi?id=593938 [3] Get rid of deprecated gnome-vfs https://bugzilla.gnome.org/show_bug.cgi?id=588322 [4] Fedora https://fedoraproject.org/wiki/Features/HalRemoval [5] Debian http://wiki.debian.org/HALRemoval [6] Ubuntu https://wiki.ubuntu.com/Halsectomy
I believe we have done this already. Bogdan?
We added support for GIO in 3.6 and this should be working. We first check to see if the GIO libraries are present on the system. If found, we use it, if not we try gnome-vfs. Please reopen if this isn't working for you or if you meant something else. Closing as WORKSFORME.
I guess I was confused because the library still dynamically links against libgnomevfs. Sorry and thanks for rocking on this :)
Okay, one more question: can one build SWT without gnomevfs headers, etc. being present? In other words: does the build do the same GIO -> gnomevfs fallback? Thanks.
We are all speaking about libswt-gnome-gtk-*.so, right? Build from the code in org.eclipse.swt/Eclipse SWT Program/gnome/library This library is used for file associations, system editors invocations and etc, right? Looking at its code it's completely gnome-vfs2 dependant and I wasn't able to find any mentioning of gio there. Or is this part of the main gtk library now?
The gnome vfs library doesn't have to be there for Program to work; if we find the gio library present on the system, we load that library instead.
Does it mean that in a controled environment where we are sure that gio is present we can not ship libswt-gnome-gtk-*.so and we will lose no functionallity?
Bogdan, can you answer my question? I want to be sure about that.
Hi Alexander. If you are sure you have GIO available on whatever system you are deploying to, you could get away with not shipping the gnome-gtk library (disclosure: I haven't tried this myself). When Program goes to look at what desktop library is available, it will use GIO if possible and all of those bindings are defined in the OS class. The gnome-gtk library contains only the gnome vfs bindings and those should never get touched if you're following the GIO path. Best thing to do is give it a try...
(In reply to comment #9) > Hi Alexander. If you are sure you have GIO available on whatever system you are > deploying to, you could get away with not shipping the gnome-gtk library > (disclosure: I haven't tried this myself). When Program goes to look at what > desktop library is available, it will use GIO if possible and all of those > bindings are defined in the OS class. The gnome-gtk library contains only the > gnome vfs bindings and those should never get touched if you're following the > GIO path. Best thing to do is give it a try... After a bit of investigation I can say that this is not possible because: 1. org.eclipse.swt.program.Program.getDesktop(Display) method uses gnome_init call before checking for libgio. gnome_init method is calling gnome_vfs_init method which itself is calling gnome_vfs_init JNI in libswt-gnome-gtk-*.so . This even makes the code after that trying to load gnomevfs redundant, am I right? Did I miss smth crucial? 2. GNOME.gnome_icon_theme_new() is called before the libgio detection and it's JNI counterpart is also in libswt-gnome-gtk*.so. Note that there is gtk_icon_theme_new in gtk 2.4+ which is supposed to replace the gnome_icon_theme_new. Any ideas how to proceed to drop the gnomevfs entirely? I mean not having the library even.
Bumping minimal gtk requirement to gtk 2.4 will allow to drop gnome library a lot easier by replacing gnome_icon_theme_* calls with gtk_icon_theme_* , is such change acceptable for SWT 3.7? Is there someone platform stuck to gtk from pre-2004?
http://www.eclipse.org/swt/faq.php#gtkstartup shows gtk 2.4 as the minimum requirement for swt 3.6+. Would such change be considered for swt 3.7 assuming that patch is provided?
Created attachment 191145 [details] fix You are correct. Sorry we did not realize gnome-vfs was still initialized and that we would not attempt to load GIO if the initialization of gnome-vfs failed. This patch will check for GIO first and if available, the gnome-vfs binding will not be loaded at all. I will released this to HEAD.
(In reply to comment #11) > Bumping minimal gtk requirement to gtk 2.4 will allow to drop gnome library a > lot easier by replacing gnome_icon_theme_* calls with gtk_icon_theme_* , is > such change acceptable for SWT 3.7? Is there someone platform stuck to gtk from > pre-2004? Are there replacements for all gnome_vfs_* calls SWT makes (gnome_vfs_mime_get_default_application, gnome_vfs_make_uri_from_input_with_dirs, etc)?
(In reply to comment #14) > (In reply to comment #11) > > Bumping minimal gtk requirement to gtk 2.4 will allow to drop gnome library a > > lot easier by replacing gnome_icon_theme_* calls with gtk_icon_theme_* , is > > such change acceptable for SWT 3.7? Is there someone platform stuck to gtk from > > pre-2004? > > Are there replacements for all gnome_vfs_* calls SWT makes > (gnome_vfs_mime_get_default_application, > gnome_vfs_make_uri_from_input_with_dirs, etc)? Sorry, I missed the question. There is http://developer.gnome.org/gio/2.30/ch27.html describing the migration path. For the things you asked my quess would be (without looking at the code) gnome_vfs_mime_get_default_application -> g_app_info_get_default_for_type gnome_vfs_make_uri_from_input_with_dirs -> g_file_*/g_uri* depending on the usecase. Please let me know about the plans for 3.8 in this regard and I'll see what can be done.
Closing as this was fixed.
