Community
Participate
Working Groups
When running Eclipse 4.1 on KDE it is not obvious how to get the internal browser working. I tried on two machines with different versions of KDE etc. On both machines the internal browser works in 3.7 (one using xulrunner the other should be using webkit (how can I see which toolkit is actually used?). In both cases libswt-gnome-gtk-3730.so had unresolved dependencies until I installed these (with their dependencies, a total of 33.6MB): - libgnomevfs2-0 - libgnomeui-0 Are these really needed? 3.7 does not need them and non-gnome users will not have them installed. After that the following error is logged to std err: (Eclipse:1963): libgnomevfs-WARNING **: Internal error: the configuration system was not initialized. Did you call _gnome_vfs_configuration_init?
Any ideas here, Grant?
Two different issues here: 1. To determine if a Browser is using Mozilla or not you can try to navigate to either about:config or about:buildconfig. If it's using Mozilla then this will show settings or compilation info, for other browser types it won't. Another way, if you have something like an RCP app, is to set Device.DEBUG = true; before the first Browser instance is created, and it will write something useful to stdout when the first Browser is created. 2. The libgnome stuff is related to SWT's Program class. If these libraries are not found then functionality will be lost in areas like determining native file associations. The General > Editors > File Associations preference page is one place where this would show up. Depending on your usage patterns you may or may not miss this.
(In reply to comment #2) > Two different issues here: > > 1. To determine if a Browser is using Mozilla or not you can try to navigate to > either about:config or about:buildconfig. Thanks. Unfortunately this assumes the internal browser *is* working. So far I haven't seen it working on my box in Eclipse 4.1. > If it's using Mozilla then this will > show settings or compilation info, for other browser types it won't. Another > way, if you have something like an RCP app, is to set Device.DEBUG = true; > before the first Browser instance is created, and it will write something > useful to stdout when the first Browser is created. Setting this property in eclipse.ini didn't help. Either it doesn't work in Eclipse or it again assumes the browser can actually be created. > 2. The libgnome stuff is related to SWT's Program class. If these libraries > are not found then functionality will be lost in areas like determining native > file associations. The General > Editors > File Associations preference page > is one place where this would show up. Depending on your usage patterns you > may or may not miss this. Are you saying, the internal browser *should* work even without these? I did get errors re unresolved libraries when trying to open the internal browser, though. Would gnome libraries give any useful information like for file associations on a non-gnome (e.g., KDE) desktop? Until now I haven't gotten past this error: (Eclipse:2590): libgnomevfs-WARNING **: Internal error: the configuration system was not initialized. Did you call _gnome_vfs_configuration_init?
I don't think there should be any connection between libgnomevfs2 and the Browser control, they should be able to succeed/fail independently of each other. If the Browser is working on your machine with Eclipse 3.7 but not with 4.1 then presumably 4.1 is doing something different (?). When 4.1 goes to create a Browser control through its workbench API does it first see if an external browser is available for some reason? Or any other references to the Program class that would be getting hit? > Would gnome libraries give any useful information like for file associations > on a non-gnome (e.g., KDE) desktop? I think they're somewhat useful if they're installed. A long time ago SWT had an analagous library for accessing this info in a KDE environment, but it had problems and went away, so SWT's Program support has always been generally weak on KDE.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
No longer relevant (for me) in 2019.
