On 06/03/2015 04:38 PM, Emmanuele Bassi wrote:
> Hi;
>
> 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 <digitalfr...@lingonborough.com>
> wrote:
>> Hi,
>>
>>> 1-06-2015 21:01 Pierre Wieser <pwie...@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
> applicable.
>
> 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:
>> https://bugzilla.gnome.org/show_bug.cgi?id=745317
>> 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
itself?
>
> 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.
>
> Ciao,
> Emmanuele.
>
Thanks,
Niels
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
