Re: Extended Layout Summary
Am Freitag, den 21.12.2007, 11:05 +0100 schrieb Mathias Hasselmann: Am Donnerstag, den 20.12.2007, 11:46 -0500 schrieb Havoc Pennington: Third, since implementing an interface requires extra boilerplate GObject stuff, it would be convenient for authors of a custom widget if GtkWidget already did the boilerplate for them. Since for newly-written custom widgets, the recommendation would be to always support extended layout. I don't see the boilerplate savings you talk about? As far as I understand GObject interfaces, you always need this this single-line boilerplate for overriding interface methods: G_DEFINE_TYPE_WITH_CODE (MamanBar, maman, GTK_TYPE_WIDGET, G_IMPLEMENT_INTERFACE (GTK_TYPE_IFACE, maman_bar_iface_init)) Not if GtkWidget already implements GtkExtendedLayout-get_min_size() like this: GTK_WIDGET_GET_CLASS(instance)-get_min_size. Then you could easily override the implementation in class_init(). I think this was what Havoc meant. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Donnerstag, den 20.12.2007, 11:46 -0500 schrieb Havoc Pennington:
Hi,
Mathias Hasselmann wrote:
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
So you suggest, that GtkWidget implements GtkExtendedLayout?
Several factors I can think of here.
First when implementing each container, it would be nice to avoid:
if (is_extended_layout(child)) {
use new request API
} else {
use old size request API
}
One solution would be that GtkWidget automatically implements extended
layout in terms of size request. Another solution would be just a
convenience function that does the above.
Yes, it makes sense to implement GtkExtendedLayout at GtkWidget level
already. This step has quite some potential to simplify code.
I'm guessing your patch already had a solution to this, I don't remember
what it was.
Two, when implementing a widget, it would be good to avoid writing both
the old size request and the new extended layout. So, one way to do that
is that in GtkWidget there's a default implementation of size request
that invokes extended layout. This may require GtkWidget to implement
extended layout, or maybe the default impl of size request could do
GTK_IS_EXTENDED_LAYOUT(), that might be fine too. Then GtkWidget would
not have to implement extended layout.
The solution I used, was adding a flag, respectively a callback to the
old size_request method indicating the operation mode (minimum
size/natural size). My size_request implementation called that now
internal function with minimum-size arguments, the natural_size
implementation called with natural-size arguments.
Ugly, compared to the smart choice of fallback behavior you suggest.
I'll modify my patches, so that all containers directly use the extended
layout interface, without any if/else mambo for child measurement.
Third, since implementing an interface requires extra boilerplate
GObject stuff, it would be convenient for authors of a custom widget if
GtkWidget already did the boilerplate for them. Since for newly-written
custom widgets, the recommendation would be to always support extended
layout.
I don't see the boilerplate savings you talk about? As far as I
understand GObject interfaces, you always need this this single-line
boilerplate for overriding interface methods:
G_DEFINE_TYPE_WITH_CODE (MamanBar, maman, GTK_TYPE_WIDGET,
G_IMPLEMENT_INTERFACE (GTK_TYPE_IFACE, maman_bar_iface_init))
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
What if the API for GTK+ were something like the above, plus a
width-for-height variant, so rename the above two:
get_desired_width(int*,int*)
get_desired_height_for_width(int,int*,int*)
and add:
get_desired_height(int*,int*)
get_desired_width_for_height(int,int*,int*)
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
- the default implementation of size_request
(gtk_widget_real_size_request) is modified to do something like
You mean do_size_request() in gtksizegroup.c, don't you?
gtk_widget_real_size_request just returns cached data since size groups
were introduced.
if (widget has height-for-width feature) {
get_desired_width(widget, min_width, NULL);
get_desired_height_for_width(widget, min_width, min_height,
NULL);
This API would require to calculate the size of GtkLabel for at least
three times:
1) get_desired_width
2) get_desired_height_for_width with min_width
3a) get_desired_height_for_width with allocated width of the
parent in vertically aligned containers like GtkVBox
3b) get_desired_width_for_height with allocated height of the
parent in horizontally aligned containers like GtkHBox
Why is it sensible to calculate the size three times?
Wouldn't it be better to replace size_request with
void get_desired_size (GtkRequisition *minimum,
GtkRequisition *natural);
Your get_desired_height_for_width and get_desired_width_for_height
functions would keep the signature you suggested (expect that I'd drop
the word desired).
I cannot imagine situations, where you are without size restrictions,
but cannot trivially retrieve the other dimensions of a desired size.
So we really should calculate both dimension in one single step.
The point is, in newly-written widgets ideally there is no need to code
the now-deprecated size_request; and also for most widgets hopefully no
need to implement width-for-height since that's something of a strange case.
How to react when a library user adds a handler to size-request signal
of a modern widget? Simply ignore it? Would be quite nasty if each
implementation of get_desired_size would have to emit and handle that
signal.
That's a bit tricky for GTK since there's legacy gunk in the way, but I
think it's the ideal.
That comment was directed to the padding stuff, we do not discuss right
now. Nevertheless it's also right for the new size request. Specially
since size groups were hacked in at some point in history. That's why
I've chosen the less ambitious way of adding a simple get_natural_size
method: Less interaction with legacy code.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington: Then the following default implementations: - all four of the new functions have default implementations that invoke the current size_request and use it for both min and natural size; so unmodified widgets still support the new interface So you suggest, that GtkWidget implements GtkExtendedLayout? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Hi,
Mathias Hasselmann wrote:
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
So you suggest, that GtkWidget implements GtkExtendedLayout?
Several factors I can think of here.
First when implementing each container, it would be nice to avoid:
if (is_extended_layout(child)) {
use new request API
} else {
use old size request API
}
One solution would be that GtkWidget automatically implements extended
layout in terms of size request. Another solution would be just a
convenience function that does the above.
I'm guessing your patch already had a solution to this, I don't remember
what it was.
Two, when implementing a widget, it would be good to avoid writing both
the old size request and the new extended layout. So, one way to do that
is that in GtkWidget there's a default implementation of size request
that invokes extended layout. This may require GtkWidget to implement
extended layout, or maybe the default impl of size request could do
GTK_IS_EXTENDED_LAYOUT(), that might be fine too. Then GtkWidget would
not have to implement extended layout.
Third, since implementing an interface requires extra boilerplate
GObject stuff, it would be convenient for authors of a custom widget if
GtkWidget already did the boilerplate for them. Since for newly-written
custom widgets, the recommendation would be to always support extended
layout.
Those are the factors I can think of. I might be wrong about them, or
there may be other factors that are also important and that lead to the
opposite conclusion.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 20:45 -0500 schrieb Behdad Esfahbod:
On Tue, 2007-11-20 at 20:09 -0500, Behdad Esfahbod wrote:
On Tue, 2007-11-20 at 07:23 -0500, Mathias Hasselmann wrote:
When a container widget got more space allocated than requested, it
considers the difference between natural and requested size of its
children to distribute that additional space, in relation to the child's
difference between natural and minimum-size. Let's use an example for
demonstration:
Assume we have a container with two children. Both children request
a_min = b_min = 50 pixels as minimum size. The first child announces
a_nat = 100 pixels, the second announces b_nat = 200 pixels as
natural size.
This gives a requested size of c_min = 100 pixels, and a natural
size of 300 pixels (c_nat) for the container. Now the container gets
allocated at a size of 200 pixels (c_cur). This are 100 pixels to
distribute (c_gap).
So the first child gets:
a_cur = a_min + c_gap * (a_nat - a_min) / (c_nat - c_nat)
= 50+ 100 * 50 / 200
= 75 pixels.
The second child gets:
b_cur = b_min + b_gap * (b_nat - b_min) / (c_nat - c_nat)
= 50+ 100 * 150 / 200
= 125 pixels.
Something that Ryan brought up, and I was hoping that Havoc answer is
that the above algorithm is not optimal, you can easily do better.
Quoting Havoc's words: bring smaller items up to natural size first.
Read his entire TEXT LAYOUT THAT WORKS PROPERLY? post here:
http://log.ometer.com/2006-10.html
Without checking HippoCanvas's implementation, I think this is how it
should work:
Say there are n child widgets c^0 .. c^{n-1}, let
c^i_diff = c^i_nat - c^i_min
We want to assign c^i_gap such that the sum of c^i_gap's is equal to
c_gap, the container's extra space to distribute. We only consider the
case that there's not enough space for all children to take their
natural size. The goals we want to achieve:
a) Maximize number of children taking their natural size.
b) The allocated size of children should be a continuous function of
c_gap. That is, increasing the container size by one pixel should never
make drastic changes in the distribution.
Goal a rules your current algorithm out as yours essentially keeps all
children off their natural size until there's enough room for all.
Goal b means that you cannot start from the least child gap, fulfill
them and then distribute the remaining gap between the rest of the
children, because when enough gap becomes available for you to
accommodate one more natural child, the allocations jump
noncontinuously.
This algorithm achieves both goals: Distribute gap to children equally
(not linearly) and not more than they need. That is:
- Sort children with decreasing c^i_diff. Use child order in the
container to break ties.
I have some concerns that the sorting step changes the complexity class
for some containers from O(n) to O(n log n). On the other hand we have
O(n^2) in GtkTable already. So probably this doesn't hurt too much, I
guess.
- Allocate like this:
for (i = n - 1; i = 0; i--)
{
double share = (double) c_gap / (i + 1);
if (share = c^i_diff)
c^i_gap = c^i_diff;
else
c^i_gap = ceil (share);
c_gap -= c^i_gap;
}
So it sounds interesting to try. But as Matthias pointed out already,
the use of natural size information is an implementation detail. So the
question is, if I should try that variant before my code is merged.
Something completely unrelated: now that you are adding extended layout
features, should we switch to doubles or some fixed subpixel format for
size negotiation? The idea being, making it easier to make Gtk+
dpi-independent in the future.
From my observation late conversion to integer values could save some
pixels wasted due pessimistic rounding, which would be another
advantage.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington: Hi, While I haven't looked at the patches in detail, based on your writeup it feels like the interfaces here will make it a little hard to implement in widgets. [...] I had your suggestion in mind all the time, when implementing the extended layout stuff, but at least for the existing container widgets in GTK+ calculating minimum and natural size at the same time would have resulted in more complicated code, as many variables would have to be duplicated: One set of variables to hold state for minimum size calculation, one set for natural size. So the pattern I successfully used was adding a flag to the old size_request implementation indicating weither requested size, or natural size is needed. In the requested size case only gtk_widget_size_request is called for children, in the natural size case the extended layout hints were tried first, with as fallback gtk_widget_size_request. My implementations of GtkWidgetClass::size_request and GtkExtendedLayoutIface::natural_size just redirect to that function, using the correct flag. After finding that pattern, adding natural size support to existing container widgets was quite trivial. Another thing I'm not clear on from your mail is the padding stuff; basically, it looks like every widget implements padding support for itself. In that case, what's the point of having get_padding in the generic extended layout interface? I mainly needed it, when trying to implement baseline alignment for GtkBin derived widgets: GtkBinClass doesn't have any padding for additional virtual functions, so I abused the extended-layout interface to get that information. Guess it can be ignored for now, as I didn't manage to get baseline alignment working - all tough using extended layout hints to add padding to all widgets, without using GtkAlignment sounds quite interesting. Well, and you are right: Using GtkBorder is quite wasteful in terms of memory usage. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Hi, Matthias Clasen wrote: On Nov 20, 2007 8:45 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: a) Maximize number of children taking their natural size. I am not convinced this is always the best strategy. Doesn't this encourage starving one child in favour of the rest of the pack getting their natural size ? If you really want to be flexible in this, you probably need to go to a TeX-like glue model and assign stretchabilities and shrinkabilities to children. The canonical example is an ellipsizable label, where the min size is something like the size of one letter plus ..., and the natural size is the entire label width (given the available height). So, if you have a box full of labels and get extra allocation above the minimum size, you want to first show all text in all labels (give everything its natural size) and then second add padding or spacing (give things more than their natural size). What you don't want to do is add padding or spacing, while some labels are still ellipsized. In the HippoCanvas comments I defined natural size as: The natural width should be thought of as the width at which alignment (HIPPO_ALIGNMENT_START etc.) makes no difference but at which nothing will be chopped off or wrapped. That is, natural size is roughly defined as the size at which we show everything, but don't have any padding or spacing. It's size that's more important than padding and spacing Clearly this is something that should be crisply defined in the GTK docs when extended layout is added. Here is the comment from HippoCanvasBox on how its algorithm works; I am too lazy to follow Behdad's pseudocode to see if it is equivalent ;-) /* If we have an allocation larger than our request (min width), we distribute the space among children as follows: 1) for each child below natural width, bring it up to its natural width a) count children with a request still below their natural width b) find the child with the smallest needed expansion to reach natural width and record this needed expansion c) distribute among below-natural-width children the minimum of (all space remaining to distribute) and (smallest needed expansion times number of children to expand) d) goto a) if children below natural width remain 2) if extra space still remains, divide it equally among each child with expand=true In other words, children will always grow to their natural width whether they are expand=true or not. Below-natural-size children always grow before expand=true children. Various optimizations are obviously possible here (keep track of flags for whether we have any expandable / any natural!=minimum, for example). The PACK_IF_FITS children are done in a second pass after other children, the if_fits flag indicates which pass this is. If if_fits=TRUE we need to skip if_fits children that did not fit. */ Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Nov 21, 2007 1:53 PM, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Matthias Clasen wrote: On Nov 20, 2007 8:45 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: a) Maximize number of children taking their natural size. I am not convinced this is always the best strategy. Doesn't this encourage starving one child in favour of the rest of the pack getting their natural size ? If you really want to be flexible in this, you probably need to go to a TeX-like glue model and assign stretchabilities and shrinkabilities to children. The canonical example is an ellipsizable label, where the min size is something like the size of one letter plus ..., and the natural size is the entire label width (given the available height). So, if you have a box full of labels and get extra allocation above the minimum size, you want to first show all text in all labels (give everything its natural size) and then second add padding or spacing (give things more than their natural size). What you don't want to do is add padding or spacing, while some labels are still ellipsized. In the HippoCanvas comments I defined natural size as: The natural width should be thought of as the width at which alignment (HIPPO_ALIGNMENT_START etc.) makes no difference but at which nothing will be chopped off or wrapped. That is, natural size is roughly defined as the size at which we show everything, but don't have any padding or spacing. It's size that's more important than padding and spacing Clearly this is something that should be crisply defined in the GTK docs when extended layout is added. Here is the comment from HippoCanvasBox on how its algorithm works; I am too lazy to follow Behdad's pseudocode to see if it is equivalent ;-) You can't do that, that's what I did ;-). /* If we have an allocation larger than our request (min width), we distribute the space among children as follows: 1) for each child below natural width, bring it up to its natural width a) count children with a request still below their natural width b) find the child with the smallest needed expansion to reach natural width and record this needed expansion c) distribute among below-natural-width children the minimum of (all space remaining to distribute) and (smallest needed expansion times number of children to expand) d) goto a) if children below natural width remain 2) if extra space still remains, divide it equally among each child with expand=true In other words, children will always grow to their natural width whether they are expand=true or not. Below-natural-size children always grow before expand=true children. Yes I think they are equivalent. Various optimizations are obviously possible here (keep track of flags for whether we have any expandable / any natural!=minimum, for example). The PACK_IF_FITS children are done in a second pass after other children, the if_fits flag indicates which pass this is. If if_fits=TRUE we need to skip if_fits children that did not fit. Interesting. Do you think that will be useful to add to Gtk+? Havoc -- behdad http://behdad.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Nov 20, 2007 10:07 PM, Matthias Clasen [EMAIL PROTECTED] wrote: On Nov 20, 2007 8:45 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: a) Maximize number of children taking their natural size. I am not convinced this is always the best strategy. Doesn't this encourage starving one child in favour of the rest of the pack getting their natural size? Right. We can add another goal to avoid starvation: c) If child i takes its natural size and child j doesn't, child j should have received at least as much gap as child i. The algorithm I sketched satisfies this too. If you really want to be flexible in this, you probably need to go to a TeX-like glue model and assign stretchabilities and shrinkabilities to children. I thought about that. But TeX's model more lends itself to Mathias's current linear distribution than something like what we are discussing now. And the linear model is clearly not the best you can do when you have nonlinearities like ellipsization. What may make sense in this model is a child priority, yes. b) The allocated size of children should be a continuous function of c_gap. That is, increasing the container size by one pixel should never make drastic changes in the distribution. This one I fully agree with. -- behdad http://behdad.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Hi, Behdad Esfahbod wrote: The PACK_IF_FITS children are done in a second pass after other children, the if_fits flag indicates which pass this is. If if_fits=TRUE we need to skip if_fits children that did not fit. Interesting. Do you think that will be useful to add to Gtk+? I think it's a useful feature, basically it allows a box to contain optional children that appear only if there's extra space. It can be a completely separate patch from this whole extended layout thing, of course. (But it depends on having extended layout, since the if-fits child is not included in min size of the box, but is included in natural size of the box.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Nov 21, 2007 5:07 PM, Mathias Hasselmann [EMAIL PROTECTED] wrote: OK, so lets six other years until we get the perfect solution Havoc dreams of in his pipe dreams. Well done. Is that supposed to be a joke or what? You asked for review, Havoc suggested a slight API change that I fully think is right (and should be trivial to adapt your patch to), and I suggested an algorithm change and provided pseudo-code too (this one should be easy to update your patch to too). There was talk about optional children and Havoc suggested that it can wait for later. So what is this message of you supposed to mean? -- behdad http://behdad.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Hi, Mathias Hasselmann wrote: OK, so lets six other years until we get the perfect solution Havoc dreams of in his pipe dreams. I think you misunderstand the intent; you said here's the proposal and I asked some questions and said what about doing it this way You are very welcome to say no, that's wrong because... or that would be too hard because... or my way is better because... - it's a discussion, and clearly you have thought about the issues longer than I have. And I'm not a maintainer anyway, I am just trying to contribute ideas that you and the maintainers are welcome to ignore. I don't *think* anything I brought up is very hard to do, certainly not a pipe dream or 6 year project. But if it is, just explain that. You probably should expect to make *some* changes when posting a patch for review - I'm sure the actual maintainers will have review comments, that's how the process works. The kernel and other major projects are the same way. However, you certainly don't have to make every change anyone brings up on the mailing list, only the ones you or the maintainers consider to be important. So please don't be discouraged. If my ideas are bad then ignore them (or, I always appreciate learning something new so if you take the time to explain what's wrong with the ideas, that's always welcome) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Nov 21, 2007 3:04 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Nov 20, 2007 10:07 PM, Matthias Clasen [EMAIL PROTECTED] wrote: On Nov 20, 2007 8:45 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: a) Maximize number of children taking their natural size. I am not convinced this is always the best strategy. Doesn't this encourage starving one child in favour of the rest of the pack getting their natural size? Right. We can add another goal to avoid starvation: c) If child i takes its natural size and child j doesn't, child j should have received at least as much gap as child i. The algorithm I sketched satisfies this too. Yeah, true. Alternatively: there shall not be both children who receive less than their natural width and children that receive more than their natural width. Anyway, I don't think that the example of bunch of ellipsiizing labels can be generalized to make the case that the hippo-style algorithm is always better than some linear distribution scheme. One thing that I have not seen mentioned in this discussion so far is the fact that it is ultimatively an implementation detail of the container how it distributes its allocation to its children. There is nothing prohibiting a linearly-distributing container and a hippo-style container from coexisting. Both can use the same extended layout interface. It would also be possible to make the distribution algorithm pluggable. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Wed, 2007-11-21 at 22:10 -0500, Matthias Clasen wrote: On Nov 21, 2007 3:04 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Nov 20, 2007 10:07 PM, Matthias Clasen [EMAIL PROTECTED] wrote: On Nov 20, 2007 8:45 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: a) Maximize number of children taking their natural size. I am not convinced this is always the best strategy. Doesn't this encourage starving one child in favour of the rest of the pack getting their natural size? Right. We can add another goal to avoid starvation: c) If child i takes its natural size and child j doesn't, child j should have received at least as much gap as child i. The algorithm I sketched satisfies this too. Yeah, true. Alternatively: there shall not be both children who receive less than their natural width and children that receive more than their natural width. Yes, that part was implied in my discussion. If there is room to give every child its natural size or more, that's what should be done. Anyway, I don't think that the example of bunch of ellipsiizing labels can be generalized to make the case that the hippo-style algorithm is always better than some linear distribution scheme. One thing that I have not seen mentioned in this discussion so far is the fact that it is ultimatively an implementation detail of the container how it distributes its allocation to its children. There is nothing prohibiting a linearly-distributing container and a hippo-style container from coexisting. Both can use the same extended layout interface. It would also be possible to make the distribution algorithm pluggable. Very good point. Matthias -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Extended Layout Summary
GTK+ finally has been branched for the next release cycle, which means that features can be added. So it seems to be a good time to descibe the extended layout patches I've created during this Summer of Code: * http://live.gnome.org/MathiasHasselmann/NewLayoutManager * http://bugzilla.gnome.org/101968 NATURAL SIZE PROBLEM DESCRIPTION --- Widgets have at least two different kinds of size requisition: * the absolutely minimum size they can deal with * the natural size they prefer GTK+ currently only offers one kind of size requisition expressed by the size-request signal. Interpretation of this signal differs among application authors, but also within the toolkit: Sometimes the values returned by the size-request signal are considered the minimum size, sometimes they are considered the preferred size. Just one result of this ambivalence I've seen recently: http://bugzilla.gnome.org/attachment.cgi?id=85309 Left of the combo box there also is a text entry which shows up as white artifact above the s of the word days. The problem here is, that the text entry got some size request assigned to get some reasonable default size - size-request interpreted as natural size. This of course leads to an unreasonable minimum size of the right pane, when disabling the shrink size property of the right pane - size-request used as minimum size. So the shrink property was enabled, leading to this unpleasant result, when reducing the pane's size too much. SOLUTION IDEA - The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. When a container widget got more space allocated than requested, it considers the difference between natural and requested size of its children to distribute that additional space, in relation to the child's difference between natural and minimum-size. Let's use an example for demonstration: Assume we have a container with two children. Both children request a_min = b_min = 50 pixels as minimum size. The first child announces a_nat = 100 pixels, the second announces b_nat = 200 pixels as natural size. This gives a requested size of c_min = 100 pixels, and a natural size of 300 pixels (c_nat) for the container. Now the container gets allocated at a size of 200 pixels (c_cur). This are 100 pixels to distribute (c_gap). So the first child gets: a_cur = a_min + c_gap * (a_nat - a_min) / (c_nat - c_nat) = 50+ 100 * 50 / 200 = 75 pixels. The second child gets: b_cur = b_min + b_gap * (b_nat - b_min) / (c_nat - c_nat) = 50+ 100 * 150 / 200 = 125 pixels. Widgets with expand property only get expanded when the allocated space is larger than the sum of all children's natural size: c_cur c_nat. This definition of natural size introduces a new invariant: natural-size = size-request This invariant should ensure, that size groups keep working, since size groups work by modifying the result of size-request calls. SIZE NEGOTIATION PROBLEM DESCRIPTION --- Over the time it became clear that the widget layout system of the GTK has some deficit. The problems my patches address are: * height-for-width/width-for-height negotiation * expression of natural size Initially I also planed to implement baseline alignments, but that task turned out being too hard to solve for that limited time Summer of Code offered. Height-for-width and width-for-height negotiation becomes necessary when placing for instance wrapping text: Too allocate space for a widget the toolkit has to know the widgets size requisition. For finding that requisition the label needs to wrap its text. For wrapping text the widget has to know much much space it gets allocated. The cat bites its own tail. SOLUTION IDEA - To work around the problem, functions like gtk_label_set_width_chars have been introduced. In a proper solution container widgets are biased whether to layout children horizontally or vertically and accordingly practise width-for-height, or height-for-width negotiation when dis- tributing the space they got allocated. To get size negotiation only small modifications to the layout mechanism of GTK+ are required: Currently we have: * size-request for container: * Sum up size-request results for each visible child. * size-allocate for container: * Distribute space by considering size-request and expand properties of the children. Size negotiation implies: * size-request for container: * Sum up size-request results for each visible child. * size-allocate for container: * Distribute space by considering __size-negotiation__ and expand properties of the children. Use size-request, when
Re: Extended Layout Summary
Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 14:10 +0100 schrieb Vincent Untz: Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) Actually its a good question and answering it should be part of the extended layout docs, I guess. The grouping feature of the window list actually is a fallback strategy, therefore the list should calculate its natural size by accumulating the natural sizes of its children in the ungrouped mode, were as it should accumulate minimum sizes in grouped mode for its own size-request. Well, unless you highly prefer the grouped mode, and see the ungrouped mode as fallback. In that uncertain case you'd also use the grouped mode for calculating natural size. Switching between grouped and ungrouped mode should happen automatically as reaction on the currently allocated size - as it is done already. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Le mardi 20 novembre 2007, à 08:45 -0500, Owen Taylor a écrit : On Tue, 2007-11-20 at 14:10 +0100, Vincent Untz wrote: Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) The natural size of the window list is the ungrouped size. Agree. And the minimum size is the everything is grouped size. But there are some other sizes between the two. There definitely are cases, like a terminal widget (gridded size), where a widget can only handle certain sizes, and is going to have to leave blank space at other sizes. And in fact, even a wrapped label fits that category. But while keeping things simple, understandable, and compatible with GTK+ as it exists now, trying to handle those cases is not feasible. Ok, I'm perfectly fine if the extended layout stuff doesn't handle that case. I was just wondering if it's possible to kill the size hints part of the applet library. Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Le mardi 20 novembre 2007, à 14:32 +0100, Mathias Hasselmann a écrit : Am Dienstag, den 20.11.2007, 14:10 +0100 schrieb Vincent Untz: Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) Actually its a good question and answering it should be part of the extended layout docs, I guess. The grouping feature of the window list actually is a fallback strategy, therefore the list should calculate its natural size by accumulating the natural sizes of its children in the ungrouped mode, were as it should accumulate minimum sizes in grouped mode for its own size-request. Well, unless you highly prefer the grouped mode, and see the ungrouped mode as fallback. In that uncertain case you'd also use the grouped mode for calculating natural size. The issue here is that the current way it works is that you can have more than one natural sizes, depending on the number of groups you can have. Eg: [Epiphany][Epiphany[Epiphany][Terminal][Terminal] can become: [Epiphany ^][Terminal][Terminal] or: [Epiphany ^][Terminal ^] So it's not a bit more complex than having only a minimum size and a natural size. (also, another thing here is that you hide/show some of the children depending on the allocated size) Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Tue, 2007-11-20 at 14:10 +0100, Vincent Untz wrote: Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) The natural size of the window list is the ungrouped size. There definitely are cases, like a terminal widget (gridded size), where a widget can only handle certain sizes, and is going to have to leave blank space at other sizes. And in fact, even a wrapped label fits that category. But while keeping things simple, understandable, and compatible with GTK+ as it exists now, trying to handle those cases is not feasible. (Would you really want, say, the notification area applet to get bigger and smaller as the task list grouped and ungrouped windows?) - Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 14:49 +0100 schrieb Vincent Untz: Le mardi 20 novembre 2007, à 14:32 +0100, Mathias Hasselmann a écrit : Am Dienstag, den 20.11.2007, 14:10 +0100 schrieb Vincent Untz: Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) Actually its a good question and answering it should be part of the extended layout docs, I guess. The grouping feature of the window list actually is a fallback strategy, therefore the list should calculate its natural size by accumulating the natural sizes of its children in the ungrouped mode, were as it should accumulate minimum sizes in grouped mode for its own size-request. Well, unless you highly prefer the grouped mode, and see the ungrouped mode as fallback. In that uncertain case you'd also use the grouped mode for calculating natural size. The issue here is that the current way it works is that you can have more than one natural sizes, No, you have only one natural size. depending on the number of groups you can [Epiphany][Epiphany[Epiphany][Terminal][Terminal] This one. can become: [Epiphany ^][Terminal][Terminal] One fallback strategy. or: [Epiphany ^][Terminal ^] Another one. So it's not a bit more complex than having only a minimum size and a natural size. No, it is simple. Natural Size is the size you ultimatively prefer. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Le mardi 20 novembre 2007, à 15:15 +0100, Mathias Hasselmann a écrit : Am Dienstag, den 20.11.2007, 14:49 +0100 schrieb Vincent Untz: The issue here is that the current way it works is that you can have more than one natural sizes, No, you have only one natural size. Ok, right. But you can still have some other preferred sizes. (or maybe I'm too tired and confused) depending on the number of groups you can [Epiphany][Epiphany[Epiphany][Terminal][Terminal] This one. can become: [Epiphany ^][Terminal][Terminal] One fallback strategy. or: [Epiphany ^][Terminal ^] Another one. Assume the natural width is 500px in the first case, 350px in the second case and 200px in the third case. And the minimum width is 400px, 280px and 150px. In such a situation, it doesn't make much sense to allocate 250px to the window list because it's between the natural size of the third case and the minimum size of the second case. So it's better to only allocate 200px. Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:53 +0100 schrieb Vincent Untz: Assume the natural width is 500px in the first case, 350px in the second case and 200px in the third case. And the minimum width is 400px, 280px and 150px. In such a situation, it doesn't make much sense to allocate 250px to the window list because it's between the natural size of the third case and the minimum size of the second case. So it's better to only allocate 200px. Ok, I see the problem. So maybe natural-size should be renamed to preferred-size? For supporting your feature there should be a separate call: void (*get_supported_sizes) (GtkOrientation orientation, GtkRequisition **sizes, guint *n_sizes); The sizes would be sorted regarding orientation - but guess we should focus on merging what we got first. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Tue, 2007-11-20 at 17:13 +0100, Mathias Hasselmann wrote:
For supporting your feature there should be a separate call:
void (*get_supported_sizes) (GtkOrientation orientation,
GtkRequisition **sizes,
guint *n_sizes);
A couple of points:
1. Don't be hasty abut this.
Consider having a bunch (m) of multiple-natural-sized widgets (each with
n different natural sizes) within a single container. This means that
there are n^m possible natural sizes for the container. You get to a
point where the natural sizes given would almost form a continuum across
all possible values. It gets worse when you consider that the value n
itself is possibly exponential (2 to the power of number of possible
groupings).
What would this extra information do for you? What I mean: how would
your updated decision-making algorithm for boxes look?
2. I think having my buttons a bit wider on the window switcher is a
gain. I'd happily take the extra space. In the case that the wnck
applet gets this space it should use it.
3. Another example worth considering is toolbars. Their minimum size
is the size at which they show the [v] drop-down and nothing else.
Their natural size is obviously showing all of their icons. If they
were to have multiple natural sizes it would be showing 1, 2, 3, 4...
icons.
I guess it's not too uncommon for people to want to stack multiple
toolbars together horizontally (I've witnessed at least 2 people asking
in #gtk+ about this before).
If you share the extra space (above minimum) evenly then you are doing
yourself a disservice. Assume for a moment that each dropdown takes as
much space as a single toolbar button. We want to stack 3 toolbars
together with buttons {a, b, c, d}, {1, 2, 3, 4} and {w, x, y, z}. We
are allocated enough space to show 9 buttons.
Is it better to have:
[a] [b] [V] [1] [2] [V] [w] [x] [V] (3 buttons wasted on dropdowns)
or
[a] [b] [c] [d] [1] [2] [3] [4] [V] (only 1 button wasted)
Note that you cannot solve this with expand or fill flags alone,
because what do you do? Set the left-most widget expand/fill but not
the others? In this case the layout doesn't know to give space to the
second on before the third. If you set all but the very right-most one
expand/fill then the layout doesn't know to give to the leftmost before
the centre one...
Maybe each widget can have some sort of a weight within the container
that specifies the slice of the pie it gets... but even this doesn't
help. Maybe priority so that nobody gets any extra space until
everyone of higher priority has their full natural size?
For things like toolbars, wnck window list and so on, it's very unclear
what the correct thing to do it. You could spend a very long time
thinking about it and still not find an elegant solution. This is
definitely no time to go blindly adding new API. :)
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Le mardi 20 novembre 2007, à 11:55 -0500, Ryan Lortie a écrit : For things like toolbars, wnck window list and so on, it's very unclear what the correct thing to do it. You could spend a very long time thinking about it and still not find an elegant solution. This is definitely no time to go blindly adding new API. :) Agree with Ryan with the no need to rush :-) I was just raising the issue because I never looked at Mathias' work before. It might perfectly make sense to ignore this case and keep a simple API. Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 11:55 -0500 schrieb Ryan Lortie: This is definitely no time to go blindly adding new API. :) True. Very true. -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Hi,
While I haven't looked at the patches in detail, based on your writeup
it feels like the interfaces here will make it a little hard to
implement in widgets.
In HippoCanvas I ended up with this:
void (* get_width_request)(HippoCanvasItem *canvas_item,
int *min_width_p,
int *natural_width_p);
void (* get_height_request) (HippoCanvasItem *canvas_item,
int for_width,
int *min_height_p,
int *natural_height_p);
(this API assumes height-for-width only, of course)
The most important thing here, I originally had separate
get_natural_size and get_min_size. However, I found that often these two
functions were the same, and when not the same, they had significant
logic in common. So to do them separately I ended up creating the same
PangoLayout twice for example, or else having to cache it, and I usually
had to awkwardly factor out a function shared by the two.
Note that I used the term request to mean both min and natural
together, and then used min_size and natural_size for the specific
request components; unfortunately for gtk, request already means
min, so the naming will have to be more confusing. Maybe desired
size or something means both min and natural
What if the API for GTK+ were something like the above, plus a
width-for-height variant, so rename the above two:
get_desired_width(int*,int*)
get_desired_height_for_width(int,int*,int*)
and add:
get_desired_height(int*,int*)
get_desired_width_for_height(int,int*,int*)
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
- the default implementation of size_request
(gtk_widget_real_size_request) is modified to do something like
if (widget has height-for-width feature) {
get_desired_width(widget, min_width, NULL);
get_desired_height_for_width(widget, min_width, min_height,
NULL);
requisition-width = min_width;
requisition-height = min_height;
}
With the above, to write a simple widget you would only have to
implement two functions: get_desired_width() and
get_desired_height_for_width().
The point is, in newly-written widgets ideally there is no need to code
the now-deprecated size_request; and also for most widgets hopefully no
need to implement width-for-height since that's something of a strange case.
There are a bunch of details here in exactly how the default
implementations work, I probably got something wrong.
Another thing I'm not clear on from your mail is the padding stuff;
basically, it looks like every widget implements padding support for
itself. In that case, what's the point of having get_padding in the
generic extended layout interface?
Starting from scratch as in HippoCanvas I think padding/margin/etc.
should be done generically so all widgets automatically have them, and
just as importantly, so no widgets ever have to do padding/margin
calculations in their size request/allocation code. i.e. have the
containers add the padding/margin on behalf of their children.
That's a bit tricky for GTK since there's legacy gunk in the way, but I
think it's the ideal.
The question about this patch though is just, where is the get_padding
call used generically, i.e. when does a widget get the padding for
another widget of unknown type, rather than for itself which has known type.
As a very minor point, I'd make the padding guint16 not guint, which
will save 64 bits per widget; in HippoCanvas I even went for guint8, but
for GTK maybe that is too limiting. (Not that I've ever seen a padding
that was even 64, let alone 256, but...)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Thanks Mathias for the write-up. You didn't get much into the baseline stuff which was the really interesting part about text, but other than that, the rest looks good from that point of view. Comments below: On Tue, 2007-11-20 at 07:23 -0500, Mathias Hasselmann wrote: When a container widget got more space allocated than requested, it considers the difference between natural and requested size of its children to distribute that additional space, in relation to the child's difference between natural and minimum-size. Let's use an example for demonstration: Assume we have a container with two children. Both children request a_min = b_min = 50 pixels as minimum size. The first child announces a_nat = 100 pixels, the second announces b_nat = 200 pixels as natural size. This gives a requested size of c_min = 100 pixels, and a natural size of 300 pixels (c_nat) for the container. Now the container gets allocated at a size of 200 pixels (c_cur). This are 100 pixels to distribute (c_gap). So the first child gets: a_cur = a_min + c_gap * (a_nat - a_min) / (c_nat - c_nat) = 50+ 100 * 50 / 200 = 75 pixels. The second child gets: b_cur = b_min + b_gap * (b_nat - b_min) / (c_nat - c_nat) = 50+ 100 * 150 / 200 = 125 pixels. Something that Ryan brought up, and I was hoping that Havoc answer is that the above algorithm is not optimal, you can easily do better. Quoting Havoc's words: bring smaller items up to natural size first. Read his entire TEXT LAYOUT THAT WORKS PROPERLY? post here: http://log.ometer.com/2006-10.html That, and switching to the API Havoc suggested would mean that Gtk+ will be in par with HippoCanvas which is cool. Cheers, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Tue, 2007-11-20 at 20:09 -0500, Behdad Esfahbod wrote:
On Tue, 2007-11-20 at 07:23 -0500, Mathias Hasselmann wrote:
When a container widget got more space allocated than requested, it
considers the difference between natural and requested size of its
children to distribute that additional space, in relation to the child's
difference between natural and minimum-size. Let's use an example for
demonstration:
Assume we have a container with two children. Both children request
a_min = b_min = 50 pixels as minimum size. The first child announces
a_nat = 100 pixels, the second announces b_nat = 200 pixels as
natural size.
This gives a requested size of c_min = 100 pixels, and a natural
size of 300 pixels (c_nat) for the container. Now the container gets
allocated at a size of 200 pixels (c_cur). This are 100 pixels to
distribute (c_gap).
So the first child gets:
a_cur = a_min + c_gap * (a_nat - a_min) / (c_nat - c_nat)
= 50+ 100 * 50 / 200
= 75 pixels.
The second child gets:
b_cur = b_min + b_gap * (b_nat - b_min) / (c_nat - c_nat)
= 50+ 100 * 150 / 200
= 125 pixels.
Something that Ryan brought up, and I was hoping that Havoc answer is
that the above algorithm is not optimal, you can easily do better.
Quoting Havoc's words: bring smaller items up to natural size first.
Read his entire TEXT LAYOUT THAT WORKS PROPERLY? post here:
http://log.ometer.com/2006-10.html
Without checking HippoCanvas's implementation, I think this is how it
should work:
Say there are n child widgets c^0 .. c^{n-1}, let
c^i_diff = c^i_nat - c^i_min
We want to assign c^i_gap such that the sum of c^i_gap's is equal to
c_gap, the container's extra space to distribute. We only consider the
case that there's not enough space for all children to take their
natural size. The goals we want to achieve:
a) Maximize number of children taking their natural size.
b) The allocated size of children should be a continuous function of
c_gap. That is, increasing the container size by one pixel should never
make drastic changes in the distribution.
Goal a rules your current algorithm out as yours essentially keeps all
children off their natural size until there's enough room for all.
Goal b means that you cannot start from the least child gap, fulfill
them and then distribute the remaining gap between the rest of the
children, because when enough gap becomes available for you to
accommodate one more natural child, the allocations jump
noncontinuously.
This algorithm achieves both goals: Distribute gap to children equally
(not linearly) and not more than they need. That is:
- Sort children with decreasing c^i_diff. Use child order in the
container to break ties.
- Allocate like this:
for (i = n - 1; i = 0; i--)
{
double share = (double) c_gap / (i + 1);
if (share = c^i_diff)
c^i_gap = c^i_diff;
else
c^i_gap = ceil (share);
c_gap -= c^i_gap;
}
Something completely unrelated: now that you are adding extended layout
features, should we switch to doubles or some fixed subpixel format for
size negotiation? The idea being, making it easier to make Gtk+
dpi-independent in the future.
--
behdad
http://behdad.org/
Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin, 1759
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Nov 20, 2007 8:45 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: a) Maximize number of children taking their natural size. I am not convinced this is always the best strategy. Doesn't this encourage starving one child in favour of the rest of the pack getting their natural size ? If you really want to be flexible in this, you probably need to go to a TeX-like glue model and assign stretchabilities and shrinkabilities to children. b) The allocated size of children should be a continuous function of c_gap. That is, increasing the container size by one pixel should never make drastic changes in the distribution. This one I fully agree with. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
On Nov 20, 2007 11:55 AM, Ryan Lortie [EMAIL PROTECTED] wrote: On Tue, 2007-11-20 at 17:13 +0100, Mathias Hasselmann wrote: For supporting your feature there should be a separate call: void (*get_supported_sizes) (GtkOrientation orientation, GtkRequisition **sizes, guint *n_sizes); A couple of points: 1. Don't be hasty abut this. Consider having a bunch (m) of multiple-natural-sized widgets (each with n different natural sizes) within a single container. This means that there are n^m possible natural sizes for the container. You get to a point where the natural sizes given would almost form a continuum across all possible values. It gets worse when you consider that the value n itself is possibly exponential (2 to the power of number of possible groupings). What would this extra information do for you? What I mean: how would your updated decision-making algorithm for boxes look? While you are right that blindly combining all natural sizes of the children leads to the exponential explosion in natural sizes of the container, that would be a pretty stupid strategy for a container to implement. It should certainly be aggressive in pruning the total space by ruling out nonsensical combinations like picking the smallest sizes for all-but-one children, and the largest size for the last child. Allowing such combinations would also lead to noncontinuous resizing behaviour, or at least to counterintuitive resizing behaviour where growing the container may shrink some of the children, while others grow. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
