On Wed, Apr 28, 2010 at 12:59 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
I have now fixed up the docs for GtkContainer and for GtkLabel
width-chars and max-width-chars and fixed the few remaining
regressions that I found.
I've merged this now. Let me know if you spot any regressions.
On Mon, Apr 26, 2010 at 10:55 PM, Tristan Van Berkom t...@gnome.org wrote:
On Mon, Apr 26, 2010 at 6:24 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
On Sun, Apr 25, 2010 at 10:00 PM, Tristan Van Berkom t...@gnome.org wrote:
The effect is as if the frame interpreted xalign as 1-xalign.
I have now fixed up the docs for GtkContainer and for GtkLabel
width-chars and max-width-chars and fixed the few remaining
regressions that I found.
I am pretty happy with what is on the branch now, so if nobody has
further comments, I propose that we merge the native-layout-incubator
branch to
constrains the window size to something
bigger,
the lines dont wrap up so small and leave an upper/lower border.
The real fix for that would be to implement extended layout on GtkFrame
as if it were an hbox with 2 children. It needs to:
- collectively report h4w/w4h of its children
- report
of the text and using that as a size request.
Since the underlined label below constrains the window size to something
bigger,
the lines dont wrap up so small and leave an upper/lower border.
The real fix for that would be to implement extended layout on GtkFrame
as if it were an hbox with 2
On Fri, Apr 23, 2010 at 11:16 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
So far, I have found two things that don't seem to work quite right:
1) In testellipsize, when rotating without any ellipsization, the text
just 'rotates out' of the allocation, whereas in ellipsized modes, the
On Sun, Apr 25, 2010 at 5:08 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
On Fri, Apr 23, 2010 at 11:16 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
So far, I have found two things that don't seem to work quite right:
1) In testellipsize, when rotating without any
On Sun, Apr 25, 2010 at 5:43 PM, Tristan Van Berkom t...@gnome.org wrote:
On Sun, Apr 25, 2010 at 5:08 PM, Matthias Clasen
The intention was to ensure the minimum size in the backwards
request mode. A horizontal label likes to be asked its width but
returns an invented value for the height;
On Sat, Apr 24, 2010 at 5:49 PM, Tristan Van Berkom t...@gnome.org wrote:
As much as I'm tempted to look at this right now, and I really am;
I have to work really hard on something else for at least a month
starting a few days ago. I'm going to try to find some spare time
to look at this but
Good morning,
I've managed to get the base feature set of the native-layout
branch working and in a usable state.
By usable I mean: I've been running Glade on the extended
layout branch for the past week and all of the regressions
I've spotted so far have been fixed, I can also run the
Gimp
Good morning,
I've managed to get the base feature set of the native-layout
branch working and in a usable state.
By usable I mean: I've been running Glade on the extended
layout branch for the past week and all of the regressions
I've spotted so far have been fixed, I can also run the
Gimp
On Mon, 2010-04-12 at 15:16 -0400, Tristan Van Berkom wrote:
- Problem --
There is another problem I cant seem to figure out at this point
and it would be great if someone with prior experience in this area
could explain.
The problem in a phrase is this:
How do
time but may have something to contribute
to the discussion I urge you to skip down to the bottom
where its marked Problem.
I'm also attaching here the new header files defining the
new extended layout apis (as they've changed since last week).
First off one of the changes I made to the api
Hello GTK+ Hackers,
Over the last week I've been working on the extended layout patches[0]
which are sitting in the 'native-layout' branch (the original plan is outlined
in Mathias Hasselmann's blog post[1]).
At this point I'd like to share my findings, plans and uncertainties with the
list
On Thu, 2010-04-08 at 15:50 -0400, Tristan Van Berkom wrote:
Which brings me to the ambiguous case, ClutterActor has a request-mode[3]
property which says an actor may be either height-for-width or
width-for-height.
I still have to investigate what the meaning of that property is, what
use
master).
So, I took a look at this, and tried to port over some of the
container support from the older extended-layout branch (bin, scrolled
window, plug/socket, treeview, cellview, cellrenderertext).
However, things don't quite work, and I think there are some
fundamental issues. E.g. Matthias
. The original extended-layout branch is so far
behind recent development that merging is ends up in a rewrite more or
less and Behdad/Havoc expressed that they don't like the implementation
used.
Hello Johannes,
thank you for your work on this.
I've also update the roadmap with all the new info
Hi Javier!
thank you for your work on this.
I've also update the roadmap with all the new info [1]. Feel free to
improve it if you want ;)
Thanks. I think this is better placed in the 3.0 section as I feel it is
a bit risky to add this in the short 2.20 cycle. This really needs
careful
Hi everybody!
You potentially know that GTK+ has some issues when it comes to
correctly assign space to widgets if the widgets don't have a fixed
size. In 2007, Mathias Hasselmann worked on this issues in a summer of
code project (see the extended-layout branch).
You will find the original
On Mon, Dec 14, 2009 at 10:36 AM, Johannes Schmid j...@jsschmid.de wrote:
thers
Anyway, I am not really the best person when it comes to Gtk+ internals.
But when someone can give me specific advice how the rest should be
implemented I can have a look.
Hey, thanks so much for pushing this
Hi there,
On the roadmap [1] the extended layout work is listed as a possibility
to go in 2.20. I would really like for that to happen. Especially with
the natural size stuff, I would be able to throw out some custom
widget code I needed to add in an application of mine to get that
behaviour
On Thu, 2009-10-22 at 21:19 +0200, Maarten Bosmans wrote:
On the roadmap [1] the extended layout work is listed as a possibility
to go in 2.20. I would really like for that to happen. Especially with
the natural size stuff, I would be able to throw out some custom
widget code I needed to add
This is my first patch, so sorry if I get the submission process wrong.
This patch is meant for extended-layout branch, which hasn't been
merged in a year.
It fixes a number of issues with GtkLabel's extended layout support
which are uncovered by my next patch:
1) the height_for_width
This patch adds extended layout support for GtkViewport. While natural
size support is easy (I would say natural...), adding
height-for-width/width-for-height support requires a new property. The
property, however, is useful even without extended layout support.
The idea is that right now
However, I'm actually thinking of disabling completely
height_for_width/width_for_height for non-wrapping labels (right now
it's accepted for elliipsizing labels), as well as disabling
get_natural_size for wrapping labels. In the meanwhile, this patch
makes things work properly.
Here is
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
On Mon, 2008-01-07 at 16:38 -0500, Mathias Hasselmann wrote:
3) Add some property to GtkSizeGroup to switch between
minimum-size, and natural-size mode? Minimum-size mode is
the
current behavior, in natural-size mode the group would use
the maximum
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
Seems GtkSizeGroup has to be modified to cache and modify natural sizes.
See attached picture for details.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
inline: extended-layout-and-size-groups.png#include
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:
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
{
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
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
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
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
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
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
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
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
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
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
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
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
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
, 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
+ 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
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
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
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
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
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
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
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
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
. 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
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
= (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
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
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,
59 matches
Mail list logo
