GNOME Bugzilla – Bug 339461
gtk_paned_set_position() after gtk_window_maximize().
Last modified: 2008-09-10 12:47:07 UTC
Please describe the problem: First, I do: gtk_window_maximize(GTK_WINDOW(window)); Then: gtk_paned_set_position(GTK_PANED(hpaned), pos); I will find the position is not right, only after i un-maximize the window, the position become the "pos" that I set. I think gtk_paned_set_position(GTK_PANED(hpaned), pos); should set the position to "pos" even when the window is maximizd. My code like this: When running, save whether the window is maximized and the hpaned position to configure file, and read these values after start up. Then do those codes: bool maximized=conf->get_bool("/apps/stardict/preferences/main_window/maximized"); if (maximized) gtk_window_maximize(GTK_WINDOW(window)); int pos=conf->get_int("/apps/stardict/preferences/main_window/hpaned_pos"); gtk_paned_set_position(GTK_PANED(hpaned), pos); Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
- Can you create a small standalone test case? - Does it depend on what window manager you are using? What window manager are you seeing this with? (Or is this on Windows?)
Here is the test codes: #include <gtk/gtk.h> gboolean on_delete_event(GtkWidget * window, GdkEvent *event , gpointer data) { gtk_main_quit(); return FALSE; } int main(int argc,char **argv) { gtk_set_locale(); gtk_init(&argc, &argv); GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_default_size (GTK_WINDOW(window), 200, 200); gtk_window_set_position (GTK_WINDOW (window), GTK_WIN_POS_CENTER); g_signal_connect (G_OBJECT (window), "delete_event", G_CALLBACK (on_delete_event), NULL); gtk_window_maximize(GTK_WINDOW(window)); GtkWidget *hpaned = gtk_hpaned_new(); gtk_container_add(GTK_CONTAINER(window), hpaned); GtkWidget *label; label = gtk_label_new("Label1"); gtk_paned_pack1(GTK_PANED(hpaned), label, TRUE, TRUE); label = gtk_label_new("Label2"); gtk_paned_pack2(GTK_PANED(hpaned), label, TRUE, FALSE); gtk_paned_set_position(GTK_PANED(hpaned), 100); gtk_widget_show_all(window); gtk_main(); return 0; } You will see the hpand's position is about a half of the window, but not the fixed 100. when maximized. I use Fodora core 5,the window manager is matacity. In Windows, this happen too.
I find the position of paned will be wrong too when the window is not show at the first, it is set with the default minimal size, when it is show, the positon will become bigger as the window size is bigger. I think we need to provide a new api: gtk_paned_set_proportion(), as the position will change when the window size change, only proportion will not change. What's your idea?
Created attachment 105022 [details] [review] Introduce "ratio" property The paned widget will only follow your request to set a new position if it is large enough to actually use it, so the problem in the test case is that you are trying to set a value which does not currently make sense. This patch documents explicitly that the position must not exceed the actually available space. Furthermore a property "ratio" and according accessors are introduced to allow a relative divider position based on the widget's size, such as: gtk_paned_set_ratio (GTK_PANED (my_paned), 0.3); In this case, the widget will adjust the position of the divider, i.e. child1_size, to (close to) 30%.
Created attachment 105054 [details] [review] Introduce "ratio" and "ratio_set" Updated patch, now "ratio" is actually restricted to values from 0.0 to 1.0 and "ratio_set" indicates whether the ratio should be honored. This is important for generated interfaces that could for example create a slider with a range matching the allowed ranges.
The docs about 'ratio' miss the important thing ... the thing that someone couldn't just guess from the names ... what the interaction is with a) setting the position b) interactive resizing c) subsequent changes to the allocation of the widget. I don't have strong feelings about this addition one way or the other .. if it's useful to someone, it's probably a fine addition.
Fwiw, the 'interaction' questions were what derailed the earlier attempt to do this in bug 58952. I'd propose to mark this a dupe and continue the discussion there...
Created attachment 105222 [details] [review] Improved documentation I have reworded the documentation, so that it explicitly explains the relation between "position" and "ratio".
Comment on attachment 105222 [details] [review] Improved documentation thanks for the patch. >@@ -982,6 +1036,7 @@ gtk_paned_grab_broken (GtkWidget > paned->in_drag = FALSE; > paned->drag_pos = -1; > paned->position_set = TRUE; >+ paned->priv->ratio_set = FALSE; > this looks like it lacks property notification. > return TRUE; > } >@@ -992,6 +1047,7 @@ stop_drag (GtkPaned *paned) > paned->in_drag = FALSE; > paned->drag_pos = -1; > paned->position_set = TRUE; >+ paned->priv->ratio_set = FALSE; same here. > gdk_display_pointer_ungrab (gtk_widget_get_display (GTK_WIDGET (paned)), > paned->priv->grab_time); > } >+/** >+ * gtk_paned_set_ratio: >+ * @paned: a #GtkPaned widget >+ * @ratio: relative position of the divider >+ * >+ * Sets the relative position of the divider between the two panes, i.e. the >+ * relative size of the first child. Whenever the size of @paned changes, the >+ * divider is repositioned and the value of "position" is updated accordingly. >+ * >+ * The value should be between 0.0 and 1.0, inclusive. >+ * >+ * Note that any manual adjustment of "position" through code or user >+ * interaction will void the effects of "ratio". i think s/void/override/ would sound better here. >+ * >+ * Since: 2.14 >+ **/ >+void >+gtk_paned_set_ratio (GtkPaned *paned, >+ gdouble ratio) >+{ >+ g_return_if_fail (GTK_IS_PANED (paned)); >+ g_return_if_fail (ratio >= 0.0 && ratio <= 1.0); >+ >+ paned->position_set = FALSE; >+ paned->priv->ratio_set = TRUE; >+ paned->priv->ratio = ratio; >+ >+ _gtk_paned_update_divider (paned); > } > > /** >@@ -1293,6 +1412,10 @@ gtk_paned_compute_position (GtkPaned *pa > > g_return_if_fail (GTK_IS_PANED (paned)); > >+ if (paned->priv->ratio_set) >+ paned->child1_size = (gdouble)GTK_WIDGET (paned)->allocation.width >+ * paned->priv->ratio; there's no need to cast to double here. in general, casts should be avoided wherever possible (they tend to "blinden" the compiler and give up type safety). >+ > old_position = paned->child1_size; > old_min_position = paned->min_position; > old_max_position = paned->max_position; >@@ -1304,7 +1427,7 @@ gtk_paned_compute_position (GtkPaned *pa > paned->max_position = MAX (1, paned->max_position - child2_req); > paned->max_position = MAX (paned->min_position, paned->max_position); > >- if (!paned->position_set) >+ if (!paned->position_set && !paned->priv->ratio_set) > { > if (paned->child1_resize && !paned->child2_resize) > paned->child1_size = MAX (0, allocation - child2_req);
(In reply to comment #7) > Fwiw, the 'interaction' questions were what derailed the earlier attempt to do > this in bug 58952. > > I'd propose to mark this a dupe and continue the discussion there... agree, as far as the patch to set a proportional ratio is regarded. i'm not entirely sure that the original issue in this bug isn't something that needs fixing though... (In reply to comment #8) > Created an attachment (id=105222) [edit] > Improved documentation > > I have reworded the documentation, so that it explicitly explains the relation > between "position" and "ratio". Christian, can you look into moving the patch to the other bug report and possibly merging it with the existing patch there (haven't looked at that yet).
Moving this to 58952, anybody feel free to mark this as a dublicate.
*** This bug has been marked as a duplicate of 58952 ***