GNOME Bugzilla – Bug 333129
[Multihead] cannot launch multiple instances of gedit on different heads
Last modified: 2006-03-22 17:42:20 UTC
Origanlly filed as http://bugzilla.gnome.org/show_bug.cgi?id=91976 logging new bug to track issue in gnome2.13. Testcase 1 Select applications, accessories, text editor on screen 0. gedit is launched. on screen 1 select applications, accessories, text editor. A new instalce of gedit is launched on screen 0. Testcase 2 Open gedit on screen1, goto screen 2 type gedit --new-window expected result:- gedit should open on screen 2 actual result gedit opens on screen 1 Similarly (first close all gedit windows) Open Gedit on screen2 goto screen 1, type gedit --new-window Expected result gedit launches on screen1 actual result gedit launches on screen2
Ouch! This is going to be tricky. None of the current developers have the possibility to test a multiscreen setup :( Beside the solution adopted in the 'old' bug is not really applicable IMHO (it was broken in the first place): having two gedit applications running (I don't mean toplevel windows, I mean two gedit processes) is going to lead to other problems, for instance the corruption of the metadata file which would be written by both processes without locking.
<pbor> is there a way to know the GdkScreen an app has been launched in? <pbor> and, as a side question, can a window be moved from a screen to another? <matthias> pbor: just get the screen of your main window ? Or do you mean from the outside ? <matthias> pbor: regarding moving between screens/displays, see gtk-demo <pbor> matthias: I mean on startup... I don't have a window yet <pbor> thinking how to solve http://bugzilla.gnome.org/show_bug.cgi?id=333129 <pbor> I need a way to decide on which screen to create the new window <matthias> pbor: Xnest -scrns 2 gives you a multiscreen setup... <matthias> pbor: whats wrong with just gedit --display :0.2 ? <pbor> (good point about xnest) <pbor> matthias: well it should work also when launching from the menu or clicking on a file <matthias> pbor: doesn't do xinerama though, which is a pity <matthias> pbor: in that case, you need support from the launching app, ie the panel/nautilus, I think <matthias> pbor: they need to specify the screen <pbor> that's what I feared... <matthias> gtk really has no data beyond whats in DISPLAY <pbor> does startup-notification already provide that info? <pbor> ok, thanks <pbor> I'll investigate
I know it is not a real solution but IMHO we should: - launch multiple gedit instances (as we did) - add file locking to metadata and hope for the best (in the worst case scenario, there could be case where we will lose some metadata, but this is not a critical problem). In this case we will avoid regressions. Does SJ or totem support multihead?
I'd prefer to try to fix it for good: it seems that startup-notification should pass us the SCREEN=N
grr... should check my facts before writing :( This is what I get in the env var when launching gedit by clicking on a panel launcher gnome-panel/gedit/4894-26-murdock_TIME3148144093 no SCREEN is sight :/
Created attachment 60511 [details] [review] This patch is a first step toward fixing the problem reported in this bug report The patch still needs some work. In particular it should modify the code so that gedit create a new window when no window exists in the current workspace of the screen where the client has been launched.
Created attachment 60555 [details] [review] patch this patch (totally untested!) should do the right thing with regard to selecting an existing window on the current workspace of the current screen. Note that the app_create_window() function now takes a screen arg, so if this is ok we'll also need to update the bindings
Comment on attachment 60555 [details] [review] patch > GeditWindow * >-gedit_app_create_window (GeditApp *app) >+gedit_app_create_window (GeditApp *app, >+ GdkScreen *screen) > { I don't think we should change gedit_app_create_window. > > >+static gboolean >+is_in_workspace (GeditWindow *window, >+ GdkScreen *screen, >+ gint workspace) >+{ >+ GdkScreen *s; >+ gint ws; >+ >+ s = gtk_window_get_screen (GTK_WINDOW (window)); >+ ws = gedit_utils_get_window_workspace (GTK_WINDOW (window)); >+ >+ return (s == screen && //CHECK: can we compare pointers or should we compare number/name? Well, I don't know and so I think it is safer compare numbers and names. Have you tested the patch in the "normal" case ? I mean in the single screen case.
Created attachment 60567 [details] [review] patch after a bit of discussion we decided that modifing create_window is acceptable, so that the whole multiscreen issue is wrapped in the GeditApp class. I was also told that comparing screen pointers was ok, but when I tried it didn't seem to work, so here I strcmp the display name and the screen number.
Created attachment 60574 [details] [review] update bindings updated binding from create_window(), overridden so that the screen param is optional
Patch committed. Robert: could you please confirm it fixes the problem for you (we have not a real multihead configuration to test it).
Just FYI, gedit's copy of ephy-spinner isn't multihead-safe.
Thanks for the heads-up Christian. I overcome my lazyness and synced the code to latest ephy-spinner.
I will test the fix for this bug within the next couple of weeks
Thank you Robert. Note that we released gedit 2.13.93 which includes the fix.
this bug is verified fix on gedit 2.14, it is now possible to open gedit on both heads of a dual head display, thank you