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

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

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

[Havoc Pennington]

Hi,

On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington  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 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

Re: Minimum height for minimum width

[Havoc Pennington]

Hi,

On Tue, Oct 12, 2010 at 12:09 PM, Owen Taylor  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

[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

Re: Minimum height for minimum width

[Havoc Pennington]

Hi,

On Tue, Oct 12, 2010 at 11:40 AM, Tristan Van Berkom
 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

[Havoc Pennington]

Hi,

On Tue, Oct 12, 2010 at 11:20 AM, Tristan Van Berkom
 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

[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

[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
>  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

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

[Havoc Pennington]

Hi,

On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom
 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: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld]

On Thu, Oct 7, 2010 at 6:41 AM, Tristan Van Berkom
 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 is

Re: Minimum height for minimum width

[Matthias Clasen]

On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom
 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