Re: Minimum height for minimum width

[Tristan Van Berkom]

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 a 

Re: Minimum height for minimum width

[Matthias Clasen]

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: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Thu, Oct 7, 2010 at 6:41 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 I was thinking that a GtkCellArea would only render a single row
 (actually, a row in a treeview can be composed of several GtkCellAreas,
 each treeview column would use exactly one cell area to abstract a lot
 of the column code).

 Now that I look at this again I'm not sure if the GtkCellArea should
 store any information about previous and following rows
  - should the alignment of cells be stored by the GtkCellArea itself ?
  - or should it be externalized to some parenting code that pushes
    the alignment data to the area ?

 I think that the former seems more appropriate since only the CellArea
 knows how cells can be aligned for a particular implementation, and
 the initial width/height of cells in the area is also determined by
 the CellArea.

I agree that the former seems more appropriate.  This also paves a way
for doing more flexible layouting in tree view rows.  However, I guess
that we also want to support how cells are laid out right now in
columns and this requires some separate entity to maintain the
alignment and widths for a set of cell areas.

  - GtkCellArea (or a subclass) might also have to implement the custom 
 event-handling and focus drawing
 code that is currently in GtkTreeViewColumn.

 I think an abstraction api for event handling is simple enough and a
 good fit for a single-row handling GtkCellArea.

 gtk_cell_area_event (GtkCellArea  *cell_area,
                     GdkRectangle *area,
                     GdkEvent     *event);

 This would be implemented by CellArea implementations
 and basically forward the event to the appropriate cell
 renderer according to the area's layout.

 I suppose the method for invoking this by treeview for
 instance would be:
   - Get the appropriate GtkTreeViewColumn for the event-x
   - The GtkTreeViewColumn would then get the appropriate GtkTreeIter
     for event-y
   - The GtkTreeViewColumn would then push the data for that
     column into its delegate GtkCellArea.
   - Then the GtkTreeViewColumn calls gtk_cell_area_event().

 Sounds approximately right ?

It sounds interesting to me and will likely work.  Do note that
currently things are done differently, tree view makes the function
call to push the data (though this function is a tree view column
function, so must be possible to refactor this).  Furthermore,
currently not GdkEvents are pushed to the cell renderer, but rather
the activate or start-editing method on the cell renderer is
called.  I think this lines up well with the plan to have the GdkEvent
only reach the cell area.

 I think that focus painting in this case should be left to the treeview
 and the GtkCellArea continues to return bounds of the overall used
 space for it's dedicated GdkRectangle (because the treeview sometimes
 like's to paint focus which spans the entire treeview row... which
 may span several GtkCellAreas for each column; each of which may
 have a different bounds in height).

There's also a case in which focus is drawn around a single cell
renderer (that is part of a column together with other cell
renderers).  So this means that either the cell area can draw this
focus, or the exact coordinates of this cell can be acquired from the
cell area.

 Ok good points, you'll notice I left out GtkCellAreaManager comments
 here...

 I think you're right that the whole big picture is much and probably not
 reasonable to get done by 3.0.

 The best move I think is to break this down into iterations, since my
 immediate concerns are about actual rendering and alignment of cells
 (i.e. achieve height-for-width treeviews and alignment of cells in
 combo boxes)... hopefully I can come up with something good and
 extendable for the GtkCellArea.

Yes, we should definitely break this down into iterations.  Starting
with pushing the cell renderer lay out code from GtkTreeViewColumn
into something like a GtkCellArea sounds like a good start to me.


 The concept of row separators and group headings will need some
 thought, I'm not sure it makes sense to chose a different GtkCellArea
 class to render a different row, these cases may be better handled
 as general functionality of the base class (which could be overridden
 by subclasses to achieve a different overall look-n-feel of the
 treeview).

Definitely requires more thought and can, as far as I can see, be done
separately from GtkCellArea.

 I also wonder with some of the offscreen rendering magic recently added
 we can even get GtkButtons to be virtually embedded into a GtkCellArea
 subclass (ofcourse without allocating a separate instance of the
 GtkButton for every row of data being the challenge)... by simply
 rendering the button onto every row...

