On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder <m...@baedert.org> wrote:
> The goal here is to unify the coordinate systems we use for events,
> drawing and size allocation.
>
> Widget coordinates definitely should be relative to the parent
> allocation in some sense, so we can move subtrees around without
> re-allocating every single widget in it.
>
> In master, all event coordinates are relative to the widget allocation,
> which excludes widget margins, but includes css margin/border/padding.
>
> In wip/baedert/drawing[1], currently widget allocations are relative to
> the parent content allocation, which means the size_allocate
> implementations get an allocation of
> {0, 0, content_allocation_width, content_allocation_height} passed.
>
Not sure i follow here. If it is relative to the parent, why would x/y by 0?
> When drawing a widget, we first offset to the widget's content
> allocation and then call its snapshot implementation.
Can we define a few terms here ? I would like to make sure we all have
the same understanding of 'content', for example.
Do we use this https://www.w3.org/TR/CSS2/box.html as reference ?
As for input, the
> events get routed to a widget if the (toplevel relative) coordinates
> are inside the widget's margin allocation (widget allocation excluding
> the css margins as well). The coordinates the gestures (or
> gdk_event_get_coords) report however, are relative to that widget's
> content allocation, i.e. the values will be negative inside the widget's
> padding and border[1].
>
I don't think there is any problem with negative coordinates, apart from
not being used this happening ?
>
> So using the content allocation in size_allocate and snapshot
> implementations makes IMO perfect sense. One problem now is that
> gtk_widget_get_allocation (and the still private get_margin_allocation,
> get_content_allocation and get_border_allocation) are not relative to
> the widget's content allocation but to the parent's (since that's the
> coordinate space passed to gtk_widget_size_allocate_with_baseline).
> Changing this would however mean that gtk_widget_get_allocation can
> also return negative x/y coordinates.
>
How so ? Doesn't it return the content allocation, which you said earlier is
(0, 0, allocated-width, allocated-height) ?
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
