subject:"Re\: questions re\: aux info, size request"

Re: GtkSizeGroup breakage (was Re: questions re: aux info, size request)

2010-09-14 Thread Matthias Clasen

This is indeed quite a brain teaser.

I don't think your current approach of incrementally bumping the size
group requisition does even work correctly. How does the size group
requisition ever become smaller again ? The pre-hfw sizegroup code
always looped over all widgets to determine the size group
requisition, which seems to me the only way to make things work.

I'll attach a simple example that shows the problem with incremental
bumping. If you use the hpaned to make the long label unwrap
completely, the height request does not get reduced to a single line
height, as you can see by using the vpaned.

Matthias
#include gtk/gtk.h

int
main (int argc, char *argv[])
{
  GtkWidget *window;
  GtkWidget *hbox;
  GtkWidget *vbox1;
  GtkWidget *vbox2;
  GtkWidget *c11, *c12, *c21, *c22;
  GtkSizeGroup *sg;
  GtkWidget *hpaned, *vpaned;

  gtk_init (argc, argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  gtk_window_set_default_size (GTK_WINDOW (window), 600, 200);

  hpaned = gtk_hpaned_new ();
  vpaned = gtk_vpaned_new ();

  hbox = gtk_hbox_new (FALSE, 5);
  vbox1 = gtk_vbox_new (FALSE, 5);
  vbox2 = gtk_vbox_new (FALSE, 5);

  gtk_container_add (GTK_CONTAINER (window), hpaned);
  gtk_paned_add1 (GTK_PANED (hpaned), vpaned);
  gtk_paned_add2 (GTK_PANED (hpaned), gtk_label_new ());
  gtk_paned_add1 (GTK_PANED (vpaned), hbox);
  gtk_paned_add2 (GTK_PANED (vpaned), gtk_label_new ());
  gtk_container_add (GTK_CONTAINER (hbox), vbox1);
  gtk_container_add (GTK_CONTAINER (hbox), vbox2);

  c11 = gtk_label_new (Some text that might wrap);
  c12 = gtk_label_new (Ellipsizing text that doesn't wrap);
  c21 = gtk_label_new (Short text);
  c22 = gtk_label_new (Some longer text that might also wrap over several lines);

  gtk_label_set_line_wrap (GTK_LABEL (c11), TRUE);
  gtk_label_set_ellipsize (GTK_LABEL (c12), PANGO_ELLIPSIZE_END);
  gtk_label_set_ellipsize (GTK_LABEL (c21), PANGO_ELLIPSIZE_END);
  gtk_label_set_line_wrap (GTK_LABEL (c22), TRUE);

  gtk_container_add (GTK_CONTAINER (vbox1), c11);
  gtk_container_add (GTK_CONTAINER (vbox1), c12);
  gtk_container_add (GTK_CONTAINER (vbox2), c21);
  gtk_container_add (GTK_CONTAINER (vbox2), c22);

  sg = gtk_size_group_new (GTK_SIZE_GROUP_BOTH);
  gtk_size_group_add_widget (sg, c11);
  gtk_size_group_add_widget (sg, c22);

  gtk_widget_show_all (window);

  gtk_main ();

  return 0;
}

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-13 Thread Havoc Pennington

Hi,

On Mon, Sep 13, 2010 at 7:06 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 Heh, do you mean GtkWindow widgets or GtkWidgets that have their own
 GdkWindow ?

Widgets that have their own GdkWindow

i.e. I was proposing that when adjusting a size request,

if (gtk_widget_get_window(widget))
{
  if (*minimum_size  1) *minimum_size = 1
}

 I think essentially to allow 0x0 allocations we either need to
 allow GdkWindows to be created at a 0x0 size (currently they
 also force = 1x1 internally)... or we need to add some special casing
 code to GtkWidget's to handle their GdkWindows with care at
 allocation time (naturally they all just call gdk_window_move_resize()
 unconditionally).

If you force the 1x1 request then in theory you would not ever get a
0x0 allocation, right? But to be sure could also force 1x1 allocation
(which is already done), but change that requirement to only apply if
gtk_widget_get_window() != NULL

I was proposing this approach - window widgets must be 1x1 - because
the alternative is to unmap when receiving a 0x0 allocation.
(HippoCanvas does the unmap thing, in fact 0x0 allocation and unmapped
are the same state in HippoCanvas, iirc.) I think the unmap-on-0x0
will be complicated to apply to GTK and maybe not that useful, since
the goal is to get rid of window widgets, keeping only the ones that
truly conceptually have a GdkWindow - toplevels and embeds - and
requiring toplevels to be 1x1 is actually logical.

Anyway the basic idea is to avoid changing anything too much, just
move the arbitrary 1x1 requirement only to those widgets that really
need it (those that have a GdkWindow)

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-12 Thread Havoc Pennington

Hi,

On Sun, Sep 12, 2010 at 1:33 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 Ok I see, so we end up with:
  - set_size_request() Can be used to increase the minimum request

I was thinking this should stay backward compatible and allow lowering
it, fwiw. Though I can't actually come up with a use case, I'm just
being paranoid.

btw - have you looked into allowing 0x0 allocations at all? (at 0x0,
draw() would not be called, I think, so draw() implementations would
not have to handle 0x0; also, 0x0 would not really work on window
widgets, but this could be addressed by forcing window widgets to have
at least a 1x1 minimum size. i.e. replace 1x1 min allocation with a
1x1 min request for window widgets only)

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-11 Thread Matthias Clasen

On Sat, Sep 11, 2010 at 7:58 PM, Havoc Pennington h...@pobox.com wrote:


 Anyhow: it would be a shame to ship the ignore set size request
 smaller than min size by accident. Should I open a bug? Or should I
 change (and document) set_size_request to increase only?

Sounds good to me.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-11 Thread Tristan Van Berkom

On Sat, 2010-09-11 at 21:05 -0400, Matthias Clasen wrote:
 On Sat, Sep 11, 2010 at 7:58 PM, Havoc Pennington h...@pobox.com wrote:
 
 
  Anyhow: it would be a shame to ship the ignore set size request
  smaller than min size by accident. Should I open a bug? Or should I
  change (and document) set_size_request to increase only?
 
 Sounds good to me.

While on this topic, there's this XXX comment I left dangling
in gtksizegroup.c:
   http://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n677

I was thinking maybe that for all the widgets in a group to be
effectively the same size, maybe we should be basing the minimum
base requests from the natural requests of all widgets in a group.

Currently a size group bumps up the minimum required size to
match the minimum size of all widgets in the group, the problem
with this is maybe some widgets will be allocated a bigger size
(while requiring the same minimum size); if they were to require
the natural size of the group as a minimum, they would more
effectively be allocated the same size (the problem with that
approach is that grouped widgets might be allocated a dramatically
large size unintentionally).

But if set_size_request() were to limit the natural size; combining
it with sizegroups that demand/require the natural size as a minimum
might work nicely.

Thoughts ?

Cheers,
-Tristan



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-11 Thread Havoc Pennington

Hi,

On Sun, Sep 12, 2010 at 12:45 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 While on this topic, there's this XXX comment I left dangling
 in gtksizegroup.c:
   http://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n677

 I was thinking maybe that for all the widgets in a group to be
 effectively the same size, maybe we should be basing the minimum
 base requests from the natural requests of all widgets in a group.

I would expect that GtkSizeGroup caused all widgets in the group to
request a min size of the largest min size in the group, and a natural
size of the largest natural size in the group. Then it Just Works,
right? Is there a reason that only one of min or natural can be picked
for size group?

 But if set_size_request() were to limit the natural size; combining
 it with sizegroups that demand/require the natural size as a minimum
 might work nicely.

To be clear, I was proposing a set_natural_size() or something (i.e. I
think making set_size_request set natural would be too incompatible)

It might be clearer to rename set_size_request to set_minimum_size()
but that function is maybe too heavily used to rename... at least
without keeping the old name also.

btw along these lines, I can't remember if I filed the attached patch.
Natural size much less useful without it.

Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington h...@pobox.com
Date: Mon, 6 Sep 2010 11:18:35 -0400
Subject: [PATCH] Make GtkWindow default to natural size not minimum size

Otherwise your ellipsized labels all start out ellipsized, unless
you manually gtk_window_set_default_size().

This probably makes it important to clamp the window's default
size to the size of the monitor's work area.
---
 gtk/gtkwindow.c |4 ++--
 tests/testgtk.c |1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gtk/gtkwindow.c b/gtk/gtkwindow.c
index 5f75dae..b50a9ab 100644
--- a/gtk/gtkwindow.c
+++ b/gtk/gtkwindow.c
@@ -5725,9 +5725,9 @@ gtk_window_compute_configure_request_size (GtkWindow *window,
   
   if (window-need_default_size)
 {
-  gtk_widget_get_child_requisition (widget, requisition);
+  gtk_size_request_get_size (GTK_SIZE_REQUEST (widget), NULL, requisition);
 
-  /* Default to requisition */
+  /* Default to natural requisition */
   *width = requisition.width;
   *height = requisition.height;
 
diff --git a/tests/testgtk.c b/tests/testgtk.c
index cddb7df..8ea1117 100644
--- a/tests/testgtk.c
+++ b/tests/testgtk.c
@@ -8431,6 +8431,7 @@ create_window_sizing (GtkWidget *widget)
 			 gtk_widget_get_screen (widget));
   label = gtk_label_new (NULL);
   gtk_label_set_markup (GTK_LABEL (label), span foreground=\purple\bigWindow being resized/big/span\nBlah blah blah blah\nblah blah blah\nblah blah blah blah blah);
+  gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END);
   gtk_container_add (GTK_CONTAINER (target_window), label);
   gtk_widget_show (label);
   
-- 
1.7.0.4

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-11 Thread Tristan Van Berkom

On Sun, 2010-09-12 at 01:01 -0400, Havoc Pennington wrote:
 Hi,
 
 On Sun, Sep 12, 2010 at 12:45 AM, Tristan Van Berkom
 trista...@openismus.com wrote:
  While on this topic, there's this XXX comment I left dangling
  in gtksizegroup.c:
http://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n677
 
  I was thinking maybe that for all the widgets in a group to be
  effectively the same size, maybe we should be basing the minimum
  base requests from the natural requests of all widgets in a group.
 
 I would expect that GtkSizeGroup caused all widgets in the group to
 request a min size of the largest min size in the group, and a natural
 size of the largest natural size in the group. Then it Just Works,
 right? Is there a reason that only one of min or natural can be picked
 for size group?

Hmmm your right this behaviour is probably a bit buggy (at the time
my target was more to make widgets actually all receive the same
size, it seemed less important to synchronize every natural size in the
group).

Ofcourse the way sizegroups are mishmashed into the request api it will
be a bit tricky to fix but I'll consider the current implementation
buggy and go ahead and perfect that.

  But if set_size_request() were to limit the natural size; combining
  it with sizegroups that demand/require the natural size as a minimum
  might work nicely.
 
 To be clear, I was proposing a set_natural_size() or something (i.e. I
 think making set_size_request set natural would be too incompatible)
 
 It might be clearer to rename set_size_request to set_minimum_size()
 but that function is maybe too heavily used to rename... at least
 without keeping the old name also.

Ok I see, so we end up with:
  - set_size_request() Can be used to increase the minimum request
  - set_natural_size() Could be added to explicitly set
the natural size to anything greater than the minimum size
(greater or less than the widget's original natural request)

Sounds good :)

Cheers,
-Tristan


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-07 Thread Tristan Van Berkom

On Tue, 2010-09-07 at 14:44 +0900, Tristan Van Berkom wrote:
On Sat, 2010-09-04 at 21:37 -0400, Havoc Pennington wrote:
Hi,

several questions looking at this code,

Sorry it took me a while to answer this mail.

1. I may be nuts but I really thought set_size_request() could reduce
a size request below the widget's normal request, back in the day.
However, won't this code allow set_size_request to *increase* min size
only?

http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n311

i.e. cached_size-minimum_size = MAX (cached_size-minimum_size,
group_size);

and cached_size-minimum_size is straight from the widget itself.

Am I reading something wrong or was this an intentional change or a bug?

Not intentional... my mistake/bug (I was not aware you could reduce
the base size request using set_size_request()).

However now that I give this one some more thought, I wonder if this
has been somehow broken for a while now.

For instance... when you put some widgets into a GtkSizeGroup and
explicitly set one of the widgets minimum size to a smaller value
than the others - will it's minimum size not still grow to match
the largest minimum size in the group ? (should it have worked the
other way around and shrank all other widgets in the group for
an explicit small request ?).

What is the behaviour that we want here ?

Personally I'd like to think that:
- You cannot allocate any widget a size smaller than its minimum
request without expecting breakage
(see never ending thread on
https://bugzilla.gnome.org/show_bug.cgi?id=617442).

- Setting an explicit minimum request with
gtk_widget_set_size_request() guarantees that it will never be
allocated a smaller size than the one the user specified
(currently though; the docs mention you can adjust the size
request to be smaller without any guarantee that it will
actually be allocated such a small size).

What is the use-case for forcing a widget to request something smaller
than it's content ?

Cheers,
-Tristan

2. The use of AuxInfo in gtkscrolledwindow.c is weird weird weird

http://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n1873

scrolledwindow uses the forced size request of the child (done with
set_size_request) but does not use the actual size request of the
child? what?

This appears to be ancient 12-year-old weirdness, see commit 0d15bc66,
http://git.gnome.org/browse/gtk+/diff/gtk/gtkscrolledwindow.c?id=0d15bc6687e9a9718273a37b3d880f6526fa91ce

In an era of min size, I think we should declare this silly and just
use the min size of the child. The commit introducing this seems to be
in a world where set_usize() (the old set_size_request name) meant
user-explicitly-set size instead of its current meaning of minimum
size request

I agree its weird weird weird, the scrolled window hfw changes were
delicately effected in the hope of not breaking anything (granted,
completely reconsidering the scrolled window code would have been
better).

That being said the next thing on my list is to seriously
reconsider how scrolled windows should work with height-for-width
(as my current patches for height-for-width treeviews has some
evil hacks in place to avoid infinite recursions when placed
in scrolled windows).

For a taste of what's in store for scrolled windows you can
read through Owen's prior work here:
https://bugzilla.gnome.org/show_bug.cgi?id=611740

3. The use of AuxInfo in gtklabel.c I don't really understand, plus seems
buggy

Basically, in a w-for-h h-for-w world, why does label need to look at
this itself and include it in its size request up front? I can imagine
the motivation back in the days when wrapped labels had to be hacky,
but now they should not have to be hacky. What is the story on this?

If it is used, the buggy is that it seems to ignore the GtkMisc
padding etc. properties and assume that set_size_request only sets the
size of the text itself, rather than the entire widget.

Right... again as with scrolled window I tried to make the least changes
as possible (originally I was hypothetically targeting GTK+ 2.x series).

Some good refactoring and even optimization is also possible in
gtklabel.c, the problem here is that everything is done through
gtk_label_ensure_layout() which is called way too often, recreating
the label's layout for the sake of any request.

That being said... we can probably safely just remove the bit
that consults aux_info from inside gtk_label_ensure_layout(), this
must be there historically so that gtk_label_ensure_layout() creates
a layout at the right height when doing a size-request for a
word-wrapping label.

Cheers,
-Tristan

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-07 Thread Havoc Pennington

Hi,

On Tue, Sep 7, 2010 at 3:49 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 What is the use-case for forcing a widget to request something smaller
 than it's content ?


I think the use-cases are mostly caused by the old limited layout
system. For example, to get a label to ellipsize, you used to have to
set its size request to something small and then pack it with
expand=true.

I'd say the semantics of set_size_request should be pretend the
widget's size request vfuncs returned what set_size_request set so
size groups and widget padding would still potentially grow that size
request.

It is just a back compat API though really; I'm not sure what it's
really good for. The only increase what vfuncs return behavior does
seem more useful in at least one case, where you just want to be sure
the min size is at least something-or-other, but are willing to use a
larger value if the true min size is larger.

I guess some searching through apps to see how they use it might be
instructive. (Is there an easy way to search through code for lots of
gtk apps?)

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: questions re: aux info, size request

2010-09-06 Thread Tristan Van Berkom

On Sat, 2010-09-04 at 21:37 -0400, Havoc Pennington wrote:
Hi,