GNOME Bugzilla – Bug 149617
Unable to download/save a file from within galeon
Last modified: 2004-12-22 21:47:04 UTC
If I click on a link to download (say, an RPM-file), galeon displays a dialog, telling that "It is not possible to view this file directly in the browser. You can save it instead". There're two buttons also in this dialog, cancel and save. But these buttons seem not to work at all (I can't even close the dialog w/ 'Cancel' button and have to use 'close' button in the window title), it just looks like the buttons are unbounded at all. However I noticed the following lines appearing in ~/.xsession-errors:0 just right after I click on a file link to download: ** (galeon-bin:28202): WARNING **: callback function not found: mime_ask_dialog_save_clicked_cb ** (galeon-bin:28202): WARNING **: callback function not found: mime_ask_dialog_toggle_helpers_toggled_cb ** (galeon-bin:28202): WARNING **: callback function not found: mime_ask_dialog_open_clicked_cb ** (galeon-bin:28202): WARNING **: callback function not found: mime_ask_dialog_cancel_clicked_cb ** (galeon-bin:28202): CRITICAL **: file gul-gui.c: line 520 (gul_gui_image_set_from_mime_type): assertion `icon_info != NULL' failed Maybe it's worth to mention that I DON'T use GNOME desktop environment, although I have recent enough GNOME libs and stuff: libgnome-2.6.1.1 gnome-desktop-2.6.2 gnome-control-center-2.6.1 etc. The problem is reproduced w/ and w/o gnome-settings-daemon running (all my previos weird problems w/ galeon could be solved just by launching gnome-settings-daemon).
Well, just noticed that saving a file w/ some apps registered as handlers in MIME database (a dialog w/ three buttons: save, cancel, open) doesn't work either. And again buttons look like anattached ones, like if developer forgot to bind a reasonable callback to button pressing event.
Please make sure that Galeon is installed properly and that there is no extra galeon.glade file in ~/.galeon directory.
Sorry, probably this problem was due to unstable nature of my distribution (Sisyphus, development version of ALTLinux) and some binary incompabilities w/ current libraries set. After re-building galeon against actually installed libraries the problem disappeared. Sorry for the inconvinience
Created attachment 30634 [details] [review] Fix galeon build w/ new autotools Actually, I finally resolved the problem :-). The problem was/is not with incompability in libraries ABI, but in using too modern building environment :-) galeon can be perfectly (and correctly!) built w/ old GNU autotools combination (automake, autoconf, libtool). But w/ the new ones (autoconf-2.59, automake-1.8.6, libtool-1.5.8) some extra "automagic" is required. According to libtool docs if one wants to be sure that an executable is able to call dlopen(NULL,...) / g_module_open(NULL...) (i.e. resolve symbols within itself), then certain linker flags are to be added (either -export-dynamic or -dlopen self). Also AC_LIBTOOL_DLOPEN should be called befor AC_PROG_LIBTOOL. The patch provided adds these steps for galeon-1.3.17. Probably it can be safely applied even if galeon team uses reasonably older versions of autotools
I've checked this patch in, it doesn't seem to do any harm. http://mail.gnome.org/archives/cvs-commits-list/2004-December/msg03732.html