GNOME Bugzilla – Bug 69260
No way to run two instances of Galeon on the same machine
Last modified: 2014-08-26 19:51:00 UTC
I'm logging into my home machine via ssh with X11 forwarding, so i get a new $DISPLAY. Whatever i'm doing (including to set $HOME to a different value), when i attempt to start a Galeon, i get: Message: Galeon already running, using existing process But well, if i'm running on a different $DISPLAY (:10.0 vs. :0.0), it makes no sense to ever use the existing process. Ideally, i think it should even be possible to share a single ~/.galeon/ directory (the second instance needs to treat it read-only, as Netscape used to do it in that case), but i could even live with e. g. setting $HOME to /tmp in that case.
it probably should.....
Just a quick note, from somebody who finds the current behaviour a bit irritating as well... I use my main workstation and two X terminals, so this affects me quite a bit. I end up killing Galeon processes all the time, or using 'galeon -q' or whatever(okay, I'm lazy, I just kill them :). The original reporter demanded a new process be started. I'm a wee bit more moderate then that ;) Personally, I would love it to use the exising process, but create a new window(as if -n had been given), but in whatever display $DISPLAY is set to. Best of all worlds :) I imagine this is terribly non-trivial, though, so don't worry 'bout it :)
I'm thinking that creating a new process would be easier to implement, 'cause you've to open a new connection to the new X server with gtk_init or gnome_init. But maybe I'm wrong!
*** Bug 67609 has been marked as a duplicate of this bug. ***
The relevant function is this: /** * new_view_on_running_shell: * * Create new view on existing shell. * Returns false if no shell is currently running. */ void new_view_on_running_shell () It is making the decision based on Galeon being registered with OAF. I made a testbed with the relevant code to see what was going on, which I will attach. Compile it like: gcc `oaf-config --cflags --libs` -o oafinfo oafinfo.c Output for me: ]./oafinfo Message: OAFAID:[OAFIID:GNOME_Galeon_Automation,jb,gil.uruk,session] Implementation ID: OAFIID:GNOME_Galeon_Automation User: jb Host: gil.uruk Domain: session Message: Galeon already running, using existing process I think maybe $DISPLAY needs to be worked into the OAF registration somehow(maybe in the currently uninformative 'domain' field?). But that's just a guess. I can look into this further if desired.
Created attachment 6672 [details] shows Galeon OAF registration info.
I think that the actual problem is that multiple instances of Galeon aren't able to peacefully co-exist -- they'll write over each other's history and bookmarks and share the same gconf settings. Mozilla will probably have huge problems with multiple instances sharing the same cache dir, too.
I'm not saying doing this is a good idea. In my case, which is a cafe-kiosk/freebox use, I actually want things as read-only as possible, so for example I have the bookmarks non-writable (which causes an annoying alert box, but works), also almost everything in .gconf/* . For my purposes, I'd like to be able to have a server with a (possibly variable) number of X-term type machines using it, and have them all use one account, instead of having to have a separate account for each machine, and have that account be read-only. When I tried this with my gdm/gnome/sawfish/Galeon setup, Galeon was what made it unworkable. Everything else was OK with it, (or oblivious).
*** Bug 74062 has been marked as a duplicate of this bug. ***
*** Bug 75887 has been marked as a duplicate of this bug. ***
Galeon should not try to spawn a new window/tab, if the running galeon process uses a different display. Instead it should display a message box telling the user that it is currently not possible to run two galeon processes from the same home directory. Would be nice to get this into galeon 1.2, there have already been four bug reports in Debian requesting this issue...
Erich's suggestion entirely misses the point: The way it is now, it's not even possible to run two instances of Galeon for the same user account with different values of $HOME. (As i wrote in my initial report, that would have sufficed for me, since i could temporarily set $HOME to e. g. /tmp in order to run the second instance.)
*** Bug 79337 has been marked as a duplicate of this bug. ***
*** Bug 79527 has been marked as a duplicate of this bug. ***
*** Bug 80749 has been marked as a duplicate of this bug. ***
*** Bug 83038 has been marked as a duplicate of this bug. ***
A simple way to fix this would be to use a manager selection for uniqueness instead of OAF. Manager selections are described in section 2.8 of the ICCCM. A proper clipboard program would use one, and an XSETTINGS daemon (such as gnome-settings-daemon) also uses one. Selections are per display and a program can use a specific format for the selection atom string for further uniqueness; usually the suffix _Sn where n is the screen number - e.g., a window manager for screen 0 is supposed to manage the selection WM_S0. A good selection name would be _GNOME_GALEON_Sn where n is the screen numnber. Start-up would then consist of first checking for an existing manager selection (see XGetSelectionOwner) If one exists than galeon is already running where it should. Notifying the existing process can be handled in a few ways - one method is described in the ICCCM, another is used by XSETTINGS. If no selection manager exists, then the starting process should claim the selection (see XSetSelectionOwner) as described in the ICCCM and proceed ordinarily.
*** Bug 84981 has been marked as a duplicate of this bug. ***
*** Bug 85253 has been marked as a duplicate of this bug. ***
Hello, I've created a patch to allow "kamikaze users" to force the creation of a new process, warning them about their session, prefs and so on, but allowing them to use galeon on multiple displays. See http://www.geekounet.org/patches/files/galeon_new_process.patch Regards, Colin
*** Bug 90734 has been marked as a duplicate of this bug. ***
Is anybody working on this? Why this has severity ENHANCEMENT with LOW priority? Personally, I would see it as at least MAJOR with HIGH. I think it is not very unusal thing to use browser on multiple terminals. As www browser is used to provide help for users, and many documentations are in html, a www browser is a must on todays computers. It simply kills the idea of multiple logins.
*** Bug 95788 has been marked as a duplicate of this bug. ***
*** Bug 100542 has been marked as a duplicate of this bug. ***
There has been some changes in bonobo-activation which may fix this on the gnome2.2 platform. Could anyone test if it works or not ?
galeon 1.3.4, and it still shows this behaviour. I have bonobo-activation 2.2.1 in a gnome 2.3 environment. Please bump the version number on this bug. Steps to reproduce: Login to gnome on display :0.0 using gdm Run 'galeon' Login on display :20.0 using gdmflexiserver Run 'galeon', or 'galeon --display=:20.0', from any terminal on either display You get: ** Message: Galeon already running, using existing process and a new galeon window appears on display :0.0 Expected behaviour: A galeon window appears on display :20.0 I note that 'galeon --display=NOTADISPLAYNUMBER' fails as expected, i.e. galeon does not provide any new window.
*** Bug 124103 has been marked as a duplicate of this bug. ***
*** Bug 125925 has been marked as a duplicate of this bug. ***
(I just reported this bug too - sorry for the duplication) I would be quite happy to keep a single instance of galeon running on the machine so long as new windows are opened on the right display. How hard would it be to extend the protcol that galeon uses to contact existing instances of itself to pass the value of the DISPLAY variable? If that can be done, it doesn't look too difficult to open a new window on another screen. See http://developer.gnome.org/doc/API/2.0/gdk/multihead.html gdk_display_open () gdk_display_get_default_screen () gtk_window_set_screen ()
I've hacked up a proof-of-concept patch along the lines of my previous comment. we extend the GaleonAutomation.idl, loadUrl method with an extra parameter boolean loadurl (in string url, in string geometry, + in string display, in boolean fullscreen, so when galeon starts up we pass the default display for that process in galeon-main.c: display = gdk_display_get_name(gdk_display_get_default()); then we add a bunch of plumbing to get the value to the right place (this part of my patch is just a hack to get it to work). Finally in the bit where the new window is created we do: in galeon-shell.c: window = galeon_window_new (); + /* open the window on the right display */ + if (strcmp( + gdk_display_get_name(gdk_display_get_default ()), + display) + != 0) + { + GdkScreen *screen = gdk_display_get_default_screen( + gdk_display_open (display)); + gtk_window_set_screen(GTK_WINDOW(window), screen); + } And that seems to work. I tested it using Xnest. So my concluson is that for a galeon hacker who knows what they're doing (ie not me!) this change shouldn't be too difficult.
I attached a patch to an epiphany bug that does this, #69260. Galeon implementation should be similar I guess. The real problem is session management ... session is per disaply in fact.
The Epiphany one is bug 112779
Duncan, Could you attach this patch?
Created attachment 27374 [details] [review] galeon-display.patch hack to pass $DISPLAY to right place Sorry, I didn't notice your request for the patch untill today. (it's against the version of the time which was 1.3.9) I've attached th patch but you'll agree that it is really just a proof-of-concept hack. It's not at all pretty. I hope you can see what I was trying to show. However I was just re-reading the thread on the smae bug in Epiphany and they think it is not as simple as doing what my patch does, which is simply to pass the $DISPLAY env variable to the point in the code where the window is actually created. In particular see comment #13 and after: http://bugzilla.gnome.org/show_bug.cgi?id=112779#c13
*** Bug 149929 has been marked as a duplicate of this bug. ***
*** Bug 306822 has been marked as a duplicate of this bug. ***
For a demonstration of how galeon (and mozilla, and all the others) could do this quite successfully, look at how xemacs and gnuclient does it. Start up xemacs (possibly recent emacs works as well, although gnuclient always seemed inferior there) on localhost. Type M-x gnuserv-start. Ssh into your box. Run gnuclient from the shell. Watch in amazement as exactly the same session pops up remotely. There is only one process, running on the server. gnuclient talks to a socket and/or port, and pipes in an elisp statement to the xemacs server. The xemacs server runs that elisp code, which basically contains the display name/number to use, along with possibly any security details (Xauthority settings, permission files, etc). A new frame pops up on the remote display. The new frame still has any environment variables and settings and filesystem from the xemacs server, but I don't know what it does about fonts on the remote Xserver. None of this messing about with gnome daemons and consitency checks in cache directories et al, because everything is taken from the server process (and this works very much well enough for xemacs, so I don't see why it wouldn't work for a browser). When you close the file being edited, the gnuclient process is told it can exit. Hence gnuclient is very lightweight, it just asks to open a file or display, or other elisp code on the server, and waits around until it is told it can go. Hell, xemacs seems to handle you destroying windows on some displays and not others if an Xsession crashes, without itself crashing! Funny thing is, it can even do terminals. Although I don't think galeon is compiled with AA support :) If this doesn't work for you when trying gnuclient, read the SECURITY section of the manpage for gnuclient. It has been so long since I set this up for myself, and it has worked ever since without a problem, that I may have forgotten some useful information...
Galeon has not seen any code changes since May 2010: https://git.gnome.org/browse/archive/galeon/log This project is not under active development anymore and got recently archived in GNOME Git. It is currently unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. If you are interested in maintainership, inform https://mail.gnome.org/mailman/listinfo/desktop-devel-list