Re: Widget, drawing and event coordinates

[Timm Bäder <mail baedert org>]

On 11.06, Matthias Clasen wrote:
> On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder <mail 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?

Because we pass the content allocation of the widget to size-allocate,
so it can be used to allocate child widgets. Since that is relative to
the widget's content allocation, x/y is 0/0. The parent-relative
allocation is set before the ->size_allocate implementation is called.


> > 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 ?

Yes. Content postion is the widget allocation as returned by
gtk_widget_get_allocation (atm) plus margin,border,padding.

> > 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 ?

Probably, yes.

> > 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) ?

No it doesn't, that's just how it is right now and one of the points to
be discussed. _get_allocation returns the widget allocation relative to
the parent's content allocation.