Re: Minimum height for minimum width - reprise
Il giorno dom, 23/06/2013 alle 17.35 +0900, Tristan Van Berkom ha scritto: [...] I have a feeling that your requirements are... falling into that pitfall, i.e. the height-for-width requesting algorithms don't fit cleanly into what we report to the X server as minimum sizes for width and height. OK, I see - sorry for taking so long to understand. I will read the bug pointed out by Matthias and comment there if I have any suggestion. Thanks, Pietro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width - reprise
Hi Tristan,
thank you for your clarification. I seem to understand there is
currently no real answer to my needs, but let me stress a couple of
points just to be sure I was clear:
Il giorno mer, 19/06/2013 alle 23.00 +0900, Tristan Van Berkom ha
scritto:
On Wed, Jun 19, 2013 at 10:13 PM, Pietro Battiston
m...@pietrobattiston.it wrote:
Il giorno mer, 19/06/2013 alle 20.03 +0900, Tristan Van Berkom ha
scritto:
On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston
m...@pietrobattiston.it wrote:
[...]
This is, to my eyes, the clearest example of height-for-width space
management... and as far as I understand, it is currently impossible.
Am I missing something?
This is possible, but I don't know any widgets which do that, that's all.
void
widget_get_preferred_height_for_width (GtkWidget *widget,
gint width,
gint *minimum,
gint *natural)
{
/* You are going to be allocated 'width' which is something greater
* than the minimum width you reported in
get_preferred_width_for_height( height = -1);
*/
/* Now you will *request* this much height */
*minimum = height;
/* Note that 'natural' must be at least as big as 'minimum' */
*natural = desired_height_for_given_width (height);
/* Now you will *request* this much height */
*minimum = *natural = height;
}
Note that you might be allocated more size than that which you requested,
but not less.
You might want your aspect ratio height to be the minimum natural
instead of 'square', depending.
Does this answer your question ?
Well, this did suggest to me that my question was maybe not well
formulated - in fact, I have a problem with the layouting algorithm, not
with the working of a widget on its own. So consider this simple
example:
1) in my widget_get_preferred_width(), I set
*minimum = 50
*natural = 200
2) in my widget_get_preferred_height_for_width(), I set
*minimum = *natural = 1/width
3) I pack_start this widget into a Gtk.VBox()
4) I add the VBox in a Gtk.Window, and show_all() it
Result: a window that's 200x200 (and the user can't shrink vertically).
Now repeat the steps above, adding, between 3 and 4:
3a) I pack_start into the VBox an additional 60x17 GtkLabel (or
GtkImage, that's irrelevant).
Result: a window that's 200x183!
So to resume: what annoys me - in both cases - is that the window is
much too tall, and the user cannot even shrink it vertically.
But what I really find inconsistent is that by adding a widget below,
the resulting window may become smaller!
Anyway, I don't have a better algorithm in mind - if you tell me that
there is nothing I'm missing and there is no obvious solution to such
problem, I'll just make things work reasonably in reasonable contexts.
It sounds like you're running into some issues with how the toplevel
decides to allocate the default size.
When I wrote height-for-width, I made sure the default size was
minimum height for minimum width, and then ensured that labels
requested a reasonably large minimum width by default (unless
the user sets width-chars explicitly to a small value).
This has been changed in GTK+ and I'm not sure what the details
are exactly now, first the trick I played to ensure labels were
reasonably wide by default was removed (resulting in some tall
dialogs with wrapping text in 3.2 or 3.4), now there is some other
logic/priority used to guess an appropriate window height (and
I think that's changed very recently, Matthias and Benjamin have
been fixing GtkWindow default sizes afaik so they would be able
to better comment on this).
However I think that what you are trying to do is a bit application
specific and not necessarily in the right place.
The layouting code is used to share space in what is allocated
in a toplevel window (and define some minimums, those minimums
should really be the minimum required to display some content).
My problem is precisely here: the minimum width I declare _is_ the
minimum required to display the content, and the same holds for the
minimum height I declare for that width. But that _doesn't_ mean that
those minimums should for any reason be considered a canonical
allocation of any sort. A better rule of thumb would be in my opinion
natural width x minimum related height. It would still be, strictly
speaking, a minimal allocation, and presumably one with a more decent
aspect ratio.
If there is no left over space in your application (i.e. no scrolled window,
no area where it is useful to put extra space and then sacrifice some height
if the window is too 'slim' to fit other content), then height-for-width is
not really for you.
My impression is that I'm not _enough_
Re: Minimum height for minimum width - reprise
On Sun, Jun 23, 2013 at 4:35 AM, Tristan Van Berkom t...@gnome.org wrote: As I've mentioned before, other people have been playing with tactics to guess a good size for the toplevel window (poke poke, jump in any time guys)... I'm not exactly aware of what the final decision was for how to guess what the default size will be. My most recent attempt at improving default size handling is in https://bugzilla.gnome.org/show_bug.cgi?id=681937#c12 . Comments appreciated. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width - reprise
Il giorno mer, 19/06/2013 alle 13.40 +0900, Tristan Van Berkom ha scritto: On Wed, Jun 19, 2013 at 1:31 AM, Pietro Battiston m...@pietrobattiston.it wrote: [...] If I'm honest about the minimum width, then the (corresponding) minimum height required is assumed to be something huge, and the result (for instance directly inside a window) is ugly. This is the nature or height for width, minimum height for minimum width will usually be tall and slim. However there are a few tactics to use which ensure that tall and slim windows don't occur. Notice the window in my case is not tall and slim, it is tall and large! Because the width is the natural one, but the minimal height corresponds to the minimal width. a.) The toplevel window should not by default present itself at minimum width, I think currently GTK+ toplevels use some trickery with natural width. I.e., the height of a window is not determined by the minimum width of a window, it's determined by the height for the width which will be *allocated* to the window (that's an important difference). Maybe I misunderstand you, but what seems to happen is precisely that the height of a window is determined by the minimum width of a window: git clone git://pietrobattiston.it/quack cd quack git checkout wrapbox_error cd plugins/tags python test_wrapbox.py [...] b.) Make sure that labels do not request a ridiculously small minimum width when they are set to wrap. OK, fine - labels were just an example, I don't claim I know better than anybody else how they should behave. c.) Height for width makes more sense when there are areas in your application which might be smaller or larger or contain some content which might not always be visible. [...] Sure. [...] Or in few words: am I missing anything? Taking it to the extreme, is there actually any way to create a simple widget which always asks for 100 000 pixels of screen space, but is totally indifferent with respect to the aspect ratio? Of course, many widgets do this, i.e. a GtkImage loaded from a pixbuf only requests the size of the image, and does not trade any height for width. Actually, what I'm asking is exactly the opposite: is there any way to create a simple widget which 1) requests (=minimal) a rectangular area of 10 000 pixels, accepting any possible ratio going from 20 x 500 to 500 x 20 2) suggests (=natural) a 100 x 100 square ? This is, to my eyes, the clearest example of height-for-width space management... and as far as I understand, it is currently impossible. Am I missing something? Thanks again, Pietro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width - reprise
Il giorno mer, 19/06/2013 alle 20.03 +0900, Tristan Van Berkom ha
scritto:
On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston m...@pietrobattiston.it
wrote:
[...]
This is, to my eyes, the clearest example of height-for-width space
management... and as far as I understand, it is currently impossible.
Am I missing something?
This is possible, but I don't know any widgets which do that, that's all.
void
widget_get_preferred_height_for_width (GtkWidget *widget,
gint width,
gint *minimum,
gint *natural)
{
/* You are going to be allocated 'width' which is something greater
* than the minimum width you reported in
get_preferred_width_for_height( height = -1);
*/
/* Now you will *request* this much height */
*minimum = height;
/* Note that 'natural' must be at least as big as 'minimum' */
*natural = desired_height_for_given_width (height);
/* Now you will *request* this much height */
*minimum = *natural = height;
}
Note that you might be allocated more size than that which you requested,
but not less.
You might want your aspect ratio height to be the minimum natural
instead of 'square', depending.
Does this answer your question ?
Well, this did suggest to me that my question was maybe not well
formulated - in fact, I have a problem with the layouting algorithm, not
with the working of a widget on its own. So consider this simple
example:
1) in my widget_get_preferred_width(), I set
*minimum = 50
*natural = 200
2) in my widget_get_preferred_height_for_width(), I set
*minimum = *natural = 1/width
3) I pack_start this widget into a Gtk.VBox()
4) I add the VBox in a Gtk.Window, and show_all() it
Result: a window that's 200x200 (and the user can't shrink vertically).
Now repeat the steps above, adding, between 3 and 4:
3a) I pack_start into the VBox an additional 60x17 GtkLabel (or
GtkImage, that's irrelevant).
Result: a window that's 200x183!
So to resume: what annoys me - in both cases - is that the window is
much too tall, and the user cannot even shrink it vertically.
But what I really find inconsistent is that by adding a widget below,
the resulting window may become smaller!
Anyway, I don't have a better algorithm in mind - if you tell me that
there is nothing I'm missing and there is no obvious solution to such
problem, I'll just make things work reasonably in reasonable contexts.
Thanks,
Pietro
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width - reprise
On Wed, Jun 19, 2013 at 10:13 PM, Pietro Battiston
m...@pietrobattiston.it wrote:
Il giorno mer, 19/06/2013 alle 20.03 +0900, Tristan Van Berkom ha
scritto:
On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston m...@pietrobattiston.it
wrote:
[...]
This is, to my eyes, the clearest example of height-for-width space
management... and as far as I understand, it is currently impossible.
Am I missing something?
This is possible, but I don't know any widgets which do that, that's all.
void
widget_get_preferred_height_for_width (GtkWidget *widget,
gint width,
gint *minimum,
gint *natural)
{
/* You are going to be allocated 'width' which is something greater
* than the minimum width you reported in
get_preferred_width_for_height( height = -1);
*/
/* Now you will *request* this much height */
*minimum = height;
/* Note that 'natural' must be at least as big as 'minimum' */
*natural = desired_height_for_given_width (height);
/* Now you will *request* this much height */
*minimum = *natural = height;
}
Note that you might be allocated more size than that which you requested,
but not less.
You might want your aspect ratio height to be the minimum natural
instead of 'square', depending.
Does this answer your question ?
Well, this did suggest to me that my question was maybe not well
formulated - in fact, I have a problem with the layouting algorithm, not
with the working of a widget on its own. So consider this simple
example:
1) in my widget_get_preferred_width(), I set
*minimum = 50
*natural = 200
2) in my widget_get_preferred_height_for_width(), I set
*minimum = *natural = 1/width
3) I pack_start this widget into a Gtk.VBox()
4) I add the VBox in a Gtk.Window, and show_all() it
Result: a window that's 200x200 (and the user can't shrink vertically).
Now repeat the steps above, adding, between 3 and 4:
3a) I pack_start into the VBox an additional 60x17 GtkLabel (or
GtkImage, that's irrelevant).
Result: a window that's 200x183!
So to resume: what annoys me - in both cases - is that the window is
much too tall, and the user cannot even shrink it vertically.
But what I really find inconsistent is that by adding a widget below,
the resulting window may become smaller!
Anyway, I don't have a better algorithm in mind - if you tell me that
there is nothing I'm missing and there is no obvious solution to such
problem, I'll just make things work reasonably in reasonable contexts.
It sounds like you're running into some issues with how the toplevel
decides to allocate the default size.
When I wrote height-for-width, I made sure the default size was
minimum height for minimum width, and then ensured that labels
requested a reasonably large minimum width by default (unless
the user sets width-chars explicitly to a small value).
This has been changed in GTK+ and I'm not sure what the details
are exactly now, first the trick I played to ensure labels were
reasonably wide by default was removed (resulting in some tall
dialogs with wrapping text in 3.2 or 3.4), now there is some other
logic/priority used to guess an appropriate window height (and
I think that's changed very recently, Matthias and Benjamin have
been fixing GtkWindow default sizes afaik so they would be able
to better comment on this).
However I think that what you are trying to do is a bit application
specific and not necessarily in the right place.
The layouting code is used to share space in what is allocated
in a toplevel window (and define some minimums, those minimums
should really be the minimum required to display some content).
If there is no left over space in your application (i.e. no scrolled window,
no area where it is useful to put extra space and then sacrifice some height
if the window is too 'slim' to fit other content), then height-for-width is
not really for you.
What you probably want, is a widget which requests 1x1 width height,
and is placed in a position where it will receive expand space in both
axis... after allocating you then decide to draw whatever fits in the
space you were allocated, centering it and drawing it with the desired
aspect ratio (as for example, totem movie player would do with it's
gstreamer widget to fit a scaled video surface into the area available
while preserving the aspect ratio).
Cheers,
-Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
On Thu, 2010-10-21 at 14:51 +0900, Tristan Van Berkom wrote:
On Thu, 2010-10-21 at 14:10 +0900, Tristan Van Berkom wrote:
On Thu, 2010-10-21 at 13:57 +0900, Tristan Van Berkom wrote:
On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
Hi,
On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
trista...@openismus.com wrote:
What happens when another subclass wants to use
-adjust_size_allocation() to realign itself further ? how
can it cooperate with GtkWidgetClass and not cause bad side
effects ?
In the patch I posted (assuming the FIXME is fixed), what would still
be broken?
I'm sort of lost what problems are unsolved. Granted, I might find out
if I tested the patch ;-)
This part will be re-broken, in this patch you are not adjusting the
allocated width for margins and alignments *before* getting the height
for the real allocated width:
---
adjusted_allocation = real_allocation;
if (gtk_widget_get_request_mode (widget) ==
GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH)
{
int min_width;
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
/* natural_width is a white lie; it's reduced to the
* actual allocation but kept above min.
*/
if (natural_width real_allocation.width)
natural_width = MAX(real_allocation.width, min_width);
gtk_widget_get_preferred_height_for_width (widget, natural_width,
NULL, natural_height);
}
else ...
---
And then it goes on too adjust the allocations after checking
the height for width:
---
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_VERTICAL,
natural_height,
adjusted_allocation.y,
adjusted_allocation.height);
---
Let's see what we can do with this api... it would have to be
something more like:
Actually even that is wrong, since we're passing a size that
has it's margins stripped to get_height_for_width(), which
will do the operation again on the for_size.
So it needs to add another line:
---
if (widget_is_height_for_width) {
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
After adjusting adjusting the allocated width with the aid of the real
natural width... we get a new adjusted_allocation.width, before passing
that width to get_preferred_height_for_width we need to:
gint adjusted_allocated_width = adjusted_allocation.width;
GTK_WIDGET_GET_CLASS (widget)-adjust_size_request(widget,
GTK_ORIENTATION_HORIZONTAL,
/* for_size is never needed
for this api afaics */
adjusted_allocated_width,
NULL);
And then we need to call get_height_for_width () to obtain the natural
height for the allocated width... /after/ adding some margins to the
inner allocated width, since those margins will be removed from the
for_size deep inside get_height_for_width() and then others re-added
to the output natural height.
Thanks for trying a patch out with this new API (it helps alot),
I'll try updating the patch to do what I think it needs to do and
send that one back.
I'll remove the for_size argument from -adjust_size_request() as
well since it's not used anywhere and I cant imagine what it can
be used for.
I've attached my patch here, with your API approach seems everything
falls into place.
Besides the changes I outlined above I also had to change GtkContainer
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
Hi,
On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
trista...@openismus.com wrote:
What happens when another subclass wants to use
-adjust_size_allocation() to realign itself further ? how
can it cooperate with GtkWidgetClass and not cause bad side
effects ?
In the patch I posted (assuming the FIXME is fixed), what would still be
broken?
I'm sort of lost what problems are unsolved. Granted, I might find out
if I tested the patch ;-)
This part will be re-broken, in this patch you are not adjusting the
allocated width for margins and alignments *before* getting the height
for the real allocated width:
---
adjusted_allocation = real_allocation;
if (gtk_widget_get_request_mode (widget) ==
GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH)
{
int min_width;
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
/* natural_width is a white lie; it's reduced to the
* actual allocation but kept above min.
*/
if (natural_width real_allocation.width)
natural_width = MAX(real_allocation.width, min_width);
gtk_widget_get_preferred_height_for_width (widget, natural_width,
NULL, natural_height);
}
else ...
---
And then it goes on too adjust the allocations after checking
the height for width:
---
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_VERTICAL,
natural_height,
adjusted_allocation.y,
adjusted_allocation.height);
---
Let's see what we can do with this api... it would have to be
something more like:
---
if (widget_is_height_for_width) {
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
gtk_widget_get_preferred_height_for_width (widget,
adjusted_allocation.width,
NULL, natural_height);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_VERTICAL,
natural_height,
adjusted_allocation.y,
adjusted_allocation.height);
}
---
From first glance at the portion that touches
gtksizerequest.c, the answer to the FIXME comment is
pretty much: yes it's going to be in the cache, we need
to call gtk_widget_get_preferred_width() there directly
to get a probably cached natural_width that has already been
treated by -adjust_size_request().
... and more importantly, why is this useful
to anybody except GtkWidget and GtkContainer ?
It is useful in any abstract base class that wants to provide stuff
around whatever its subclasses draw.
I think GtkContainer is actually a good enough reason to have this.
border-width is deprecated sure, but it's not going away soon, it'd be
nice to clean up all the code that has to deal with it.
Another example in GTK is GtkMisc, though we want to deprecate that
too, you could use this vfunc to delete the align and pad handling
from its subclasses and delete some code, which would be nice.
Hypothetically you could do things like:
* a base class that aligned in a more precise way than
left/right/center (like GtkAlignment)
* a base class providing more complex CSS-like border/margin/pad
capability with colors for each
* a base class that provided a frame
* a base class that adds any kind of display or status next to subclass
content
All of these could also be implemented as a container, granted. (That
is, GtkMisc and GtkAlignment solve the same problem.)
However, I think there can be good reasons to do this stuff in a base
class so your widgets can have the stuff built in
Hmm
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
On Thu, 2010-10-21 at 13:57 +0900, Tristan Van Berkom wrote:
On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
Hi,
On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
trista...@openismus.com wrote:
What happens when another subclass wants to use
-adjust_size_allocation() to realign itself further ? how
can it cooperate with GtkWidgetClass and not cause bad side
effects ?
In the patch I posted (assuming the FIXME is fixed), what would still be
broken?
I'm sort of lost what problems are unsolved. Granted, I might find out
if I tested the patch ;-)
This part will be re-broken, in this patch you are not adjusting the
allocated width for margins and alignments *before* getting the height
for the real allocated width:
---
adjusted_allocation = real_allocation;
if (gtk_widget_get_request_mode (widget) ==
GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH)
{
int min_width;
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
/* natural_width is a white lie; it's reduced to the
* actual allocation but kept above min.
*/
if (natural_width real_allocation.width)
natural_width = MAX(real_allocation.width, min_width);
gtk_widget_get_preferred_height_for_width (widget, natural_width,
NULL, natural_height);
}
else ...
---
And then it goes on too adjust the allocations after checking
the height for width:
---
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_VERTICAL,
natural_height,
adjusted_allocation.y,
adjusted_allocation.height);
---
Let's see what we can do with this api... it would have to be
something more like:
Actually even that is wrong, since we're passing a size that
has it's margins stripped to get_height_for_width(), which
will do the operation again on the for_size.
So it needs to add another line:
---
if (widget_is_height_for_width) {
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
After adjusting adjusting the allocated width with the aid of the real
natural width... we get a new adjusted_allocation.width, before passing
that width to get_preferred_height_for_width we need to:
gint adjusted_allocated_width = adjusted_allocation.width;
GTK_WIDGET_GET_CLASS (widget)-adjust_size_request(widget,
GTK_ORIENTATION_HORIZONTAL,
/* for_size is never needed
for this api afaics */
adjusted_allocated_width,
NULL);
And then we need to call get_height_for_width () to obtain the natural
height for the allocated width... /after/ adding some margins to the
inner allocated width, since those margins will be removed from the
for_size deep inside get_height_for_width() and then others re-added
to the output natural height.
Thanks for trying a patch out with this new API (it helps alot),
I'll try updating the patch to do what I think it needs to do and
send that one back.
I'll remove the for_size argument from -adjust_size_request() as
well since it's not used anywhere and I cant imagine what it can
be used for.
Cheers,
-Tristan
gtk_widget_get_preferred_height_for_width (widget,
adjusted_allocation.width,
NULL, natural_height);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_VERTICAL,
natural_height,
adjusted_allocation.y,
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
On Thu, 2010-10-21 at 14:10 +0900, Tristan Van Berkom wrote:
On Thu, 2010-10-21 at 13:57 +0900, Tristan Van Berkom wrote:
On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
Hi,
On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
trista...@openismus.com wrote:
What happens when another subclass wants to use
-adjust_size_allocation() to realign itself further ? how
can it cooperate with GtkWidgetClass and not cause bad side
effects ?
In the patch I posted (assuming the FIXME is fixed), what would still be
broken?
I'm sort of lost what problems are unsolved. Granted, I might find out
if I tested the patch ;-)
This part will be re-broken, in this patch you are not adjusting the
allocated width for margins and alignments *before* getting the height
for the real allocated width:
---
adjusted_allocation = real_allocation;
if (gtk_widget_get_request_mode (widget) ==
GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH)
{
int min_width;
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
/* natural_width is a white lie; it's reduced to the
* actual allocation but kept above min.
*/
if (natural_width real_allocation.width)
natural_width = MAX(real_allocation.width, min_width);
gtk_widget_get_preferred_height_for_width (widget, natural_width,
NULL, natural_height);
}
else ...
---
And then it goes on too adjust the allocations after checking
the height for width:
---
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_VERTICAL,
natural_height,
adjusted_allocation.y,
adjusted_allocation.height);
---
Let's see what we can do with this api... it would have to be
something more like:
Actually even that is wrong, since we're passing a size that
has it's margins stripped to get_height_for_width(), which
will do the operation again on the for_size.
So it needs to add another line:
---
if (widget_is_height_for_width) {
gtk_widget_get_preferred_width (widget, min_width,
natural_width);
GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
After adjusting adjusting the allocated width with the aid of the real
natural width... we get a new adjusted_allocation.width, before passing
that width to get_preferred_height_for_width we need to:
gint adjusted_allocated_width = adjusted_allocation.width;
GTK_WIDGET_GET_CLASS (widget)-adjust_size_request(widget,
GTK_ORIENTATION_HORIZONTAL,
/* for_size is never needed
for this api afaics */
adjusted_allocated_width,
NULL);
And then we need to call get_height_for_width () to obtain the natural
height for the allocated width... /after/ adding some margins to the
inner allocated width, since those margins will be removed from the
for_size deep inside get_height_for_width() and then others re-added
to the output natural height.
Thanks for trying a patch out with this new API (it helps alot),
I'll try updating the patch to do what I think it needs to do and
send that one back.
I'll remove the for_size argument from -adjust_size_request() as
well since it's not used anywhere and I cant imagine what it can
be used for.
I've attached my patch here, with your API approach seems everything
falls into place.
Besides the changes I outlined above I also had to change GtkContainer
adjust_size_allocation() implementation to do it's own magic *first*
and then chain up to GtkWidgetClass after.
Otherwise with extra-large allocations, a container border width
would be
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
On Fri, 2010-10-15 at 11:32 -0400, Havoc Pennington wrote:
Hi,
I think I get what you're saying. If not I'll probably understand it
reading your code.
btw things are looking kind of messed up to me in the current code in
gtkwidget.c ... this:
gtk_widget_get_preferred_width (widget, NULL, natural_width);
get_span_inside_border_horizontal (widget,
aux_info,
allocation-width,
natural_width,
x, w);
so natural_width has the margins in it, right? But it's centered
without removing those margins first. The code up in
get_span_inside_border() removes margins from allocation-width but
not natural_width.
It seems like we need to remove the margins to get
adjusted_natural_width. And then say in GtkContainer, we need that
adjusted_natural_width and we remove border_width from it, and then we
pass the twice-adjusted natural width with both margins and border
width and alignment-added-padding stripped down to the actual subclass
like GtkButton.
Without trying to code it and see if it works, it could look like:
(* adjust_size_allocation) (GtkWidget *widget,
GtkOrientation orientation,
gint *for_size_opposite,
gint *natural_size,
gint *offset,
gint *adjusted_size);
where all four numbers are changing as we're chaining
Widget-Container-Button
Might be nicer to do struct GtkAllocatedSize { int for_size_opposite;
int natural_size; int offset; int adjusted_size } ?
Ok my brain is about to explode trying to figure out the right
implementation for this, lets look in detail to the requirements.
From what I understand, come time to adjust the size for allocation
GtkWidget needs to do the following steps (for simplicity, lets assume
GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH mode):
- Strip any padding added by itself and any subclasses from the
allocation-width (this produces a 'stripped_allocated_width')
- If halign != FILL, it needs to limit the width to the real natural
size, this in itself involves:
a.) calling gtk_widget_get_preferred_width()
b.) stripping any padding from the returned natural width
(producing a 'stripped_natural_width')
c.) interior width available for alignments becomes
MIN (stripped_allocation_width, stripped_natural_width)
- Now that we have the proper width for interior allocation; go ahead
and strip any padding added to the allocation-height, i.e. get
a 'stripped_allocated_height'.
- If valign != FILL, we need to further limit the height to the
proper natural height for width, the fun continues:
a.) We need to *re-add* any required padding to the concluded
interior allocation width, presumably by calling
-adjust_size_request() on our _final_ width which was
concluded by the previous steps.
b.) We need to use this new adjusted width to obtain the natural
height and do that by calling
gtk_widget_get_preferred_height_for_width()
c.) Now we need to strip the added padding from the returned
natural height (getting us a usable
'stripped_natural_height').
d.) The interior height available for alignment/allocation
now becomes:
MIN (stripped_allocated_height, stripped_natural_height)
- Now we have a proper width and height we can go on to align
the interior allocation inside the padded space in both
orientations.
Of course furthermore, gtk_widget_get_height_for_width needs to be
amended to adjust the for_width by:
- Stripping any extra padding added by -adjust_size_request from
the for_width.
- If halign != FILL then it needs to:
a.) gtk_widget_get_preferred_width() to obtain the natural width
b.) strip any padding previously added to the natural width
c.) 'for_width' then becomes
MIN (stripped_for_width, stripped_natural_width);
- Call the class vfunc -height_for_width() using the adjusted
'for_width'
That's the big picture of what needs to happen, however it's still
not mapped to any proper API... I've been tentatively writing some
pseudo code that should do it but I keep getting stuck somewhere.
Maybe splitting the adjust_size_allocation() and align_size_allocation()
makes sense, but I get the feeling that adding apis here is creating
a mess factor we dont want to deal with in the long run (and admittedly
I still dont have a clear picture of how it can all work).
There's also another alternative, all of this alignment/padding code
so far belongs to GtkWidget (and marginally GtkContainer), so does all
of the size-requesting
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi,
I would think of it like this maybe
real_adjust_request(orientation, request_data)
{
adjust_request_by_adding_margin(orientation, request_data)
/* alignment does not affect request */
}
real_adjust_allocation(orientation, allocation_data)
{
adjust_allocation_by_removing_margin(orientation, allocation_data)
adjust_allocation_by_aligning(orientation, allocation_data)
}
I think allocation_data *includes* the natural size, which is itself
adjusted. So when you by_removing_margin you are dropping down the
natural size you started with so that the align stuff has the
marginless size. Same for for_size.
Conceptually GtkWidget contains two adjustments. But those two
adjustments should not have anything to do with each other. It's as if
you had a hierarchy like:
GtkWidget - GtkWidgetWithMargin - GtkWidgetWithAlignment
Those would chain up to each other. But since it's all in one class
the two adjusts are invoked inline. However if our adjust vfunc has
the right signature, it should be possible to do margin and alignment
orthogonally.
On Sun, Oct 17, 2010 at 5:36 AM, Tristan Van Berkom
trista...@openismus.com wrote:
- Strip any padding added by itself and any subclasses from the
allocation-width (this produces a 'stripped_allocated_width')
Widget base class need not strip what subclasses added - each subclass
strips its own. When overriding, subclass has to chain up so widget
can do its stuff just as container does.
I'd also say margin here for clarity rather than padding
- If halign != FILL, it needs to limit the width to the real natural
size, this in itself involves:
a.) calling gtk_widget_get_preferred_width()
I think get_preferred_width should be called outside of the adjust
vfunc, and then initial natural size passed in. As the adjustment
proceeds, the natural size is chopped down by each adjustment.
b.) stripping any padding from the returned natural width
(producing a 'stripped_natural_width')
This should be done by the adjust_allocation_by_removing_margin() and
the natural width that then gets passed for aligning would be reduced.
c.) interior width available for alignments becomes
MIN (stripped_allocation_width, stripped_natural_width)
Hmm this doesn't sound right. Conceptually we have to decide if the
margin is inside or outside the alignment-required padding. This
basically means whether we do the margin adjust first or the align
adjust first. (Note that on request you go from inner adjust to outer,
i.e. chain up last, and on allocation the other direction, i.e. chain
up first. So if margin is on the outside, it would be added second in
request, and removed first in allocate.)
Anyway. What should come in to
adjust_allocation_by_aligning(allocation_data) should be a natural
size de-margined and an allocation also de-margined. We just align the
de-margined natural size in the de-margined allocation.
- Now that we have the proper width for interior allocation; go ahead
and strip any padding added to the allocation-height, i.e. get
a 'stripped_allocated_height'.
I think you go back and have your unadjusted width allocation, and you
pass that as the for_width to the
adjust_allocation(orientation=height). Now as the allocation
adjustment proceeds, each adjust step has to also adjust for_width (in
addition to the allocation itself and the natural size).
Of course furthermore, gtk_widget_get_height_for_width needs to be
amended to adjust the for_width by:
- Stripping any extra padding added by -adjust_size_request from
the for_width.
Rather, each adjust_size_allocation step (align, margin,
border_width are 3 steps) should compensate for itself in the
for_width as the chaining up proceeds.
That's the big picture of what needs to happen, however it's still
not mapped to any proper API... I've been tentatively writing some
pseudo code that should do it but I keep getting stuck somewhere.
I think just adding the natural size, for_size, and orientation to the
existing two vfuncs should work. Probably need a struct to hold {
size, natural_size, for_size } which are the three things to adjust.
There's also another alternative, all of this alignment/padding code
so far belongs to GtkWidget (and marginally GtkContainer), so does all
of the size-requesting logic... so we could go the direction of:
- remove vfuncs -adjust_size_allocation/-adjust_size_request
I think the adjust approach should be workable as described above and
keep the nice encapsulation / flexibility of the vfuncs.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom trista...@openismus.com wrote: What happens when another subclass wants to use -adjust_size_allocation() to realign itself further ? how can it cooperate with GtkWidgetClass and not cause bad side effects ? In the patch I posted (assuming the FIXME is fixed), what would still be broken? I'm sort of lost what problems are unsolved. Granted, I might find out if I tested the patch ;-) ... and more importantly, why is this useful to anybody except GtkWidget and GtkContainer ? It is useful in any abstract base class that wants to provide stuff around whatever its subclasses draw. I think GtkContainer is actually a good enough reason to have this. border-width is deprecated sure, but it's not going away soon, it'd be nice to clean up all the code that has to deal with it. Another example in GTK is GtkMisc, though we want to deprecate that too, you could use this vfunc to delete the align and pad handling from its subclasses and delete some code, which would be nice. Hypothetically you could do things like: * a base class that aligned in a more precise way than left/right/center (like GtkAlignment) * a base class providing more complex CSS-like border/margin/pad capability with colors for each * a base class that provided a frame * a base class that adds any kind of display or status next to subclass content All of these could also be implemented as a container, granted. (That is, GtkMisc and GtkAlignment solve the same problem.) However, I think there can be good reasons to do this stuff in a base class so your widgets can have the stuff built in Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
On Thu, 2010-10-14 at 10:45 -0400, Havoc Pennington wrote:
In sounds like in short the for_size somehow needs to be adjusted
(strip out the pixels that adjust_size_request added). (If I'm
understanding properly.) Of course that's what adjust_size_allocation
does, except it's both dimensions. for_size is after all the proposed
allocation size in one dimension.
Ouch, indeed.
The for_size fed to widget implementations additionally needs to
strip the added padding that can happen in -adjust_size_request()
However the bug I'm referring to is another one; the for_size also
needs to be limited to the natural size in the case that the widget
does not fill (i.e. not to compensate for pixels stripped in
-adjust_size_request(), but for pixels that will further be stripped
in -adjust_size_allocation(), in the case that the widget expanded).
Maybe just change adjust_size_allocation to take a GtkOrientation and
return a single integer (could have a convenience function to do the
current full GtkAllocation adjust). Then use that to clean up for_size
when it comes in to compute_size_for_orientation() in
gtksizerequest.c. Or I think for now it'd also work to make a
GtkAllocation allocation = { MAXINT, for_height } and adjust that,
seems less hacky to change adjust_size_allocation to be able to do
just one dimension.
Right, this will be a bit more difficult as the current
adjust_size_allocation() needs to use the context of both
APIs (i.e. it needs to call get_request_mode() and then
either get_preferred_width and get_preferred_height_for_width()
or the other way around).
However changing that API seems like the right thing to do,
I suppose it will need to take the natural_width as an argument,
which seems strange.. the api would look similar to the current
gtkwidget.c static functions:
get_span_inside_border_horizontal/vertical().
In the end the adjust_size_allocation() api/vfunc
will look like this:
void gtk_widget_adjust_allocated_size (GtkWidget *widget,
GtkOrientation orientation,
gint proposed_size,
gint natural_size,
gint *offset,
gint *adjusted_size);
And then gtk_widget_adjust_allocation() would be a convenience API
that would call the above api, this convenience API would function
in the same way as the current implementation does internally:
'gtk_widget_real_adjust_size_allocation()'
The part that feels weird here is that we are feeding in the
natural_size, however it's important because come allocation time
specifically; the 'natural_size' may be in context to a for_size
in the other orientation (i.e. the widget cannot be expected to
just know its natural size in this stage).
I'll give this approach a shot with the above API change and
file a bug for it shortly...
-Tristan
PS: After looking at this, it feels also a bit strange that we need
to have -adjust_size_request/allocation() (i.e. it seems that the
added border-width that GtkContainer computes here should just be
pulled in by chaining up vfuncs through parent classes during
the request/allocate cycles), however I suppose there's nothing
to be done for that... or is there...
I don't think a solution that looks at xalign specifically is needed,
so we can keep the abstraction barrier. The generic mechanism just
needs to be smart enough to know that the for_size is a proposed
(adjusted up) allocation and thus has to be unadjusted before
computing the unadjusted request.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom trista...@openismus.com wrote: The for_size fed to widget implementations additionally needs to strip the added padding that can happen in -adjust_size_request() Right, adjust_size_allocation should basically invert anything adjust_size_request does so the widget is seeing things as if only the widget itself had set the request. By padding I don't just mean the margin properties, I mean anything adjust_size_request adds (also the padding for fill alignment, the container border width, etc.) However the bug I'm referring to is another one; the for_size also needs to be limited to the natural size in the case that the widget does not fill (i.e. not to compensate for pixels stripped in -adjust_size_request(), but for pixels that will further be stripped in -adjust_size_allocation(), in the case that the widget expanded). Wouldn't it fix this to do adjust_size_allocation on the for_size? In the end the adjust_size_allocation() api/vfunc will look like this: void gtk_widget_adjust_allocated_size (GtkWidget *widget, GtkOrientation orientation, gint proposed_size, gint natural_size, gint *offset, gint *adjusted_size); If you have a for_size (which can be -1 for unset) then you could skip the natural size and just call the size request API again, using the for_size if = 0. I think that would be better, because as you say: The part that feels weird here is that we are feeding in the natural_size, however it's important because come allocation time specifically; the 'natural_size' may be in context to a for_size in the other orientation (i.e. the widget cannot be expected to just know its natural size in this stage). I think you should just call the request methods again. (Not the wrappers of course, the vfuncs directly.) Instead of passing in a natural size. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi, On Fri, Oct 15, 2010 at 9:55 AM, Havoc Pennington h...@pobox.com wrote: I think you should just call the request methods again. (Not the wrappers of course, the vfuncs directly.) Instead of passing in a natural size. I guess this doesn't work when chaining up and down Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
On Fri, 2010-10-15 at 09:55 -0400, Havoc Pennington wrote: Hi, On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom trista...@openismus.com wrote: The for_size fed to widget implementations additionally needs to strip the added padding that can happen in -adjust_size_request() Right, adjust_size_allocation should basically invert anything adjust_size_request does so the widget is seeing things as if only the widget itself had set the request. By padding I don't just mean the margin properties, I mean anything adjust_size_request adds (also the padding for fill alignment, the container border width, etc.) However the bug I'm referring to is another one; the for_size also needs to be limited to the natural size in the case that the widget does not fill (i.e. not to compensate for pixels stripped in -adjust_size_request(), but for pixels that will further be stripped in -adjust_size_allocation(), in the case that the widget expanded). Wouldn't it fix this to do adjust_size_allocation on the for_size? In the end the adjust_size_allocation() api/vfunc will look like this: void gtk_widget_adjust_allocated_size (GtkWidget *widget, GtkOrientation orientation, gint proposed_size, gint natural_size, gint *offset, gint *adjusted_size); If you have a for_size (which can be -1 for unset) then you could skip the natural size and just call the size request API again, using the for_size if = 0. I think that would be better, because as you say: The part that feels weird here is that we are feeding in the natural_size, however it's important because come allocation time specifically; the 'natural_size' may be in context to a for_size in the other orientation (i.e. the widget cannot be expected to just know its natural size in this stage). I think you should just call the request methods again. (Not the wrappers of course, the vfuncs directly.) Instead of passing in a natural size. It needs to: a.) call the wrappers to get a natural_width before entering adjust_size_allocation(for_size, natural_width) so as to pick up a good cached value that was treated by sizegroups and by adjust_size_request() b.) feed a natural size vs a proposed size to the adjust_size_allocation() because as I mentioned above: at allocation time, a widget cannot know its natural size, since it's natural size can be contextual to its dimension in the other orientation. Otherwise when doing valign at allocate time, the implementation calls get_preferred_height () ? no it cant because it's height already depends on its already allocated width (I recently fixed gtk_widget_real_adjust_natural_allocation() since it was calling gtk_widget_get_preferred_size(), which results in vertically clipped labels when valigned CENTER). So the convenience function that calls the new gtk_widget_adjust_size_allocation(), clearly has to do the right contextual request that gtk_widget_real_adjust_size_allocation() does now (i.e. not the one it was doing 2 weeks ago)... the orientation contextual adjust_size_allocation()... needs to be told what is the natural size... it has no context to make a guess. Sorry, but this really is as complex as it seems... -Tristan Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
Hi,
I think I get what you're saying. If not I'll probably understand it
reading your code.
btw things are looking kind of messed up to me in the current code in
gtkwidget.c ... this:
gtk_widget_get_preferred_width (widget, NULL, natural_width);
get_span_inside_border_horizontal (widget,
aux_info,
allocation-width,
natural_width,
x, w);
so natural_width has the margins in it, right? But it's centered
without removing those margins first. The code up in
get_span_inside_border() removes margins from allocation-width but
not natural_width.
It seems like we need to remove the margins to get
adjusted_natural_width. And then say in GtkContainer, we need that
adjusted_natural_width and we remove border_width from it, and then we
pass the twice-adjusted natural width with both margins and border
width and alignment-added-padding stripped down to the actual subclass
like GtkButton.
Without trying to code it and see if it works, it could look like:
(* adjust_size_allocation) (GtkWidget *widget,
GtkOrientation orientation,
gint *for_size_opposite,
gint *natural_size,
gint *offset,
gint *adjusted_size);
where all four numbers are changing as we're chaining Widget-Container-Button
Might be nicer to do struct GtkAllocatedSize { int for_size_opposite;
int natural_size; int offset; int adjusted_size } ?
Sorry I got this wrong in my original patch :-/
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]
In sounds like in short the for_size somehow needs to be adjusted
(strip out the pixels that adjust_size_request added). (If I'm
understanding properly.) Of course that's what adjust_size_allocation
does, except it's both dimensions. for_size is after all the proposed
allocation size in one dimension.
Maybe just change adjust_size_allocation to take a GtkOrientation and
return a single integer (could have a convenience function to do the
current full GtkAllocation adjust). Then use that to clean up for_size
when it comes in to compute_size_for_orientation() in
gtksizerequest.c. Or I think for now it'd also work to make a
GtkAllocation allocation = { MAXINT, for_height } and adjust that,
seems less hacky to change adjust_size_allocation to be able to do
just one dimension.
I don't think a solution that looks at xalign specifically is needed,
so we can keep the abstraction barrier. The generic mechanism just
needs to be smart enough to know that the for_size is a proposed
(adjusted up) allocation and thus has to be unadjusted before
computing the unadjusted request.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Sigh, alright can of worms open. Not sure exactly where to start here but lets keep in mind that of course, any window must fit all of its screen content at all times, that's not to say that it requires the minimum-height-for-minimum-width at all times, but only when it's allocated it's minimum width (as Owen pointed out before, it's quite possible to bump the window's height constraint in a more dynamic way; while growing the window's height as needed when the user shrinks it's width, I have not tested this but I think its a behaviour worth considering, ofcourse we would not want to *shrink* the window's height automatically when the user grows the width, that would look just awkward IMO). Also... lets try to break this down into two separate issues at hand. First issue being that the window requires enough height to fit the windows minimum width at all times... this is because we dont to any dynamic updating of window constraints based on window allocations. Second thing is that Owen disagrees that the minimum wrap width of a label should be limited to something greater than the size of the largest word. My initial thoughts on these issues is that: a.) dynamic constraints on GtkWindow is something worth experimenting b.) The minimum size of a label is not a hack just because of our current minimum-for-minimum policy on window constraints, and for the most part should be left as is. Comments in line... On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote: On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote: Agreed, GtkLabel needs to report min size = true min sane size and natural size = either full width, or a good width The full width is more correct imo, maybe we should figure out why that doesn't work well. I'm not sure you agree completely here, are you saying that a wrapping label's minimum width should be the width of the largest word ? or it should be a true sane minimum size ? My opinion is that a single word wrap width is definitely not a sane minimum size at all. In other words I don't think its a sane idea to allow the user to shrink the window's width so much that its height probably flows right off screen (leaving larger paragraphs virtually unreadable in a single column when hitting the minimum constraint). However, currently we use width-chars property of label to allow the user to declare an unreasonably small minimum width for a label (very small minimums IMO should only be used for some static text that is known to never be a long paragraph, thus never pushing window height to an unreasonably large value when allocated its minimum width). For an ellipsized label, the natural width is clearly the full width. In this case there's an obvious interpretation of natural size because there's a minimum size where we display all the information and above that we're just adding padding. I don't completely agree here either, in many cases that are important to handle the text displayed in a label is some user input, data loaded from a database or even some translated text that wont fit normal screen constraints (same goes for the natural width of a GtkCellRendererText). For this reason it is important for the programmer to consider setting max-width-chars on a label that may have overly large text. Ellipsizing labels will still consume more space when allocated any further space via its expand or via resizing of treeview columns (for cell renderers). But for a wrapped label, there are many different possibilities for displaying all the information. I'm not sure that there's anything more natural about the case where we put each paragraph on a single unwrapped line. Of course, if we take the position that there is never any reason to allocate an actor more than it's natural size - if the natural size is all the size that is useful - then using a narrower natural width could be problematical, especially if things like centering are added by the parent actor or GTK+, and not the actor itself. A related patch attached, if you fix this you'll quickly want it. Yeah, came up when I was fixing gnome-terminal behavior (see e.g., https://bugzilla.gnome.org/show_bug.cgi?id=631903) Also, you said if doing minimum-height-for-natural-width the window doesn't wrap the label and can't be made narrower. I don't understand that... I would expect the min size of the window is the min height for natural width as you propose, and the min width as returned by get_preferred_width(). So the min width ought to be the true min width? If you use those values, then you are telling the window manager that the window can be sized to a size that's too small for its contents. Since GTK+ 3 basically can't handle underallocation all, this isn't a good idea. (The behavior with underallocation is that widgets are allocated with their minimum size centered at their allocated location. Since there is no clipping this means you get
Re: Minimum height for minimum width
On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom trista...@openismus.com wrote: Sigh, alright can of worms open. For an ellipsized label, the natural width is clearly the full width. In this case there's an obvious interpretation of natural size because there's a minimum size where we display all the information and above that we're just adding padding. I don't completely agree here either, in many cases that are important to handle the text displayed in a label is some user input, data loaded from a database or even some translated text that wont fit normal screen constraints (same goes for the natural width of a GtkCellRendererText). For this reason it is important for the programmer to consider setting max-width-chars on a label that may have overly large text. Ellipsizing labels will still consume more space when allocated any further space via its expand or via resizing of treeview columns (for cell renderers). Common example here: filenames / paths ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom trista...@openismus.com wrote: On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote: On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote: Agreed, GtkLabel needs to report min size = true min sane size and natural size = either full width, or a good width The full width is more correct imo, maybe we should figure out why that doesn't work well. I'm not sure you agree completely here, are you saying that a wrapping label's minimum width should be the width of the largest word ? or it should be a true sane minimum size ? My point here was mostly about the natural width. I don't have a lot of opinion about what min sane size is (though in general I think it should be smallest size that can work at all) I don't completely agree here either, in many cases that are important to handle the text displayed in a label is some user input, data loaded from a database or even some translated text that wont fit normal screen constraints (same goes for the natural width of a GtkCellRendererText). For this reason it is important for the programmer to consider setting max-width-chars on a label that may have overly large text. IMO this should never be necessary unless something is broken. The toplevel should pick a default size that's no larger than maximized (work area) by default, if it can do so while staying above its min size. (This may be an important addition to that GtkWindow default size = natural size patch.) Widgets should not have to do a bunch of custom f*ing around logic. They should report min useful size and max useful size, done and done. If that doesn't work, the toolkit is broken. Label trying to second-guess stuff to keep the toplevel aspect ratio correct is just broken. Now, we've just established that due to the WM interaction we may have to be broken at least on X ... ;-) but hopefully the consequences of that limitation can be minimized. In theory we could pretty quickly get a new WM protocol in metacity/gnome-shell to fix it for real, too - if we know what the protocol is, which I don't. The only time I think you should have to do max-width-chars is when you don't want the window to ever default to full screen width (presumably you decide this is just ugly, for example). You shouldn't have to set this to unbreak stuff - for example, you shouldn't have to set it just to keep the window from going off the screen. btw shouldn't max-width-chars be called natural-width-chars? I certainly always saw the good width to wrap to thing as a workaround for GTK+ 1/2 geometry management. But picking a good aspect ratio from the toplevel will require a binary search. That might be fine if the binary search is done only once when picking a default size for the toplevel when first mapping it. Not sure where this portion is going, ofcourse setting the default width of a window to be the natural width of the window should be fine and doable, using reasonably sized labels and good judgement with max-width-chars this is currently doable. I think a good first cut would be natural width constrained to work area size - the WM may already do that constraint anyhow, hopefully. Some windows might be sort of oddly wide compared to their height but they won't go offscreen. Making things a pretty aspect ratio could be done via binary search, but maybe is better done by just letting apps set max-width-chars or otherwise messing with their layout. Doing it by magic picking of a good wrap width by default ... eh. Such a weird hack. One thing I have to add is that constraining the width of the window to be the natural width of the window is surely not what we want; It would mean that minimum sizes of labels are then unattainable completely (in which case, why have a minimum size at all ? the minimum then becomes the natural for the whole window's content). I don't think anyone was suggesting this Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
I guess to me it's much better to have one hack in GtkWindow globally (GtkWindow is already a giant special case) than to leak the hack into all widgets that actually do h-for-w. Just a separation of concerns thing. It doesn't make sense for N child widgets inside a window to all be trying to heuristically guess how to make the window have a nice aspect ratio. Just do that on the toplevel. Even if the GtkWindow hack is really nasty like a binary search, that's fine. (I think a binary search might be overkill... picking a default size assuming there's a roughly linear relation between min W x H-for-min-W and nat W x H-for-nat-W probably works fine and is only 3 request cycles and only to pick default size, not on every resize) Then when implementing widgets, just return min size = min useful, natural size = max useful, that is the raw data for GtkWindow, no guesses. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
On Tue, 2010-10-12 at 09:45 -0400, Havoc Pennington wrote: Hi, On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom trista...@openismus.com wrote: On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote: On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote: Agreed, GtkLabel needs to report min size = true min sane size and natural size = either full width, or a good width The full width is more correct imo, maybe we should figure out why that doesn't work well. I'm not sure you agree completely here, are you saying that a wrapping label's minimum width should be the width of the largest word ? or it should be a true sane minimum size ? My point here was mostly about the natural width. I don't have a lot of opinion about what min sane size is (though in general I think it should be smallest size that can work at all) I don't completely agree here either, in many cases that are important to handle the text displayed in a label is some user input, data loaded from a database or even some translated text that wont fit normal screen constraints (same goes for the natural width of a GtkCellRendererText). For this reason it is important for the programmer to consider setting max-width-chars on a label that may have overly large text. IMO this should never be necessary unless something is broken. The toplevel should pick a default size that's no larger than maximized (work area) by default, if it can do so while staying above its min size. (This may be an important addition to that GtkWindow default size = natural size patch.) Widgets should not have to do a bunch of custom f*ing around logic. They should report min useful size and max useful size, done and done. If that doesn't work, the toolkit is broken. Label trying to second-guess stuff to keep the toplevel aspect ratio correct is just broken. I'm not sure what exactly you are talking about here, the only guess a label currently makes is for a reasonable width-chars, i.e. limiting a wrapping label to a reasonably large minimum width. This is to avoid unreasonably large heights in proportion to the width. I don't think that its right to allow the minimum width to be as small as a single word, that either results in: a.) requiring the height-for-minimum width at all times in the window (current behaviour) b.) letting the user shrink the window's width too small and grow the window's height too much (if we were to constrain window size dynamically) Sure, the programmer is allowed to set a small minimum width via the width-chars, but lets not encourage him by making it the default behaviour of the label. If you disagree with that, then what would you have the label do in place ? Please explain where we are second-guessing stuff and how exactly the toolkit is broken, then we can move on to fix it. So far the two things I would change (or add as enhancements) are: a.) Add a feature to let the GtkWindow choose a default size according to the natural size clamped into the screen size b.) Try making the window's height constraint contextual to the window's allocated width. I wouldn't say the toolkit is broken just because we haven't yet added those features. Now, we've just established that due to the WM interaction we may have to be broken at least on X ... ;-) but hopefully the consequences of that limitation can be minimized. In theory we could pretty quickly get a new WM protocol in metacity/gnome-shell to fix it for real, too - if we know what the protocol is, which I don't. The only time I think you should have to do max-width-chars is when you don't want the window to ever default to full screen width (presumably you decide this is just ugly, for example). You shouldn't have to set this to unbreak stuff - for example, you shouldn't have to set it just to keep the window from going off the screen. Good point, if we add a feature to GtkWindow to set a default size automatically according to its natural request, then this would become apparent. One place for instance we would definitely want to set max-width-chars is in GtkDialog texts (generally we dont want single line-high dialogs that span the whole screen width, of course). Other places we would want to use max-width-chars would be in cell renderers, depending on the view's design I think alot of cases would like to restrict the natural size of a column in proportion to it's surrounding columns - if only to achieve a desired look and proportion. btw shouldn't max-width-chars be called natural-width-chars? It's called max-width-chars because the property already existed, we just used that same property in context of the new geometry management system (just to not add more api bloat). I certainly always saw the good width to wrap to thing as a workaround for GTK+ 1/2 geometry management. But picking a good aspect ratio from the toplevel will require a binary search
Re: Minimum height for minimum width
On Tue, 2010-10-12 at 10:21 -0400, Havoc Pennington wrote: I guess to me it's much better to have one hack in GtkWindow globally (GtkWindow is already a giant special case) than to leak the hack into all widgets that actually do h-for-w. Just a separation of concerns thing. It doesn't make sense for N child widgets inside a window to all be trying to heuristically guess how to make the window have a nice aspect ratio. I see what you're saying and it makes sense to me. However I wouldn't say there is that much heuristic guesswork involved in GtkLabel, only a rule of thumb: don't have a small minimum width if its going to result in a huge height-for-minimum-width (i.e. its not like the label is counting its siblings in the hierarchy and doing something proportional to the current window size, or anything really all that scary at all). Just do that on the toplevel. Even if the GtkWindow hack is really nasty like a binary search, that's fine. (I think a binary search might be overkill... picking a default size assuming there's a roughly linear relation between min W x H-for-min-W and nat W x H-for-nat-W probably works fine and is only 3 request cycles and only to pick default size, not on every resize) Then when implementing widgets, just return min size = min useful, natural size = max useful, that is the raw data for GtkWindow, no guesses. And currently the min useful is just not defined as a single word width. Anyway, currently we have nothing at all in place that guesses the default size - I'm not at all against adding code along those lines (just for the record, there's no need for any alarm as far as I can see, please). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 11:20 AM, Tristan Van Berkom trista...@openismus.com wrote: I'm not sure what exactly you are talking about here, the only guess a label currently makes is for a reasonable width-chars, i.e. limiting a wrapping label to a reasonably large minimum width. This is to avoid unreasonably large heights in proportion to the width. search for guess_wrap_width in gtklabel.c, that's what I mean, i think it's the same thing you're talking about. That sets min size I guess, but I'm also saying we should have natural size be max useful size, not another guess (related to earlier discussion). Basically I don't think min or natural should be a guess what looks good, they should be true min and max useful size. b.) letting the user shrink the window's width too small and grow the window's height too much (if we were to constrain window size dynamically) too small and too much here just means somewhat unaesthetic aspect ratio rather than broken. If the user wants to resize to that, fine. Maybe their screen is a weird size. We shouldn't default to it though, which is why GtkWindow needs more smarts. If min size is two words per line instead of one word, ok, but philosophically the min size should be the minimum size that's remotely useful - NOT size that looks pretty good or guess at a nice aspect ratio Essentially, I don't think individual widgets should have much smarts about this stuff. They should just report min remotely useful size, max remotely useful size. Toolkit or app need to take steps to then make the overall layout look good. Please explain where we are second-guessing stuff and how exactly the toolkit is broken, then we can move on to fix it. I'm saying if the label needs any intelligence then we have a problem because any other widget using h-for-w would also need intelligence, and those heuristics may not even be compatible with each other or make sense in the overall layout. Widgets should just be dumb about this. Report their min and max useful size. So far the two things I would change (or add as enhancements) are: a.) Add a feature to let the GtkWindow choose a default size according to the natural size clamped into the screen size b.) Try making the window's height constraint contextual to the window's allocated width. Yep I agree I wouldn't say the toolkit is broken just because we haven't yet added those features. If making Label dumb (just reports min and max useful size) has bad results, then that's a bug in the toolkit, or at least the app, or some widget with more contextual knowledge like GtkDialog. There isn't enough information on the Label level. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Tue, Oct 12, 2010 at 11:40 AM, Tristan Van Berkom trista...@openismus.com wrote: And currently the min useful is just not defined as a single word width. Understood, I think we basically agree. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
). Again you are jumping from label to window. In general, in most real layouts, labels will always be allocated a reasonable amount of width even if they have very small minimum sizes. For an ellipsized label, the natural width is clearly the full width. In this case there's an obvious interpretation of natural size because there's a minimum size where we display all the information and above that we're just adding padding. I don't completely agree here either, in many cases that are important to handle the text displayed in a label is some user input, data loaded from a database or even some translated text that wont fit normal screen constraints (same goes for the natural width of a GtkCellRendererText). For this reason it is important for the programmer to consider setting max-width-chars on a label that may have overly large text. Ellipsizing labels will still consume more space when allocated any further space via its expand or via resizing of treeview columns (for cell renderers). I think you need to think very carefully about how natural width is explained and documented, since it seems to be neither exactly: - the maximum useful width - a good width for the widget I get the impression from the above that the main point of natural size is that once a widget reaches it's natural size it will stop competing with other widgets for space? That may be a useful concept, but if we can't coherently document and explain natural width, then we'll have a decade of confused programmers on our hands. (I'm confused right now!) Hmm. The a good width to wrap to thing seems like pretty much crack to me. If people want their window to have some sort of pleasing aspect ratio they should just pack the label to limit its width, or set default size on the window, or whatever. Or maybe GtkWindow should constrain the default size to nice aspect ratio somehow, solving globally for the window instead of per-label. I certainly always saw the good width to wrap to thing as a workaround for GTK+ 1/2 geometry management. But picking a good aspect ratio from the toplevel will require a binary search. That might be fine if the binary search is done only once when picking a default size for the toplevel when first mapping it. Not sure where this portion is going, ofcourse setting the default width of a window to be the natural width of the window should be fine and doable, using reasonably sized labels and good judgement with max-width-chars this is currently doable. If the minimum height of a window is the minimum height for the minimum width, and the natural width of a label is the width with no wrapping, then no, making the default width of the window the natural width of the window doesn't work. One thing I have to add is that constraining the width of the window to be the natural width of the window is surely not what we want; It would mean that minimum sizes of labels are then unattainable completely (in which case, why have a minimum size at all ? the minimum then becomes the natural for the whole window's content). There's no getting around it, for GtkLabel in GtkWindow, if we have a single minimum size without height-for-width, then we don't have useful reflow - we just have a single layout with a size determined by the programmer. I don't think that there's anything worse in using natural width minimum height for natural width For that layout than: minimum width minimum height for minimum width these are both equally good minimum sizes. The only real questions are what the other consequences are of each decision - how does that affect other uses of minimum width and natural width. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi,
On Tue, Oct 12, 2010 at 12:09 PM, Owen Taylor otay...@redhat.com wrote:
I think you need to think very carefully about how natural width is
explained and documented, since it seems to be neither exactly:
- the maximum useful width
- a good width for the widget
I get the impression from the above that the main point of natural size
is that once a widget reaches it's natural size it will stop competing
with other widgets for space?
conceptually and in ascending pixel size I think there could be:
a) min size widget can be without breaking (breaking = drawing outside
bounds or whatever)
b) min size widget can be while being useful (still show some
recognizable info such as at least one word)
c) a good size
d) max size widget can do something useful with
e) size at which widget acts like expand=false (this is what I'd call
max size and I think it's a feature GTK doesn't have right now)
Coincidentally Matthias was just trying to invent e) on scrolled
window by dynamically changing expand flag (see
https://bugzilla.gnome.org/show_bug.cgi?id=628902), that just won't
work afaik, but we _could_ in theory add a max_size to
get_preferred_{width,height} which would do this at the cost of making
size request more complex to implement.
At the moment I'd say min size should be b) and natural size should be
d), but maybe there is a solid argument for c). I tend to think c)
should be done at GtkWindow or application level.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
On Tue, 2010-10-12 at 12:09 -0400, Owen Taylor wrote: On Tue, 2010-10-12 at 15:44 +0900, Tristan Van Berkom wrote: [...] Also... lets try to break this down into two separate issues at hand. First issue being that the window requires enough height to fit the windows minimum width at all times... this is because we dont to any dynamic updating of window constraints based on window allocations. *Even if you don't do any dynamic updating* the minimum-for-minimum approach isn't inherently right, it's a decision that you are making. A height-for-width window content doesn't have a single minimum size, it has a range of minimum sizes: +---+ +-+ +--+ +--+ | | | | | | +--+ | | | | +--+ | | | | | | +-+ | | +---+ You are saying that we should always pick the left-most version - the tallest version, and make that the minimum size and the default size. (Without dynamic updating, minimum and default size should be the same for a window without any expandable areas; e.g. a dialog with buttons and labels, since a bigger default would just add useless excess space.) I've been saying that for a height-for-width layout the leftmost should be chosen for the minimum size yes. The default size is usually left up to the programmer to decide (the right-most would a be more ideal minimum size for width-for-height layouts). Why ? because that offers the most flexibility for height-for-width widgets in the UI, i.e. labels are allowed to reach their minimum size. However that's not to be stubborn and say that I'm right %100 of the time, its only the logical conclusion I came to when facing the restriction of having to chose a final minimum size (and not update the constrained height dynamically). The corollary to this is that if I'm designing a window I have to make the minimum width on the window the right width - the width where it has a pleasing aspect ratio and looks good. Maybe this is a reasonable conclusion, but it's not some inherently logical conclusion. Second thing is that Owen disagrees that the minimum wrap width of a label should be limited to something greater than the size of the largest word. My initial thoughts on these issues is that: a.) dynamic constraints on GtkWindow is something worth experimenting b.) The minimum size of a label is not a hack just because of our current minimum-for-minimum policy on window constraints, and for the most part should be left as is. Comments in line... On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote: On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote: Agreed, GtkLabel needs to report min size = true min sane size and natural size = either full width, or a good width The full width is more correct imo, maybe we should figure out why that doesn't work well. I'm not sure you agree completely here, are you saying that a wrapping label's minimum width should be the width of the largest word ? or it should be a true sane minimum size ? My opinion is that a single word wrap width is definitely not a sane minimum size at all. In other words I don't think its a sane idea to allow the user to shrink the window's width so much that its height probably flows right off screen (leaving larger paragraphs virtually unreadable in a single column when hitting the minimum constraint). You are jumping from a conclusion about windows to a conclusion about labels. Yes, if I have a window with a single label in it, and I've implemented height-for-width window constraints on it in some fashion, then it doesn't make sense to allow the user to accidentally reflow the window so it is 5000 pixels tall. We want a reasonable minimum width on the window. But that doesn't mean that that minimum reasonable width of a window should be used for minimum reasonable width of a label - there are lots of other places where a label can be used. If someone is using a layout editor, and they add a label for a name, and they decide that they want it to wrap onto two lines when necessary, they are going to be very surprised when setting the label wrappable suddenly makes everything expand way out horizontally. Yes, they can find the width-chars property and crank it down, but I don't think this is expected behavior. Keeping to expected behavior is important for making people understand what's going on... it's better to have people reason out: Oh, if I don't set a minimum width on the window, then the user can resize it way down and it gets too tall, I better set a minimum width Than learn: Labels in GTK+ start off with a magic width that seems to be around 40-50 characters wide. If you want to make a wrapping label narrower than that you have to set the width-chars property The first way may not be any easier than
Re: Minimum height for minimum width
Hi,
On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington h...@pobox.com wrote:
d) max size widget can do something useful with
e) size at which widget acts like expand=false (this is what I'd call
max size and I think it's a feature GTK doesn't have right now)
Trying to think about how these two are different, and not really
getting anywhere. It seems like you'd never set the max size above the
natural size.
So in the scrolled window case, to get the effect Matthias was going
for, maybe the answer would just be to set the max size hint on the
window to the natural size. The problem with that is basically
maximization and fullscreen, i.e. that we don't really want a max size
- it's better to add padding.
Conclusion perhaps, e) is not useful, user should always be able to
resize too high and get extra padding in the layout, if they want.
The situation where it could make sense to add max_size to
get_preferred_{width,height} might be if the natural size were defined
as c) a good size, then you'd also be able to use a separate max
useful size. For example then a box layout would first bring all
children up to the good size; if still extra space, then bring them
all up to max size; if still extra space, then start padding them.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
On Tue, 2010-10-12 at 13:27 -0400, Havoc Pennington wrote:
Hi,
On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington h...@pobox.com wrote:
d) max size widget can do something useful with
e) size at which widget acts like expand=false (this is what I'd call
max size and I think it's a feature GTK doesn't have right now)
Trying to think about how these two are different, and not really
getting anywhere. It seems like you'd never set the max size above the
natural size.
So in the scrolled window case, to get the effect Matthias was going
for, maybe the answer would just be to set the max size hint on the
window to the natural size. The problem with that is basically
maximization and fullscreen, i.e. that we don't really want a max size
- it's better to add padding.
Conclusion perhaps, e) is not useful, user should always be able to
resize too high and get extra padding in the layout, if they want.
The situation where it could make sense to add max_size to
get_preferred_{width,height} might be if the natural size were defined
as c) a good size, then you'd also be able to use a separate max
useful size. For example then a box layout would first bring all
children up to the good size; if still extra space, then bring them
all up to max size; if still extra space, then start padding them.
Ah interesting, I suppose that when a label's xalign property is
not FILL, it will cease unwrapping and giving away height once
allocated any size greater than its natural width.
I suppose that's not really a problem though, the desired effect
of align != FILL needs only to be properly interpreted.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
On Mon, 2010-10-11 at 15:41 -0400, Havoc Pennington wrote: Uggghhh... so the h-f-w request/allocate stuff needs to be exposed to the WM ;-) Client-side decorations! :) Then we can handle everything ourselves. (Of course it's not so trivial... then we'll want to know things like snap coordinates from the WM. Or yeah, we may actually need a new protocol so that the WM and the client can work together during resizes.) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Minimum height for minimum width
When we are doing height-for-width layout, sometimes we get a situation where we have a height-for-width object in a context that doesn't support height-for-with-layout. Examples: A) The height-for-width contents of a GtkWindow. X doesn't support height-for-width layout, the window hints are just the minimum size and the default size. [*] B) A height-for-width widget inside a container that is width-for-height. The current behavior of GTK+-2.9x is that the miminum size in such a context is the minimum-height-for-the-minimum width. This sounds obviously right, but I think it's not. For example, if a wrapping GtkLabel did the obvious thing and reported its minimum width as the minimum width as the width of the longest word, the result of putting this inside a GtkWindow would be: ++ |This| |is | (using the current default-size-of-GtkWindow is minimum size) |some| |text| ++ Or +-+ |This is some text| | | (using default-size-of-GtkWindow is natural size) | | | | +-+ Because that works out so badly, GtkLabel currently doesn't report it's real minimum width, but, as in GTK+-2.0, reports a guess of a good width to wrap to as the mininum width, so what you get is that the window starts off as: +--+ |This is | |some text | +--+ and can't be resized to a smaller width/height. That doesn't work badly for this case, but means that a wrapped GtkLabel always has that artificial minimum width, even in cases where it has a real height-for-width parent. (Unless overridden by the programmer.) In my opinion minimum-height-for-minimum width is just conceptually wrong - the minimum width should be the real minimum width, and at the real minimum width a height-for-width widget will be unnaturally tall. This is no a good miminimum height. What, to my mind, works better in every way is minimum-height-for-natural-width. The objection I was hearing to this is then the window ends up with: +-+ |This is some text| +-+ And can't be made any narrower than this, but unlike minimum width, the natural width has no inherent meaning for a widget that can adapt to any width, like a wrapping label. We can get identical results to the current results by making a wrapped GtkLabel report a good width to wrap to as the *natural* width. And we do this without breaking the minimum width of GtkLabel. - Owen [*] It actually works pretty well in X to report a dynamic minimum height depending on the current width. We start off with the minimum width of the window as the real minimum width, but the minimum height of the window as the height for the default/natural width. If the user starts shrinking the window horizontally, we set progressively bigger minimum height hints. This does work out slightly oddly with wireframe resizing, however. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Agreed, GtkLabel needs to report min size = true min sane size and
natural size = either full width, or a good width
The full width is more correct imo, maybe we should figure out why
that doesn't work well.
A related patch attached, if you fix this you'll quickly want it.
Also, you said if doing minimum-height-for-natural-width the window
doesn't wrap the label and can't be made narrower. I don't understand
that... I would expect the min size of the window is the min height
for natural width as you propose, and the min width as returned by
get_preferred_width(). So the min width ought to be the true min
width?
Hmm. The a good width to wrap to thing seems like pretty much crack
to me. If people want their window to have some sort of pleasing
aspect ratio they should just pack the label to limit its width, or
set default size on the window, or whatever. Or maybe GtkWindow should
constrain the default size to nice aspect ratio somehow, solving
globally for the window instead of per-label.
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: Minimum height for minimum width
On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote: Agreed, GtkLabel needs to report min size = true min sane size and natural size = either full width, or a good width The full width is more correct imo, maybe we should figure out why that doesn't work well. For an ellipsized label, the natural width is clearly the full width. In this case there's an obvious interpretation of natural size because there's a minimum size where we display all the information and above that we're just adding padding. But for a wrapped label, there are many different possibilities for displaying all the information. I'm not sure that there's anything more natural about the case where we put each paragraph on a single unwrapped line. Of course, if we take the position that there is never any reason to allocate an actor more than it's natural size - if the natural size is all the size that is useful - then using a narrower natural width could be problematical, especially if things like centering are added by the parent actor or GTK+, and not the actor itself. A related patch attached, if you fix this you'll quickly want it. Yeah, came up when I was fixing gnome-terminal behavior (see e.g., https://bugzilla.gnome.org/show_bug.cgi?id=631903) Also, you said if doing minimum-height-for-natural-width the window doesn't wrap the label and can't be made narrower. I don't understand that... I would expect the min size of the window is the min height for natural width as you propose, and the min width as returned by get_preferred_width(). So the min width ought to be the true min width? If you use those values, then you are telling the window manager that the window can be sized to a size that's too small for its contents. Since GTK+ 3 basically can't handle underallocation all, this isn't a good idea. (The behavior with underallocation is that widgets are allocated with their minimum size centered at their allocated location. Since there is no clipping this means you get a mess of overlapping widgets.) Setting the hints dynamically based on the current width can work, if we're willing to say screw wireframe resizing (wireframe resizing doesn't completely *not* work, you just have to release and retry a few times to get to certain sizes.) Hmm. The a good width to wrap to thing seems like pretty much crack to me. If people want their window to have some sort of pleasing aspect ratio they should just pack the label to limit its width, or set default size on the window, or whatever. Or maybe GtkWindow should constrain the default size to nice aspect ratio somehow, solving globally for the window instead of per-label. I certainly always saw the good width to wrap to thing as a workaround for GTK+ 1/2 geometry management. But picking a good aspect ratio from the toplevel will require a binary search. That might be fine if the binary search is done only once when picking a default size for the toplevel when first mapping it. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Mon, Oct 11, 2010 at 3:30 PM, Owen Taylor otay...@redhat.com wrote: Setting the hints dynamically based on the current width can work, if we're willing to say screw wireframe resizing (wireframe resizing doesn't completely *not* work, you just have to release and retry a few times to get to certain sizes.) Uggghhh... so the h-f-w request/allocate stuff needs to be exposed to the WM ;-) I can't even think of a good solution in theory, offhand. I guess having labels pick a good width is the best option. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
