Re: Undeprecate GtkAlignment ?

On 06/03/2015 04:38 PM, Emmanuele Bassi wrote:

once again, you should send this email to gtk-devel-list, not to
gtk-list. No GTK developer (except me, I think) follows gtk-list.

On 3 June 2015 at 23:10, Rafał Lużyński <digitalfreak lingonborough com> wrote:

1-06-2015  21:01 Pierre Wieser <pwieser trychlos org> wrote:
Would it be possible to envisage undeprecation of GtkAlignment widget ?

I support this for other reasons:

1. The current documentation of GtkAlignment says that its xalign and
   yalign properties can be replaced by halign and valign properties
   of GtkWidget. This is not quite true because xalign and yalign properties
   could have any gfloat value from 0 to 1 while halign and valign can
   be only GTK_ALIGN_START (corresponding to 0), GTK_ALIGN_END (corresponding
   to 1.0), GTK_ALIGN_CENTER (corresponding to 0.5) and of course
   GTK_ALIGN_FILL and GTK_ALIGN_BASELINE (which are not interesting in
   this context). There is no way to replace other values of xalign/yalign,
   like 0.25 or 0.33333.

Personally, I think that fractional alignments are most always wrong.
They are just a fancy way to have pixel-precise alignment ("I have
this widget that is 200px and I want its child to be 120px, let's
align it to 0.4), which is not a good way to deal with the boxes model
used by GTK+ — even if it's something that seems to be common from
developers coming from the Windows world.

If you really, really want to position widgets yourself, then using a
GtkFixed or a GtkLayout is probably a better option.

Another option would be to write a constraint-based layout manager,
but that's kind of complicated.

2. GtkAlignment had the xscale and yscale properties which could be used to
   make the child fill a specified fraction (or percentage) of its parent.

That's not going to work really well with the layout management system
employed by GTK. I mean: it *seems* to work, if you constrain your
layout to a specific subset of use cases, but it's not generally

Layout management in GTK flows from child to parent for size
requisition, and from parent to child for size allocation; this means
that a child cannot request a fraction of the size of its parent
because the size of the parent depends on the size of its children.
Using percentages would only work if the parent was absolutely sized,
or the size negotiation was fairly more complicated.

Some time ago we have discussed this on IRC and eventually filed the bug:
As you can see undeprecation of GtkAlignment would be helpful for us.
Alternatively a new container could be developed but some of its features
would actually be the same as of GtkAlignment.

About that bug. I included some language mentioning functionality
similar to GtkAlignment because I thought that it might fit with my main
idea. I'm still interested in feedback about adding a convenience
container that would allow preferred sizes to be "set" without
overriding GtkWidget disregarding any discussions about GtkAlignment
like functionality.

I am wondering if losing GtkAlignment is a feature regression. What if I
have some code that uses GtkAlignment that is using fractional "xalign"
and "yalign" values or xscale and yscale values other than 1? If I port
to a later Gtk version that removes GtkAlignment how would I keep the
layout of my widgets the same? Could it be done without changes to Gtk

No, it wouldn't be at all like GtkAlignment, except (maybe) in the
API. It would require a fair chunk of rewrite, and possibly a bunch of
(ABI-incompatible) changes to how GTK works, to avoid breakage.

My strong inclination is to tell you to write such a layout manager,
and then propose it for inclusion (assuming more than one application
uses it); this would at least give everybody an idea of the
constraints for such a layout manager.

To be fair, it's high time people started writing their layout
managers as well, instead of just having GTK provide them; this way,
if they get included inside GTK, we'll all have a good grasp on their
use, scope, and constraints, before committing to API stability.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]