Re: Widget, drawing and event coordinates

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

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