On 11.06, Matthias Clasen wrote: > 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?
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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list