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 <digitalfreak@xxxxxxxxxxxxxxxxx> wrote:
> Hi,
>
>> 1-06-2015 21:01 Pierre Wieser <pwieser@xxxxxxxxxxxx> 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.
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.
--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
