GNOME Bugzilla – Bug 730414
New window (instead of new tab) created when opening documents from terminal, or from the file manager when gedit is tiled
Last modified: 2020-11-24 09:59:38 UTC
In nautilus, navigate to some directory with multiple text files. Double click to open one file, then the other. Sometimes the result is (a), and sometimes the result is (b): a) Two files open in two different tabs of one gedit window. b) Two files open in two different gedit windows, each with a single tab. (a) was always the behavior in 3.10. After updating to 3.12 I find that either is possible, and I don't know what causes the difference. (Sometimes I think it's timing-related, but I'm definitely not sure of this.) The attached screencast is a typical example: with one gedit window already open, opening a new document results in two gedit windows, opening another document results in three gedit windows, and all further documents open in the third window. I would expect them all to have opened in the original window instead.
No screencast due to the attachment size limit, but I think the problem is sufficiently clear?
I don't have a recently enough gnome and nautilus to test. When opening files from the command line (with jhbuild), it works fine. When the terminal is on another workspace (on Xfce), a new gedit window is opened. When a gedit window already exists on the same workspace, a new tab is opened. Maybe the workspace detection doesn't work fine in gnome-shell. Does the bug happen only when opening a file from a file manager, or does it also happen with a terminal?
(In reply to comment #2) > Does the bug happen only when opening a file from a file manager, or does it > also happen with a terminal? It also happens sometimes when running with a terminal. It's as if I was calling 'gedit --new-window' even though I'm not using that option. Just as when using Nautilus to open documents, it's not consistent: sometimes all the documents open in one existing window, and sometimes they all open in new windows.
Ok, it's maybe a regression in mutter or gnome-shell for the workspaces. The gedit code uses some X11-specific code to detect workspaces (see gedit_utils_get_current_workspace()). So this code will need changes for Wayland (or the workspace detection is simply ignored).
*** Bug 733577 has been marked as a duplicate of this bug. ***
*** Bug 750629 has been marked as a duplicate of this bug. ***
Since upgrading to GNOME 3.16 I see this issue with "half maximized" (Super + left/right arrow) gedit windows, but interestingly not with fully maximized windows. (See bug 747939.) I never saw this issue in 3.14 or earlier.
As a workaround, you can drag the file from nautilus into gedit, which will always work properly.
FWIW, I rarely use Nautilus. I’m seeing this issue when running `gedit some/file-name` from gnome-terminal. My work around lately has been to keep gedit windows not quite half-maximized, but have their bottom be some amount away of space from the bottom of the screen. This is inspired by bug 733577.
I have a similar problem, and I have not been able to find any consistency in how it chooses between a new window and a new tab. Simon Sapin's workaround doesn't work. I'm running debian-stable with gnome, so gedit 3.14.0 and gnome 3.14.1.
Created attachment 315429 [details] [review] Patch to only check screen, display and workspace for new tab This has been annoying me for a while, so here's a patch that fixes it. With this, gedit still opens a new instance for each workspace (and display), but re-uses gedit windows wherever they are on the workspace. I think this is better default behavior, since this seems to be annoying a lot of people[1][2][3][4], this version should meet everyone's needs, and if anyone really wants a new window, they can say --new-window (there is no option for the opposite). [1] http://askubuntu.com/questions/75671/why-does-gedit-keep-randomly-opening-new-instances-when-opening-files-from-nauti [2] http://askubuntu.com/questions/55522/how-to-avoid-opening-duplicate-files-in-new-windows-in-gedit [3] http://askubuntu.com/questions/44353/is-there-a-way-to-open-a-text-file-in-an-already-open-instance-of-gedit [4] http://ubuntuforums.org/archive/index.php/t-766578.html
Review of attachment 315429 [details] [review]: The commit message doesn't explain *why* the bug occurred. It looks like you've proceeded by trials and errors, until it works. Can you explain why removing that code fixes the bug? and that it is better to remove that code for all cases? Minor comments: - For the commit message, the first line should be shorter (72 chars max). - You need to add the bug URL at the last line of the commit message. Also, maybe it was the last use of gedit_utils_get_current_viewport(). In that case, after explaining that it is no longer useful, you can deprecate the function (I think it's a public function that can be used by plugins, so the function cannot be removed directly).
With Ubuntu 16.04 and XFCEs compositor activated, this bug is still present in Gedit 3.18.3. With Gnome Shell 3.18 this bug occurs too.
I assume the problem is that this viewport code is wrong, but the bigger problem is that as far as I can tell, viewports haven't existed since 2003[1][2] so this probably hasn't been tested in over a decade. I'll see if I can find time to clean up this patch sometime. [1]: http://www.circuitousroot.com/artifice/programming/useful/fvwm/viewports/index.html [2]: http://www.astro.ucla.edu/~mperrin/OLD/gnomeviewports.html
Maybe i created a proper fix. gdk_window_get_position seems to return a position that includes shadows drawn by a compositor. Is this what is expected to be returned? --- gedit-3.18.3/gedit/gedit-app.c 2016-09-20 01:46:09.000000000 +0200 +++ gedit-app.c 2016-09-20 01:50:00.665508710 +0200 @@ -349,9 +349,7 @@ /* Check for viewport match */ gdkwindow = gtk_widget_get_window (GTK_WIDGET (window)); - gdk_window_get_position (gdkwindow, &x, &y); - width = gdk_window_get_width (gdkwindow); - height = gdk_window_get_height (gdkwindow); + gdk_window_get_geometry (gdkwindow, &x, &y, &width, &height); gedit_utils_get_current_viewport (screen, &vp_x, &vp_y); x += vp_x; y += vp_y;
(In reply to bart from comment #15) > Maybe i created a proper fix. gdk_window_get_position seems to return a > position that includes shadows drawn by a compositor. Is this what is > expected to be returned? Wow thanks. Olivier, what do you think of this patch?
That patch i created is probably wrong. So here is another try. I have not found any function that would give me the shadow outsets. As a workaround the window center is used, since shadows on all systems i used seemed symmetrical to me. Also the largest part of a window should inside the viewport if the window center is. --- gedit-app.c 2016-09-20 12:06:27.000000000 +0200 +++ gedit-3.18.3/gedit/gedit-app.c 2016-09-20 12:11:09.196007270 +0200 @@ -324,6 +324,7 @@ gint sc_width, sc_height; gint x, y, width, height; gint vp_x, vp_y; + gint window_center_x, window_center_y; /* Check for screen and display match */ display = gdk_screen_get_display (screen); @@ -353,16 +354,16 @@ width = gdk_window_get_width (gdkwindow); height = gdk_window_get_height (gdkwindow); gedit_utils_get_current_viewport (screen, &vp_x, &vp_y); - x += vp_x; - y += vp_y; + window_center_x = x + vp_x + width * .5; + window_center_y = y + vp_y + height * .5; sc_width = gdk_screen_get_width (screen); sc_height = gdk_screen_get_height (screen); - - return x + width * .25 >= viewport_x && - x + width * .75 <= viewport_x + sc_width && - y >= viewport_y && - y + height <= viewport_y + sc_height; + /* use window center so any symmetrical shadow additions can be ignored*/ + return window_center_x >= viewport_x && + window_center_x <= viewport_x + sc_width && + window_center_y >= viewport_y && + window_center_y <= viewport_y + sc_height; } static GeditWindow *
(In reply to bart from comment #17) > I have not > found any function that would give me the shadow outsets. As a workaround > the window center is used, since shadows on all systems i used seemed > symmetrical to me. Also the largest part of a window should inside the > viewport if the window center is. You might find https://wiki.gnome.org/HowDoI/SaveWindowState helpful (thanks to Kamil Páral, see https://bugzilla.gnome.org/show_bug.cgi?id=771112 for details).
(In reply to Christian Stadelmann from comment #18) > You might find https://wiki.gnome.org/HowDoI/SaveWindowState helpful (thanks > to Kamil Páral, see https://bugzilla.gnome.org/show_bug.cgi?id=771112 for > details). Thanks. Nevertheless it got me no further toward a simple solution, that ignores "client side shadows" for x and y calculation. That is actually the main problem. Toward the edges of the screen/viewport y gets out of range. For me it is y == -31 and x == -62 in the top left corner.
I spent a lot of time wondering "why the heck does it keep opening new windows even within the same workspace?" tonight, until I realized that if the Gedit window is tiled (splitscreen/half-screen, as comment #7 pointed out) Gedit will open windows each time. Wondering if that particular trigger-case of the bug needs to be a separate bug report or if it's already being addressed by the patches here? Anyhow, even if the bugs with the current logic were fixed, I would really love to see a user preference to force documents to open in tabs at all time (bug #656337). Personally, I don't *ever* want gedit to open a new window by itself. That's how I end up never finding my stuff across the 5-6 gedit windows that get created throughout the workday.
(In reply to bart from comment #19) > Thanks. Nevertheless it got me no further toward a simple solution, that > ignores "client side shadows" for x and y calculation. From a user perspective, it seems to me personally like you're trying to fix the wrong problem. IMO, the "Only re-use a window if it's fully on this monitor" concept is wrong. It seems to me that the "open a new window" is for the case where there isn't a window on the current screen. A 1000x1000 px window that e.g. has /one pixel/ in its corner off-screen does /not/ qualify as not having a window on the current screen. Therefore I would suggest that the concept should be "Re-use a window if it is mostly on this monitor" (mostly = majority of pixels it covers) or even "Re-use a window if its center point is on this monitor". For example, I might intentionally temporarily move a window partially off screen to make more room for another window, such as temporarily moving gedit a bit off the left to have it only show the text editor portion and not the sidebar. The bulk of the window is still on screen and opening something in a new tab in that window is quite proper in that case IMO.
(In reply to Jean-François Fortin Tam from comment #20) > I spent a lot of time wondering "why the heck does it keep opening new > windows even within the same workspace?" tonight, until I realized that if > the Gedit window is tiled (splitscreen/half-screen, as comment #7 pointed > out) Gedit will open windows each time. Wondering if that particular > trigger-case of the bug needs to be a separate bug report or if it's already > being addressed by the patches here? It's the same bug, so it should already be addressed by my patch (#17).
(In reply to Matthew Gabeler-Lee from comment #21) > For example, I might intentionally temporarily move a window partially off > screen to make more room for another window, such as temporarily moving > gedit a bit off the left to have it only show the text editor portion and > not the sidebar. The bulk of the window is still on screen and opening > something in a new tab in that window is quite proper in that case IMO. My patch from comment #17 should just do that. Assuming symmetric client side shadows, only 1/4 of a window is required to be on screen for tabs to be opened in it.
Bart, I took the sources of version 3.22.0+4+g2c70ccb86-1 of the Archlinux package for gedit (which are commit 2c70ccb86ff7d20de5eb87e988f10d891178442b from git.gnome.org/browse/gedit), applied your patch from comment 17 successfully: patching file gedit/gedit-app.c Hunk #1 succeeded at 316 (offset -8 lines). Hunk #2 succeeded at 346 (offset -8 lines). …, recompiled, and installed the resulting package. But I don’t notice any behavior change. I can still observe the bug: when a gedit window is "tiled" / "half-maximized" (with Super + left arrow or Super + right arrow), running "/usr/bin/gedit some_file.txt" opens a new window. When the window is manually resized to have the same width but slightly less height, the same command opens a new tab in the existing window instead. This is how the package is built: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gedit&id=5894b376365d35ea2722875d12286b9146f21e2b Could you give an example of action that your patch should make gedit react to diffrerently?
(In reply to Simon Sapin from comment #24) > Could you give an example of action that your patch should make gedit react > to diffrerently? My system: Ubuntu 16.04.2 LTS, xfce 4.12 gedit 3.18.3 Close all other gedit windows. Open some document with your patched gedit. Open another document with your patched gedit. The gedit window should now contain two tabs. This also worked for a tiled gedit window. If I still had some other gedit instance running (e.g. an unpatched /usr/bin/gedit), no tabs would be created, tiled or not.
(In reply to Simon Sapin from comment #24) > Could you give an example of action that your patch should make gedit react > to diffrerently? If you're using Wayland -- and if you're using Arch then you are unless you've explicitly selected the X session when logging in -- then you're probably hitting the super-annoying bug #766284.
Ah! I can’t reproduce the issue now. Maybe I left one gedit window earlier, so I was still running the unpatched executable… So please ignore my message above. Your patch is working well for me. Thank you!
I've been bitten by this bug as well and it's a large blocker for my workflow as I generally use gedit in half the screen and the terminal in the other half and use the terminal to open files as needed. Couldn't this patch be merged?
I’ve been compiling gedit myself in order to apply this patch and running patched gedit for over a year now, and haven’t encountered this bug again or another issue that might have been caused by the patch. So, +1 for merging.
(In reply to Simon Sapin from comment #29) > I’ve been compiling gedit myself in order to apply this patch and running > patched gedit for over a year now, and haven’t encountered this bug again or > another issue that might have been caused by the patch. > > So, +1 for merging. That sounds like a pretty strong endorsement to me... Jeremy, since you're the closest gedit has to a maintainer nowadays, it's probably safe to push this, right?
Michael, I'm not the gedit maintainer. If you like the patch, feel free to push.
I've ran the patch for months now with correct results. Could someone please push it to the repo?
I tried to turn the patch from comment 17 into a merge request on https://gitlab.gnome.org/GNOME/gedit, but the patch doesn’t apply anymore. Commit https://gitlab.gnome.org/GNOME/gedit/commit/801848243ff89fde2171faa1ffc7c7e9fe79a8ec made non-trivial changes to this function, with a commit message that says "This code impact the tab vs new window opening policy". Anyone want to try and see if this bug still exists in version 3.31.2 or more recent?
From this part of the commit comment: Under X11, the same policy on x coordinates (in the viewport if 25% of the window is in it) is used for the Y coordinates. It would seem the problem should be fixed. That's nice. Thank you Sébastien Lafargue!
you're welcome
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.