The following questions come up often on IRC and in the mailing lists. If you have any suggestions for this file, such as additional questions or answers, please mail them to the galeon-devel mailing list at galeon-devel@lists.sourceforge.net.
This header is part of Mozilla, and you need to either install the Mozilla source or find a Mozilla-devel package containing the appropriate headers. This also applies for nsI*.h. These steps are described in detail on the website and in the INSTALL file.
First, try updating to a newer version. If the problem persists, try visiting the same page in Mozilla. If Mozilla crashes as well, your problem is likely a Mozilla bug. It can be reported at http://bugzilla.mozilla.org/. If the crash only occurs in Galeon, please file a bug report (after checking for duplicates) at the GNOME bugzilla site (reachable via Help->Report a bug, or at http://bugzilla.gnome.org/).
The assertion usually looks like:
** CRITICAL **: file mozilla.cpp: line 64 (gboolean mozilla_load_prefs ()): assertion `prefService != nsnull' failed.
If this happens, it usually means there is a problem or incompatibility with your Mozilla installation. Try manually exporting/setting your MOZILLA_FIVE_HOME environment variable and then executing galeon-bin. This is known to work sometimes, but it's also known to not work for some users (Debian installations in particular).
Another time when this has been known to happen is when the Mozilla has been updated/changed with old lingering user files that (for some reason) are causing problems. Removing Mozilla user files (rm -rf ~/.mozilla") and/or removing Galeon's Mozilla profile files (rm -rf ~/.galeon/mozilla/galeon) may fix this problem. Be sure to back up any important files in these directories (such as Mozilla bookmarks, preferences, etc.) if necessary.
Galeon supports scrollwheel mice natively. If your other applications work fine with the wheel and Galeon does not, it could be because other programs (such as Imwheel) are interfering. However, even with Imwheel the wheel can still be used if the wheel is pushed down while scrolled (I'm not sure why, and this may only be true for Logitech mice).
If your wheel doesn't work at all for any applications, you probably need to configure your X server. For XFree86, this can be done by adding the line ZAxisMapping 4 5 to the Pointer (mouse) section of XF86Config.
If you still want to use imwheel for the wheelmouse support in other applications, you can place the following two lines in your ~/.imwheelrc file and restart imwheel to tell it not to interfere with Galeon:
"^Galeon" @Exclude
First of all, from the very start Galeon has always intended to be a GNOME web browser. If you don't use GNOME, then Galeon probably isn't a very good choice for the time being.
So why lock Galeon into the GNOME environment? There are many advantages to using the existing GNOME libraries. Contrary to what some think, depending on existing libraries to do typical tasks in modern desktop applications is not bloat. In fact, it's the exact opposite of bloat. The bottom line is that implementing our own toolbar, our own configuration mechanism, our own session management, and our own dialogs would be counter-productive.
Galeon relies on many standard GNOME libraries (GTK+, libgnome, libglade, libxml, etc.). Given these requirements, how much would we gain by removing the GNOME dependency? This is not only illogical, but conflicts with some of Galeon's other goals of integrating nicely with the GNOME desktop.
However, if you absolutely don't want to use GNOME, there is now a project known as SkipStone which implements a GTK+-only web browser.
This is due to the fact that you're trying to compile Galeon and Mozilla with a different compiler version. Download the right Mozilla package for your distribution (take a look at http://galeon.sourceforge.net/download.html).
Note that both applications must be compiled not only with the same version of compiler, but also with the same compiler flags. For example, with gcc Mozilla by default adds -fno-rtti and -fno-exceptions or -fno-handle-exceptions (depends on gcc version). Galeon now adds -fno-rtti, which should be normally be sufficient. This can be disabled with the --enable-cpp-rtti flag to ./autogen.sh.
If you need further flag changes, you have two chances to get things in sync:
# sh # Build configuration script # # See http://www.mozilla.org/build/unix.html for build instructions. # # Options for 'configure' (same as command-line options). ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --enable-strip-libs ac_add_options --enable-crypto ac_add_options --enable-optimize
Configure Mozilla with standard configure script and compile it. Before configuring Galeon set the proper CXXFLAGS. For example, with latest version of gcc:
CXXFLAGS='-fno-exceptions' export CXXFLAGS
For more see configure.in in the Mozilla source. You can save some space by disabling RTTI.
On Linux systems, threads are essentially visible as separate processes to many user-space applications. This means that process X, using 10MB of memory with 5 threads sharing that same 10MB will appear to consume 50MB (though it is not). Only count one process, not all of them (this is true for many other applications besides Galeon).
Make sure the MOZILLA_FIVE_HOME environment variable points to the directory where the Mozilla executables are installed. If Mozilla is compiled from source, try [mozilla_build_dir]/dist/bin.
GnomeUI-ERROR **: file gnome-icon-item.c: line 304 (get_default_font): assertion failed: (default_font != NULL)If so you need to properly set your language environment. Example:
export LANG=de_DE
This problem has been observed with out of date versions of Oaf (including 0.6.1). Upgrade to 0.6.5 (availble from Ximian).
This can also be caused by the GNOME_Galeon_Automation.oaf file not being installed in a place that oaf can look for it.
If you've compiled Galeon from a source tarball, chances are it's installed it in /usr/local/share/oaf/GNOME_Galeon_Automation.oaf. However, oaf isn't searching this directory, so when you start another copy, oaf tells Galeon that it isn't running and it doesn't know to attach.
To fix this, make a symlink called /usr/share/oaf/GNOME_Galeon_Automation.oaf which links to /usr/local/share/oaf/GNOME_Galeon_Automation.oaf, or alternatively add export OAF_INFO_PATH=/usr/local/share/oaf (for sh scripts) or setenv OAF_INFO_PATH /usr/local/share/oaf (for csh scripts) to your shell startup. If the GNOME_Galeon_Automation.oaf file is being installed into a different directory, you will have to use that instead. When you start Galeon twice, it should attach and open a new window/tab in the existing process. You may need to restart your X session and/or gconfd (gconftool --shutdown) and oafd (killall oafd) for the changes to take effect.
Another possibility is that the value of the DISPLAY environment variable differs in the two locations from which Galeon is being started. Frequently, DISPLAY will be set to :0 in the window manager, but to :0.0 in terminals. One way to work around this is to set the variable to :0.0 in your X startup script (usually ~/.xsession or ~/.xinitrc), by adding the line export DISPLAY=:0.0 (for sh scripts) or setenv DISPLAY :0.0 (for csh scripts).
If you want to rebind a shortcut, Galeon supports the standard GTK+ way of changing shortcuts: simply hover over the menu option with the mouse pointer and press the keyboard shortcut you want to rebind it to.
./configure: line 538: syntax error near unexpected token `AM_INIT_AUTOMAKE(galeon,'
Make sure you have xml-i18n-tools installed and try again.
First and foremost, be sure you have a new GConf (1.0.7 is the latest at this writing) rather than an old one. In particular, 1.0.4 is too old and causes problems.
If you do ps jaxwww | grep gconf and see two gconfd-1 processes, that's what's wrong; just kill them both and restart Galeon. This problem has not been reported with GConf 1.0.7, only older versions.
If you have trouble with 1.0.7, most likely it's because your home directory is NFS-mounted and either your operating system doesn't support locks in NFS directories or you have stuck locks due to a hard system crash. Try rm -r ~/.gconf*/*lock if you are sure you have no gconfd processes (for your login name) running on any machine using your NFS home directory. If you nuke the lock when gconfd is running and bad stuff happens, it's your own fault. ;-)
If you want to use GConf while logged in from two different machines, sharing the same home directory, you must enable TCP/IP for ORBit by adding the line ORBIIOPIPv4=1 to /etc/orbitrc and restart gconfd. You will need to do this on both machines; one machine will contact the gconfd running on the other. This setup is poorly tested but should work.
It's possible schema installation failed when you installed Galeon, so you can try reinstalling them as follows:
GCONF_CONFIG_SOURCE=`gconftool-1 --get-default-source` \ gconftool-1 --makefile-install-rule /etc/gconf/schemas/galeon.schemas
Be sure your GConf config file is set up correctly by editing the path file in the directory $sysconfdir/gconf/1. A basic configuration for the default backend would look like:
xml:readonly:/etc/gconf/gconf.xml.mandatory include "$(HOME)/.gconf.path" xml:readwrite:$(HOME)/.gconf xml:readonly:/etc/gconf/gconf.xml.defaults
You can also take a look at $sysconfdir/gconf/1/path.example and in most cases you can simply move it to $sysconfdir/gconf/1/path. Be sure that the path file can be read by all users.
Ensure you have a $sysconfdir/gconf/gconf.xml.defaults dir set up with the right permissions. In most cases you can run chmod -R 755 $sysconfdir/gconf/gconf.xml.defaults.
WARNING: The GConf deamon makes heavy use of a cache so when changing your setup you will probably need to restart it.
Be sure you have no applications depending on gconf running and then run:
gconftool --shutdown
GConf will then restart when it is required.
If none of the above works, enable user syslogging and see if gconf is logging any error messages. On Linux, to do this try adding this line to /etc/syslog.conf:
user.* /var/log/user
then run service syslog restart, reproduce your gconf problem, and look in /var/log/user for messages. If gconf is failing to get a lock then the issue is probably the NFS thing mentioned earlier. Otherwise maybe there are other informative error messages.
If you still can't figure it out, try mailing gconf-list@gnome.org, describing what happened when you tried all of the above and what version of gconf you have, what exact error messages you get, etc.
We still don't know why. Any insight on this will be highly appreciated. We believe its a gconf glitch.
When the Galeon with apparently messed-up prefs starts, and you are sure you did set all your prefs right the previous session, go to a terminal window and run killall gconfd-1. After restarting Galeon, your prefs should be back to normal.
Galeon uses external conversion programs to render all info and man content as HTML. Thus, these programs have to present if info and man pages are to be viewed. We use gnome-man2html2 and gnome-info2html2 which are part of the Nautilus package. So, if you don't have Nautilus installed, you won't have these programs. We know that there will be plenty of people who haven't got Nautilus installed, so we're going to put together a separate package for the conversion programs, hopefully pretty soon. :-)
The new style of SGML help documents (gnome-help:, so far only supported by nautilus itself) require gnome-db2html2 from Nautilus.
The normal GNOME help documents, which are regular HTML files (and accessed through the ghelp: protocol), do not require an external converter.
The toc: pages (toc:, toc:man, toc:info, toc:ghelp, toc:gnome-help) also don't require anything special.
This feature is already implemented. It is not in the UI because there was a Mozilla bug that made Galeon crash at startup with some strings.
You can set the user agent from the command line using GConf:
To get the current user agent:
gconftool -g /apps/galeon/Advanced/Network/user_agent
To set the user agent to XXX:
gconftool -s /apps/galeon/Advanced/Network/user_agent --type=string "XXX"
To restore the default user agent:
gconftool -s /apps/galeon/Advanced/Network/user_agent --type=string default
Galeon needs to run once as the user that owns the Mozilla distribution directory, because Mozilla wants to write some files there.
Make sure that the file GNOME_Galeon_NautilusView.oaf is correctly installed (it shuld be in /usr/share/oaf in most setups) and restart oaf. Also, you'll have to setup Nautilus to use Galeon to render HTML, once Galeon has been installed (to do so, you have to select the View as other... option in the Nautilus view selection optionmenu).
See the plugins section of the User Manual (plugins.html).
The common cause for this is an incorrectly set LC_CTYPE environment variable. You can see this by typing the command locale in a terminal window.
The LC_CTYPE variable controls what character set applications should use for their output. If LC_CTYPE is unset or set to "C", this essentially means that applications are expected to use ASCII for their output. The problem is that ASCII doesn't include any international characters, and hence international characters won't get displayed correctly, if at all.
You can easily correct this by making sure the LC_CTYPE variable is set to your locale, like LC_CTYPE=de_DE if you are in Germany. This will make sure that applications can correctly display your native characters. Please note that it will not change the language of the applications, it only changes the character set used.
To use Java in Galeon, you'll need to install a plugin for Mozilla.
You can download the Linux x86 version of Sun's Java Runtime Environment (JRE) from http://java.sun.com/j2se/1.3/jre/download-linux.html. Once you've installed it, you'll need to create a symbolic link in your Mozilla plugin directory to the plugin file. The plugin file is at [JRE directory]/plugin/i386/libjavaplugin_oji.so.
If you prefer, you can instead install Sun's Java SDK, or the SDK offerred at http://www.blackdown.org/. If you're on a different platform, you may need to use a different vendor's Java environment. As long as they provide a Mozilla-compatible plugin, though, things should still work.
Once you've installed the plugin, it should be visible on the about:plugins page, and if you have the Allow Java preference enabled, Galeon should be able to run Java applets.
A likely cause for this is an errant Mozilla preference. Exit Galeon and open ~/.galeon/mozilla/galeon/prefs.js in your favorite text editor, and look for a line that tells Mozilla how to handle the problematic MIME type. If you find such a line, delete it and save the file. After doing this, the MIME type should be handled correctly in Galeon.
It is also possible that the MIME type has been registered by the Plugger plugin. Plugger is a wrapper plugin that passes unsupported files from the browser to external programs. To check which files are being handled by Plugger, examine the /etc/pluggerrc file. You can either edit the file so that Plugger will use different programs, or delete the offending lines altogether so that Galeon will handle the file types instead. For file types that are often embedded in documents (like WAV sound files or MIDI music files), it may make more sense to use Plugger, as Galeon is unable to launch helper applications for inline content. Please see the Plugger documentation for more information.