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
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
[REMINDER] GTK+ Team Meeting on IRC
hi everyone; as you might have seen on the wiki page[0], now that GLib and GTK+ have been branched for development, the (bi-)weekly IRC meetings can restart as well. so, here it is (and sorry for the short notice): date: 2007-11-20 time: 20:00 UTC [1] #gtk-devel on irc.gnome.org meeting points: - GIO/GVFS merge - GSettings status - extended layout interface API ciao, Emmanuele. +++ [0] http://live.gnome.org/GTK+/Meetings [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=20&year=2007&hour=20&min=0&sec=0&p1=0 -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ 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
Monitor and projector hotplug (aka RandR 1.2 support for GTK+)
Hi I have been doing some work on adding RandR 1.2 support to GTK+. There is an initial patch here: http://www.gnome.org/~ssp/randr/gtk.patch The interesting part is perhaps the API: A new signal on GdkScreen: void (*monitors_changed) (GdkScreen *screen); that is emitted whenever the number of attached monitors change. I hope that we can get the X server to actually generate this event on its own whenever a monitor is hotplugged, but if not, then this signal would be emitted whenever the user changed the control panel appropriately. These new calls: gint gdk_screen_get_monitor_width_mm (GdkScreen *screen, gint monitor_num); gint gdk_screen_get_monitor_height_mm (GdkScreen *screen, gint monitor_num); gchar * gdk_screen_get_monitor_plug_name (GdkScreen *screen, gint monitor_num); gchar * gdk_screen_get_monitor_display_name (GdkScreen *screen, gint monitor_num); The "get_monitor_display_name()" would return a UTF-8 string that could be shown to the user. Ie., it might be something like "Sony 21" or "Epson Projector". Comments appreciated. I am especially interested in feedback from people writing applications such as presentation program, that would make use of such external screens as more than just extra screen space. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ Team Meeting on IRC
On Tue, 2007-11-20 at 19:41 +, Emmanuele Bassi wrote: > hi everyone; > > as you might have seen on the wiki page[0], now that GLib and GTK+ have > been branched for development, the (bi-)weekly IRC meetings can restart > as well. English sucks. Is this twice a week, or once every two weeks? ( I had to double check which one it meant, and it can mean either: http://dictionary.cambridge.org/define.asp?key=7805&dict=CALD ) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Monitor and projector hotplug (aka RandR 1.2 support for GTK+)
On Wed, 2007-11-21 at 00:39 +0100, Soeren Sandmann wrote: > Hi > > I have been doing some work on adding RandR 1.2 support to GTK+. There > is an initial patch here: > > http://www.gnome.org/~ssp/randr/gtk.patch Was that based on the patch in the bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=439588 ? If it's an update, could you please post it to the bugzilla as well? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ Team Meeting on IRC
On Tue, 2007-11-20 at 23:47 +, Bastien Nocera wrote: > On Tue, 2007-11-20 at 19:41 +, Emmanuele Bassi wrote: > > hi everyone; > > > > as you might have seen on the wiki page[0], now that GLib and GTK+ have > > been branched for development, the (bi-)weekly IRC meetings can restart > > as well. > > English sucks. Is this twice a week, or once every two weeks? > > ( I had to double check which one it meant, and it can mean either: > http://dictionary.cambridge.org/define.asp?key=7805&dict=CALD ) argh! I knew it! okay: every *other* week. I'll fill out the wiki page with the next dates. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ 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: Monitor and projector hotplug (aka RandR 1.2 support for GTK+)
On 21 Nov 2007 00:39:29 +0100, Soeren Sandmann <[EMAIL PROTECTED]> wrote: > > Comments appreciated. > Looks pretty close to what Pascal and I had worked out earlier in bugzilla, so I'd say it looks fine api wise. The only things that jumped out in the patch were the debug printfs that are still in there and the stubbed out get_display_name(), which probably blocks on finding a home for the EDID parser (or on enough EDID to be exposed as output properties...). 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 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
What's the purpose of gtk_menu_attach_to_widget ?
Hi, What's the purpose of gtk_menu_attach_to_widget ? And is there any bad effect if I create a gtk menu without using this function ? BRs, Baisheng ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
