Community
Participate
Working Groups
I200411170800-gtk Not sure what triggers it, neither who is doing it. I get the following stderr output once in a while: (<unknown>:27693): libgnomevfs-WARNING **: Deprecated function. User modifications to the MIME database are no longer supported. In my development workbench, the output reads: (Gecko:11501): libgnomevfs-WARNING **: Deprecated function. User modifications to the MIME database are no longer supported. So I suspect the mozilla/gecko library is doing this, hence I punted it to SWT. Probably nothing we can do much about, but here's the bug anyway.
Tom: which Linux distribution are you using?
fedora core 3 - and now you mention it: the warnings have just started to show up after upgrading from core 2. $ rpm -q libgnome gnome-vfs gnome-vfs2 libgnome-2.8.0-2 gnome-vfs-1.0.5-21 gnome-vfs2-2.8.2-8
GNOME has recently been revamping their MIME system. There is likely some change which is affecting how we use it.
This results in not finding any platform mime handlers, including the system browser, any more. Program.findProgram(..., "html") won't find anything due to seeing an empty mime database.
*** Bug 72110 has been marked as a duplicate of this bug. ***
*** Bug 83585 has been marked as a duplicate of this bug. ***
I recently discussed the state of the Program API implementation on GNOME with Marco Pesenti Gritti, one of the libgnomevfs maintainers. Here are some of my thoughts: 1. The warnings are not accurate. We are not trying to modify the database. This seems to be a bug in libgnomevfs. 2. The major change in gnomevfs is that they now use the xdgmime system as a back-end. 3. This system makes it difficult to support the old libgnomevfs API which we use. Therefore, most, if not all, of the GNOME code in Program.java will need to be rewritten. 4. Much of the API we will need to use has only been around since GNOME 2.4. 5. Some of the Program API may be unimplementable with the new API without changes upstream, specifically listing all known programs and listing all known file extensions.
Billy, I guess I am just re-stating the obvious, but... while our supported systems do not include FC3 or (AFAIK) any other system using 2.8, it is a "major" issue that eclipse does not support launching external apps on any of these. Do you think that this will make it on the 3.1 plan, given the facts you outlined in comment 7?
*** Bug 88042 has been marked as a duplicate of this bug. ***
For what it's worth, I get this too using a Debian variant (SimplyMEPIS). (<unknown>:30919): libgnomevfs-WARNING **: Deprecated function. User modifications to the MIME database are no longer supported. KDE 3.3.2, Linux kernel 2.6.7 installed deb packages: libgnomevfs2-0, version 2.8.3-11 libgnomevfs2-common, version 2.8.3-11 libgnome2-0, version 2.8.1-2 libgnome2-common, version 2.8.1-2
Created attachment 20490 [details] Patch On platform-swt-dev, Ty C was interested in helping with this bug. Here are my current hacks that I hope to get in soon: - I use gnome_url_open() to implement Program.launch(). This API has existed since GNOME 2.2, and it's much simpler than the original code. This makes "Open With > System Editor" work properly in Eclipse. - I use gnome_vfs_mime_type_from_name() to implement findProgram(), which avoids actually querying the MIME database. This API has existed since at least GNOME 1.4, and so it is also safe. This allows for getting icons and program names. Program.execute() can be implemented on newer GNOME versions using gnome_vfs_mime_application_launch(), but this API is new in GNOME 2.4, and currently gnome-vfs provides no clean way to do runtime version checks like GTK+ does. This makes it a little more complicated, so I haven't done that yet. Once Program.execute() works, only getPrograms() and getExtensions() will be left unfinished, and I believe they may not be possible to implement with the new gnome-vfs API.
I did not have much success with gnome_url_open() on RHEL3 or RH9, so I guess this code will need version checks as well.
Created attachment 20615 [details] Adds static icon retrieval methods to Mac OS X Carbon variant The patch primarily enhances Program.java. A caller may use the 2 new static methods to retrieve an icon either by file name extension or by requesting the system folder icon.
Created attachment 20616 [details] Adds static icon retrieval methods to Linux GTK variant The patch primarily enhances Program.java. A caller may use the 2 new static methods to retrieve an icon either by file name extension or by requesting the system folder icon. The patch uses the same method to get the MIME type as the first patch attached to this bug, but uses GTK functions instead of GNOME ones which are deprecated.
Ty, can you open a new bug with your patch? I'd rather keep this one just about the GTK+ implementation. Thanks.
First about the GTK+ patch, thanks a lot for posting your code! There are really two parts to it: one is the update to use the new GNOME 2.8 API, and the other part is the addition of the new API. Please file a new bug about the API additions. In this bug I'm addressing the deprecated API use and what to do about it. The real difference between your solution from my patches is the use of GtkIconTheme versus GnomeIconTheme. I think I'm going to stick with using the GnomeIconTheme code because it still works on newer systems, and is backwards compatible to GNOME 2.2. One change I did make (see bug 92505) was to only create a GNOME icon theme once, rather than each time we do a lookup. This is much more efficient, especially on newer GNOME systems. Having a separate helper to lookup the MIME type per extension is a good idea as well.
Fixed > 20050503 The only parts of the Program API which are not implemented on GNOME 2.4 and higher are getPrograms() and getExtensions(), both of which cannot be implemented with the new libgnome-vfs API. There will be no more warnings printed to the console while running Eclipse.
*** Bug 78910 has been marked as a duplicate of this bug. ***
We created a new bug entry as per comment #15. Please refer to bug #93606.
Verified that we work on GNOME 2.8 using I20050510-0010
