GNOME Bugzilla – Bug 104011
If current gedit instance is on another workspace then --new-window should be implied
Last modified: 2005-03-13 23:52:10 UTC
I'm using gedit 2.1.4 that comes with the redhat phoebe beta. gedit crashes when you try and open a text file with gedit when gedit it running on another desktop. steps to create: 1. open a text document in gedit using the nautilus "open with" menu 2. switch to another desktop and open a text document in gedit 3. switch back to the first desktop and close gedit (should still be running on the other desktop). 4. open a text document with gedit on the first desktop. this will cause all instances of gedit to crash.
FWIW, in part 4 of my steps above, you should open the new text document using the nautilus "open with" menu.
Please could you use bug-buddy to get a stack trace of the crash and submit that to bugzilla. Thanks.
How do you open the text in step 2? Was gedit already running before step 1?
In step 2 I used nautilus "open with" menu. I'll submit a stack trace tonight when I get home from work.
clarified steps 1. open a text document in gedit using the nautilus "open with" menu. Leave gedit running. 2. switch to another desktop and open a text document in gedit using the nautilus "open with" menu. Leave gedit running. 3. switch back to the first desktop and close gedit (should still be running on the other desktop). 4. open a text document with gedit on the first desktop using the nautilus "open with" menu. this will cause all instances of gedit to crash.
Gedit is NOT running prior to step 1.
What do you mean with "Desktop"? Are you referring to different Workspaces or to different heads in a multihead configuration?
different workspaces (the kind you can switch to using that applet on the panel)
I cannot reproduce this bug. Note that when I use nautilus to open the 2nd file in the 2nd workspace the gedit window moves to the current workspace. So when I return to the 1st workspace the gedit window is no more there. We really need a bt. <paolo> are you able to reproduce bug #104011? * snorp looks <snorp> oh <snorp> yeah, I saw the mail <snorp> I can't repro it <paolo> hmmm... me too <paolo> but I have seen another problem <snorp> hmmm <paolo> when you use nautilus to open the 2nd file in the 2nd workspace <paolo> the gedit window moves to the current workspace <snorp> yeah <paolo> I think this is a bit confusing <snorp> I think because we gtk_window_present() it <snorp> yeah, possibly <paolo> yep <snorp> but <paolo> I think we should try to emulate the --new-window behavior in this case <snorp> oh <snorp> hmmm <paolo> but I dunno how <snorp> yeah <paolo> any idea? <snorp> hmmm <snorp> so you think if the current instance is on another workspace <snorp> that --new-window should be implied <paolo> yep <snorp> hmmm <snorp> seems hard <paolo> we need a bonobo-activation magic <snorp> would have to add a "getWorkspaceNum()" or something <snorp> to Gedit::Window <snorp> hmm <snorp> I don't think any b-a stuff is required <paolo> if current workspace is different from workspace of the current active window <paolo> then <snorp> right <snorp> but I dunno how to get the workspace of the current window :/ <paolo> if there aren't opened windows in the current workspace open a new window <snorp> maybe some libwnck stuff <snorp> right <paolo> otherwise set an opened window in the current workspace as active <snorp> yep <snorp> problem is <snorp> I don't think libwnck is a dep that gedit can have <snorp> (hopefully I am wrong) <paolo> wnck_window_get_workspace <snorp> yeah <paolo> wnck_window_is_on_workspace <paolo> these are what we need <snorp> yep <paolo> good, I will attach the IRC log to the bug <snorp> hmmm <snorp> ok <snorp> I guess nautilus would also have to pass the current workspace to gedit? <snorp> so we know what to compare to? <paolo> hmm... I think it is safe to assume that the user is using nautilus from the current workspace <snorp> right <snorp> but how do we know what the current workspace is? <snorp> (we don't necessarily have a window on the workspace) * paolo looks in libwnck <paolo> wnck_screen_get_active_workspace <snorp> aha <snorp> good :) <paolo> now we need to know the active screen <snorp> oh <snorp> gdk_screen_get_default() should be ok <paolo> yep <snorp> (since nautilus will be invoking it with a proper environment)
here's the stack trace: Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...0x40795bc2 in waitpid () from /lib/i686/libpthread.so.0
+ Trace 32990
sorry about the initial steps... I just got home and can now further explain: 1. open a text document in gedit using the nautilus "open with" menu. Leave gedit running. 2. switch to another workspace and open a text document in gedit using the nautilus "open with" menu. Leave gedit running. it should open as a tab in the gedit window on the first desktop. 3. right click on the tab for the file you just opened and choose "move to new window." it should open the file in a new gedit window. 4. move the new instacne of gedit to the second workspace using your window manager (metacity in this case) now you should have an instance of gedit running on each workspace. 3. switch back to the first workspace and close gedit (should still be running on the second workspace). 4. open a text document with gedit on the first workspace using the nautilus "open with" menu. this will cause all instances of gedit to crash.
actually it seems to generate 2 crashes one right after the other (each instance of gedit I suppose...): Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...0x40795bc2 in waitpid () from /lib/i686/libpthread.so.0
+ Trace 32991
I still cannot reproduce this bug. BTW, we had a similar bug, but IIRC with different stack trace, that we have fixed in gedit 2.1.5. This could be a duplicate of it. Could you please update your gedit and lemme know if you are still able to reproduce this bug? James: the crash seems to happen in egg_recent_view_set_model. Any idea?
I'll upgrade and see if I can reproduce it. Should I upgrade to the latested version or just 2.1.5?
Latest please (i.e. 2.1.91)
the crash does not occur in the latest version (2.1.91). It would be nice however if when you opened a text file with gedit using the nautilus "open with" menu it would open the file on the current workspace in it's own instance of gedit rather than as a tab in an already running instance of gedit. The current behavior is very confusing. just my 2 cents...
I agree, read the attached IRC log Changing summary
*** Bug 114013 has been marked as a duplicate of this bug. ***
Paolo, Some further thinking regarding this, because I'm starting to think gedit moving between workspace has some annoying secondary issues which can't simply be resolved using the --new-window flag. Okay, try this. 1. Open a gedit window. 2. Click open file. Note that the default directory is ~ (your home directory.) 3. Click cancel to shut the Open File dialog. 4. Move to a new work space. 5. Open a terminal. 6. Type 'cd /tmp' and hit enter. 7. Type 'gedit --new-window' and hit enter. 8. Click open file on the new gedit window. Note that the default directory is still ~ (your home directory.) One of the great thing I love about launching applications from the command line is that it effectively uses the current directory as the default directory. Unfortunately, the --new-window option doesn't handle this appropriately negating much of the benefit of being able to run mutliple gedit windows. Also, having to type --new-window to get a new instance of gedit is a PITA. As a result of experiencing these behaviours, I would propose that gedit, should: * Open a new window each time it is started. * Set the default directory according to where gedit was started. The current behavior is confusing, and interfers with expected functionality.
*** Bug 119429 has been marked as a duplicate of this bug. ***
From bug #128541: New documents should not be opened in tabs if document not opened through file->open I had a gedit window with a new document opened on one desktop. I opened nautilus and was looking at my files. I double clicked on one, and it opened in gedit. The existing gedit window moved to the new desktop, and opened the document in a second tab. I finished with the document and closed the window. Got a dialog asking to save the file... (Save the file? I didn't touch it!) So I clicked okay. Bam. Lost the old document. This behavior is confusing and annoying. And it just caused me to lose data.
*** Bug 128541 has been marked as a duplicate of this bug. ***
I strongly agree with comment 21. New documents should not be opened in tabs if the document was not opened through an existing instance of gedit via "File -> Open" (or the "Open" button on toolbar). Even if there is already a running instance of gedit on the current workspace, and I open a separate document from a separate directory from nautilus, it should still open as a separate gedit window with it's own distinct working directory. Of course, it would still be nice to be able to drag the tab from the newer gedit to the older gedit, and vice-versa, even though people would rarely need to do that.
Is this really an enhancement, or is it a bug?
*** Bug 143341 has been marked as a duplicate of this bug. ***
just a reminder: galeon has some utility code to deal with workspaces that may be useful http://cvs.gnome.org/viewcvs/galeon/utils/gul-x11.c?rev=1.1&view=auto
Created attachment 38253 [details] [review] patch Sorry for getting to this so late in the release cycle, however my gedit install was a bit brocken (a new instance was always launched, so I didn't notice this bug anymore) Note that with the metacity changes this gedit bug has become much more evident and confusing: now if you have a gedit window open on workspace 1 and you double click on a text file in workspace 2, the text file is opened in window on workspace 1, but the user is left on workspace 2 without even realizing that the file has been opened at all. (To clear things up, the behavior with older releases was that the already opened gedit window was moved on the current workspace, which was a bug, but way less confusing). The current behavior is IMHO critical because by note realizing of having opened the file in another workspace the user may even loose data (open the file in another editor becase gedit "doesn't open" the file, modify, then switch workspace and be prompted by gedit to save the file which was in fact opened and by saving overwrite the changes made). The patch implements the proper behavior: if a gedit window is already availbale in the current workspace, open the file there otherwise opene a new toplevel window. The patch is not very small but it is pretty simple and the two new functions used to detect workspaces are cut & pasted by galeon, so are well tested. The patch works well for me, but obviously some more testing is appreciated. Given the above considerations I think that we should ask for inclusion of this patch (modulo problems in the patch itself) in gedit 2.10.
bumping prio
Comment on attachment 38253 [details] [review] patch Hi, sorry for the late reply but I have a flue. >- Window getActiveWindow (); >+ Window getActiveWindow (in long workspace); Since the semantic of the function is changed, I think we should try a better name. >- bonobo_ui_component_remove_verb (ui_component, verb_name); >+ if (bonobo_ui_component_path_exists (ui_component, path, NULL)) >+ { >+ bonobo_ui_component_remove_verb (ui_component, verb_name); > >- bonobo_ui_component_rm (ui_component, path, NULL); >- bonobo_ui_component_rm (ui_component, cmd, NULL); >+ bonobo_ui_component_rm (ui_component, path, NULL); >+ bonobo_ui_component_rm (ui_component, cmd, NULL); >+ } Why this change? > > > static GNOME_Gedit_Window > impl_gedit_application_server_getActiveWindow (PortableServer_Servant _servant, >+ const CORBA_long workspace, > CORBA_Environment * ev) Have you tested this function with sticky windows? I'm not sure it works as expected with sticky windows. >+} >+ >+/* the following two functions are courtesy of galeon */ >+ >+enum { X11_ALL_WORKSPACES = 0xffffffff }; s/X_11_ALL_WORKSPACES/GEDIT_ALL_WORKSPACES. >+guint >+gedit_util_x11_get_current_workspace (GdkScreen *screen) I'd remove x11 from the name. >+guint >+gedit_util_x11_get_window_workspace (GtkWindow *gtkwindow) Ditto. This patch is needed and is a nice improvement in the way gedit works with multiple workspaces. But I have a few questions: Why gedit does not behave in the same way it worked in previous releases? It is still a gtk_window_present problem? Are we sure it is not a Metacity problem? I'm not sure this is a blocker, we could release a gedit 2.10.1 release a week after 2.10.0 eventually. BTW, with the little changes I have proposed, I accept the patch, if you want you can try to ask the release team for a freeze break, even if it is very late.
Created attachment 38289 [details] [review] improved patch Here is the updated patch following your suggestions (at first I didn't bother renaming the function because I still hope that bonobo stuff will go away soon). It solves the problem with sticky windows: now to decide if a window is ok the condition is (is_in_this_workspace || is_sticky) >>- bonobo_ui_component_remove_verb (ui_component, verb_name); >>+ if (bonobo_ui_component_path_exists (ui_component, path, NULL)) >>+ { >>+ bonobo_ui_component_remove_verb (ui_component, >>verb_name); >> >>- bonobo_ui_component_rm (ui_component, path, NULL); >>- bonobo_ui_component_rm (ui_component, cmd, NULL); >>+ bonobo_ui_component_rm (ui_component, path, NULL); >>+ bonobo_ui_component_rm (ui_component, cmd, NULL); >>+ } > >Why this change? because bonoboui spews bad warnings. The problem was there before the patch, but the patch makes it easy to trigger: when rebuilding the menu to add new items we walk the list and remove all, but the list also contains the new docs for which we have not yet a menu item. I'm running this patch by the release team, because in my opinion is a very confusing behavior. (when I experienced it yesterday I understood that windows were opening in other workspaces only because I remebered how the code worked) Beside including this patch in a gedit 2.10.1 soon after the release sound like a workaround to me: what you gain? Distros and users will soon end up adopting the version which includes the patch and the patch will not magically become "better" in this week.
committed.
*** Bug 170236 has been marked as a duplicate of this bug. ***