GNOME Bugzilla – Bug 168105
the right edge tab does not appear when switching tab
Last modified: 2011-02-04 16:20:15 UTC
Please describe the problem: The right edge tab does not appear when switching tab. This bug happens only if the window size is specific width and each tab label is fixed specific width. Steps to reproduce: 1. run test app. 2. switch to "Label09" tab using mouse button click Then, all the visible tabs move left, but "Label10" tab does not appear! 3. switch to "Label08" tab using mouse button click Then, "Label10" tab appears. Actual results: Expected results: Does this happen every time? Other information: test app code int main (int argc, char *argv[]) { GtkWidget *window, *note; gint i; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); note = gtk_notebook_new(); gtk_notebook_set_show_tabs(GTK_NOTEBOOK(note), TRUE); gtk_notebook_set_scrollable(GTK_NOTEBOOK(note), TRUE); gtk_container_add(GTK_CONTAINER(window), note); for (i = 0; i < 15; i++) { GtkWidget *child, *label; gchar *label_text; child = gtk_text_view_new(); label_text = g_strdup_printf("Label%02d", i); label = gtk_label_new(label_text); g_free(label_text); gtk_notebook_append_page(GTK_NOTEBOOK(note), child, label); gtk_widget_set_size_request(label, 80, -1); gtk_widget_show(child); } gtk_window_set_default_size(GTK_WINDOW(window), 926, 700); gtk_widget_show_all(window); gtk_main(); return 0; }
I can confirm this using GTK+ 2.6.2 on Ubuntu PPC. I've been told this can't be reproduced on the same version of GTK+ but with x86.
I am using GTK+-2.6.2 on x86 machine. There's this bug. The condition of reproducing this bug is very severe, so the window size or tab label size might not be suited your x86 environment.
Testcase still 100% reproducible here, with gtk+ 2.8.3 (on x86).
Created attachment 65470 [details] [review] fixes the bug. this patch is for CVS head.
Created attachment 65471 [details] [review] fixes the bug. This patch is for 2.8.x.
I confirmed the patch fixes this bug on GTK+-2.8.17. Nice work!
The patch causes different misbehaviour. I'll attach a screenshot of how the test app appears for me after clicking first on tab no. 9 and then on the right arrow. Note how the tabs do not scroll, instead the 10th tab is drawn over the arrow.
Created attachment 65784 [details] problem
Created attachment 65800 [details] [review] revised patch for 2.8.x
Created attachment 65805 [details] [review] revised patch for CVS head
2006-05-19 Matthias Clasen <mclasen@redhat.com> * gtk/gtknotebook.c (gtk_notebook_pages_allocate): Fix a boundary case in scrolling where a tab was not shown. (#168105, Hiroyuki Ikezoe, patch by Kouhei Sutou)
May I suggest the following fix?: @@ -4851,9 +4894,7 @@ &(notebook->first_tab), remaining_space, STEP_PREV); - page = notebook->focus_tab->data; - if (*remaining_space <= 0 && - !gtk_widget_get_child_visible(page->tab_label)) + if (*remaining_space < 0) { notebook->first_tab = gtk_notebook_search_page (notebook, notebook->first_tab, With the last commit I got in epiphany what Matthias described in comment #7, and I also got a "complain" of this code crashing galeon (due to notebook->focus_tab being NULL) The modification I propose prevents the crash from happenning, fixes what Matthias described, and I think that fixes the issue commented in this bug report (I could not reproduce it with the attached test, I got it instead by playing with tests/testnotebookdnd) Please, could anyone who could reproduce this before test my proposed fix?
The fix is the same of my first patch. (http://bugzilla.gnome.org/attachment.cgi?id=65470) The problem what Matthias described in comment #7 is for my first patch, not my revised path. (http://bugzilla.gnome.org/attachment.cgi?id=65805) I didn't think about notebook->focus_tab is NULL or not. Do you hava a test case for the crash bug that is caused by notebook->focus_tab is NULL?
I could reproduce this bug with the following code: #include <gtk/gtk.h> int main (int argc, char *argv[]) { GtkWidget *window, *note; gint i; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); note = gtk_notebook_new(); gtk_notebook_set_show_tabs(GTK_NOTEBOOK(note), TRUE); gtk_notebook_set_scrollable(GTK_NOTEBOOK(note), TRUE); gtk_container_add(GTK_CONTAINER(window), note); for (i = 0; i < 11; i++) { GtkWidget *child, *label; gchar *label_text; child = gtk_text_view_new(); label_text = g_strdup_printf("Label%02d", i); label = gtk_label_new(label_text); g_free(label_text); gtk_notebook_append_page(GTK_NOTEBOOK(note), child, label); gtk_widget_set_size_request(label, 80, -1); gtk_widget_show(child); gtk_notebook_set_current_page(GTK_NOTEBOOK(note), i); } gtk_window_set_default_size(GTK_WINDOW(window), 926, 700); gtk_widget_show_all(window); gtk_main(); return 0; }
Created attachment 66699 [details] [review] fixes different problem (for 2.8.x)
Oh, right... I didn't realize that it was your first suggested fix, in fact after reading more in detail Matthias' issue I've seen that it's somewhat unrelated to mine (yet they make the notebook look the same). After following Matthias' steps I can reproduce it with the "fix" My issue can be seen with gtk HEAD + epiphany HEAD, the tabs go past the right edge when the notebook has to show the arrows. Some code reading got me to the roots of the problem. the if (*remaining_space < 0) is part of the solution, that code section should not happen if remaining_space is 0 (which is what triggers the bug). Besides that, there's a problem in what "first tab" and "last tab" mean: - The first tab is the first visible tab - The last tab is the first invisible tab past the last visible tab This produces Matthias' issue while calculating the first tab in gtk_notebook_calc_tabs() when focus_tab is the last visible tab and there's 0 remaining space. IMO The proper fix would require "first tab" and "last tab" to adopt the same semantic to make gtk_notebook_calc_tabs() work equally fine in both directions. Another solution (implies less code touching) would be hacking that function to know what to do in that border case. I'm going to attach a patch that implements the second one. The committed patch seems somewhat wrong to me, tabs visibility is calculated later based on which/how many tabs can it show, and not backwards BTW, what does the attacment in comment #15 do? is it related to this bug? Gosh, sorry for the long comment :)
Created attachment 66737 [details] [review] patch
> BTW, what does the attacment in comment #15 do? is it related to this bug? Did you try my patch, didn't you? You can apply my patch into HEAD and will find my patch fixes your problem. Please try.
2006-06-04 Matthias Clasen <mclasen@redhat.com> * gtk/gtknotebook.c (gtk_notebook_calculate_shown_tabs): (gtk_notebook_calc_tabs): Fix borderline cases in tab visibility calculation. (#168105, Carlos Garnacho Parro)
*** Bug 343618 has been marked as a duplicate of this bug. ***
*** Bug 345535 has been marked as a duplicate of this bug. ***