Interesting idea, and since you want to make it possible to push
GdkEvents into GtkCellArea, the button will also behave appropriately.
 (The event handling was the main issue why you couldn't do something
like a GtkButton in a 

Re: Minimum height for minimum width

[Havoc Pennington]

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

[Havoc Pennington]

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

[Tristan Van Berkom]

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. That 

Re: Minimum height for minimum width

[Tristan Van Berkom]

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

[Havoc Pennington]

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

[Havoc Pennington]

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

[Owen Taylor]

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.)

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 the second way, but it's far
less magic and more comprehensible.

Now, obviously if we combine:

 - Label doesn't have a magic minimum width when wrapping

With:

 - Window starts off with minimum width

Then that also could produce something a little unexpected - but I think
it would be better to have an artificial minimum size enforced by
default on GtkWindow than on GtkLabel. (For one thing, it deals with
things that are *like* GtkLabel.)

 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).

Re: Minimum height for minimum width

[Havoc Pennington]

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

[Tristan Van Berkom]

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 the 

Re: Minimum height for minimum width

[Havoc Pennington]

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

[Tristan Van Berkom]

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

[Federico Mena Quintero]

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

Minutes of the GTK+ Team Meeting - 2010-10-12

[Emmanuele Bassi]

Minutes of the GTK+ Team Meeting - 2010-09-21

• magic expand (bug: 628902)
- ongoing work on the widget-expand-3 branch
- related containers migrated
- mclasen considers it ready for merge
- missing issue: window resizability
  ‣ might be a bit tricky
  ‣ can be worked on post-merge

• multi-root FileChooser (bug: 609886)
- as discussed on gtk-devel-list
- API footprint is limited
- not really a security feature
  ‣ restricts root for loading files from a removable volume
  ‣ useful for kiosk-like environments
  ‣ first step towards proper lockdown
- still some kinks

• fate of the tutorial and examples
- old cruft, basically unmaintained
- some content should be migrated to the API reference
  ‣ packing: GtkContainer + GtkBox
  ‣ signal connection: GtkWidget + GtkWindow
- examples should be moved and xincluded into the reference
ACTION: ebassi will do the tutorial surgery

• remove GtkWrapBox
- no real users
- probably merged a bit too soon
ACTION: removal from master, eventual move to libegg
- topic for the hackfest: LayoutManager class for delegating layout code

• deprecate / remove gtk_init_add / remove* API (bug: 629955)
- look like pre-1.x API, so not widely used any more
- no reasonable use cases in a modern use of gtk
- should just go away

• destroy - up or down ? (bug: 630690)
- move it down to GtkWindow?
- or up to GObject?
- what actually are the requirements?
  ‣ big hammer to break reference cycles
  ‣ g_object_run_dispose()
  ‣ ::destroy signal for notification top-levels? widgets?
- needs to be discussed at the hackfest

• deprecation of glib gettext macros (bug: 624186)
- glib-gettext is a remnant of gettext  0.10
- upstream has become more useful
- gdk-pixbuf migrated
- clutter migrated too
- glib-gettext adds glib functions to po/Makefile.in.in's --keyword and --flag
  ‣ overrides in upstream gettext go into po/Makevars
  ‣ glib needs to ship a macro to generate those overrides

• GtkComboBoxText subclass to supersede text convenience API (bug: 612396)
  ‣ GtkComboBoxEntryText needed?
- gtk_combo_box_text_* API is already a sub-class in disguise
  ‣ mutually exclusive
- a real sub-class would just ratify the existing code
- complication: it makes GtkComboBoxEntry slightly more awkward, and requires
  a sub-class for that
  ‣ could be solved by folding the entry as a property of the super-class
- GtkComboBoxText should be accepted
- merge GtkComboBox and GtkComboBoxEntry
ACTION: tristan to investigate the merge

next meeting: gtk+ hackfest (2010-10-18 → 2010-10-23)

log available at: http://live.gnome.org/GTK%2B/Meetings

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

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