GNOME Bugzilla – Bug 123408
GtkNotebook should be able to show tab_labels but not tab_border
Last modified: 2018-04-15 00:22:30 UTC
According to the documentation: * This [set_show_border] only has a visual effect when the tabs are not shown. The feature is necessary to solve Fitt's law problems with tabbed apps. See 112291, the same problem is reproducable in gnome-terminal and gedit.
Not sure how this would interact with theming. I guess you'd just call gtk_paint_box_gap and gtk_draw_extension with a reduced area and let things get chopped. Would likely look horrendously ugly. Perhaps the right solution is instead to make sure that the active area for clicking for notebook tabs extends all the way to all three edges of the tab area without regard to how things are drawn?
What about scrollbars inside the notebook panes? The effect is most apparent when trying to use these in a maximised app (like epiphany). The notebook border does not allow you to whack the cursor to the edge of screen in order to operate the scrollbar.
Someone needs to figure out exactly *which* borders are being objected to. It's clearly easier to get things to look OK if you only want to whack the borders off the 3 sides where there aren't noteobok tabs.
I filed the original bug (112291) with ephy, and my objection was to the borders on the left, right and bottom of the frame (although mainly just the right, where the scrollbar was). I've never had issues with the border on the tabbed edge, because the tabs get in the way of any sort of behaviour I described above anyway.
Re comment 3: When we maximise an epiphany window, and hide all toolbars etc., only the notebook and its child will be shown. Then we want (Fitt's law): - switch notebook page when the mouse is at the screen border with the tab labels (usually top border) - scroll the notebook's child's scrollbars either by dragging or using the scroll wheel, when the mouse is at that border (usually the right border (left when RTL), less commonly the bottom border) I've found out that I can achieve this by setting the notebook's style's xthickness = ythickness = 0. The only drawback is that this also makes the separation line between the tab labels and the notebook page vanish. So maybe all that's needed is a mode to avoid adding any x/y-thickness to the notebook and the notebook page, but still draw that separation line ?
*** Bug 166158 has been marked as a duplicate of this bug. ***
I'm for deleting the one pixel insensitive line that appears around the notebook contents when there's more than one tab (it is inconvenient with maximised windows). It can be replaced by a line that is part of the tab border, which is already how themes draw it.
*** Bug 300149 has been marked as a duplicate of this bug. ***
Created attachment 75853 [details] [review] patch Hi!, This patch avoids the use of xthickness/ythickness in the borders where tabs are not drawn. I've been thinking in other ways to do this, but IMHO this is the best solution: contained widgets with border_width=0 are very possibly interested in this feature, and the ones that don't care will have already a border_width set, so won't care about a couple of pixels less. Besides that, leaving this in hands of app developers or themes will only make things more inconsistent...
Does this bug cover hiding borders, but showing tabs, like in firefox? (Firefox has no notebook border around the content)
This bug hits Epiphany as well. Is there some chance to get this fixed soonish?
Ping, can a GTK+ maintainer review the patch?
hmm, doesn't the patch end up breaking non-zero thickness in notebooks ? And it does not fix the orignal complaint in this bug, which was about clicking at the outer edge of the tab row. So I think what we want is a) do what Owen proposed, and make tabs react to clicks all the way to the outer border and b) maybe add a separate style parameter for controlling separation between the tab row and the content; then themes can set thickness to zero and still retain some separation between tabs and content.
(In reply to comment #13) > hmm, doesn't the patch end up breaking non-zero thickness in notebooks ? Yes, it does, my rationale is that apps which put something inside a notebook page with 0 separation will very probably consider non-zero thickness a "bug", or at least something very annoying. > And it does not fix the orignal complaint in this bug, which was about clicking > at the outer edge of the tab row. Maybe I'm misunderstanding, but I don't think so :), if you see the bug referenced in the report (#112291), it's about being able to click/scroll in the borders where there aren't tabs, for example, the page scrollbar in a maximized epiphany window. > > So I think what we want is > > a) do what Owen proposed, and make tabs react to clicks all the way to the > outer border > > and > > b) maybe add a separate style parameter for controlling separation between the > tab row and the content; then themes can set thickness to zero and still retain > some > separation between tabs and content. With my patch, xthickness/ythickness is only used in the tabs side to separate tabs and content. Sadly, modifying xthickness/ythickness in the notebook will also modify how tabs are drawn (it's also used when allocating tab_label sizes). Another way would be allowing show_tabs && !show_border, but I'm sure it will break visually apps that have these properties incorrectly set. (At the moment, border will always be shown when tabs are shown, regardless of its value)
Carlos, any progress here?
Will work on this again during this weekend
Hey Carlos, did you get back to this?
Created attachment 102869 [details] [review] [PATCH] Implement gtk_notebook_[gs]et_fullscreen_mode(), which makes the notebook borderless for all borders, but the one with the tabs. This way contained widgets can follow fitts' law, which is good for usually maximized/fullscreen tabbed apps (ephy, terminal, gedit, ...) --- gtk/gtknotebook.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++----- gtk/gtknotebook.h | 5 ++ 2 files changed, 131 insertions(+), 12 deletions(-)
I've been thinking about this, and it doesn't make much sense to me to have it as an style property, as it's something themes aren't interested in modifying, instead it's multitabbed apps the ones interested in letting users just whack the pointer to a border to manipulate the scrollbar in there. So, I've just added gtk_notebook_set_fullscreen_mode() which removes the border, perhaps it should just set some flag and actually turn it on only if the parent window is maximized or fullscreen? anyone has a better idea?
IMHO show_tabs && !show_border should work, too. > So, I've just added gtk_notebook_set_fullscreen_mode() which removes the > border, perhaps it should just set some flag and actually turn it on only if > the parent window is maximized or fullscreen? anyone has a better idea? It should also check if the widget is on the far right. In my opinion it should be fixed in the applications directly.
Why have a set_fullscreen_mode function, when the show_border property exists?
Created attachment 110329 [details] [review] [set_show_border] now always has a visual effect (doesn't matter whether tabs are shown or not) The attached patch removes the (unnecesary) border between the scrollbar and the screen edge, when the window is maximized. Scrolling in Epiphany now works fine, as it does in gedit. The close buttons in gedit are a bit clipped now (but they are fine in epiphany), maybe some bug in gedit code?
Any more news about this issue? It's clearly an usability regression (GNOME 2.22 doesn't have the issue) and there's no bug activity since May! (six months ago). The issue also affects to Nautilus when two or more tabs are opened.
*** Bug 577303 has been marked as a duplicate of this bug. ***
*** Bug 581535 has been marked as a duplicate of this bug. ***
*** Bug 569993 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > Any more news about this issue? It's clearly an usability regression (GNOME > 2.22 doesn't have the issue) and there's no bug activity since May! (six months > ago). > > The issue also affects to Nautilus when two or more tabs are opened. > I'm using Gnome 2.22.3 and I'm still seeing the border in gedit when the window is maximized with one or more tabs. I'd love to see the border removed from the tabs when the window is maximized, I keep missing the scroll bar all the time, drives me crazy.
Could somebody review the patch, please?
*poke* Also, for anyone who finds this bug and wants the borders to go away on their terminal, the following in ~/.gtkrc-2.0 works: style "notebook-borderless" = "default" { xthickness = 0 ythickness = 0 } widget "TerminalWindow.*.GtkNotebook" style "notebook-borderless"
Created attachment 167045 [details] Visualization of issue Hi, to help clarify what this bug is about, I've thrown together a UI mockup. Top is the current behaviour, bottom is the behaviour that this bug is requesting. This is for any application using tabs as MDI (epiphany, gedit, nautilus, gnome-terminal, ...) to reduce visual clutter (and make use of Fitt's law when maximized), any chance of a fix for Gtk+3?
*** Bug 642173 has been marked as a duplicate of this bug. ***
Normally, I don't like to "vote" for a bug, but I'd really like to see this in 3.2. Is there a style class that could be added to the context and interprited by the theming engines?
*please* get this fixed. It's incredibly annoying.
I also would like to see this fixed. I'm trying to use a GtkNotebook with a terminal (VTE) and the border just looks wrong.
Any updates on this? The border seems to be gone from gnome-terminal. Is that because of a gtk fix, or just a hack in the particular application?
Hey Thomas, this bug is 10 years old now. If the dev hasn't got it fixed yet, I wouldn't expect it to be fixed in the next decade either. This project needs a lot of cleaning up, because this is a mess. Further illustrated by the fact that this bug still has the status "NEW". If you can't manage the bugs, then assign them to someone else for christ sake.
Stephen: NEW is the standard status if nobody works on it. If you can offer unlimited manpower feel free to assign the bugs to yourself, for christ sake. Thanks. :)
I'm an open source developer also and I would honestly be ashamed if I had a bug open for a single year. Admittedly the projects I work on aren't anywhere near the popularity of gtk+, but still a 10 year long bug seems very excessive. Just my opinion, and I don't expect my opinion to count for much around here. My apologies for coming off harsh though. All GPL work is greatly appreciated. Cheers
I had a lot of trouble with this problem a while ago. If I recall this correctly, then the solution involved a few different things: * Different themes create different kinds of borders, for example on Adwaita, I was only seeing a 1px border, while on an Ubuntu Theme I was seeing a 3px grey padding (yes padding, not border). * I added the following CSS override to my application: /** * Calling gtk_notebook_set_show_border is not enough. We need to * disable the border explicitly by using CSS. */ gtk_css_provider_load_from_data (GTK_CSS_PROVIDER (provider), " .notebook {\n" " border: none;\n" "}\n", -1, NULL); Which solved the border thing for me. Additionally I made it possible to load a custom style.css, where the user could define his personal CSS. This lead to interesting styles from some users [2]. Regards Sebastian [1] https://github.com/lanoxx/tilda/commit/7060d50cec6eebe1e14b096167e14a3be7a32f94 [2] https://github.com/tsloughter/tilda/issues/7#issuecomment-12627169
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new