Widget, drawing and event coordinates

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Widget, drawing and event coordinates

Timm Bäder
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.
When drawing a widget, we first offset to the widget's content
allocation and then call its snapshot implementation. 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].

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.

The question is now: does this all make sense or should we go another
way? One thing I would find useful (I haven't tried it though...) is to
also exclude css margins from the widget allocation, just like we do
with widget margins currently.




[1] See also https://mail.gnome.org/archives/gtk-devel-list/2017-May/msg00034.html
[2] I modified tests/testwidgetfocus to showcase this
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Widget, drawing and event coordinates

Matthias Clasen-2
On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Widget, drawing and event coordinates

Timm Bäder
On 11.06, Matthias Clasen wrote:

> On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Widget, drawing and event coordinates

Matthias Clasen-2
Trying to summarize an irc discussion on this topic:

We generally agreed that the content area should be what all vfuncs (measure,
size_allocate, snapshot), events and signal handlers operate in.

The other size that is relevant for widgets is the 'outer' size including the content size,
css padding, border and margin, and any extra space that the widget might be allocated.

Widgets need the content size of themeselves, and the outer size of their children.

We should introduce new getters for content size and outer size, and phase out
get_allocation, which is defined in terms of the parent window - not very useful
anymore.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Widget, drawing and event coordinates

Timm Bäder
On 12.06, Matthias Clasen wrote:

> Trying to summarize an irc discussion on this topic:
>
> We generally agreed that the content area should be what all vfuncs
> (measure,
> size_allocate, snapshot), events and signal handlers operate in.
>
> The other size that is relevant for widgets is the 'outer' size including
> the content size,
> css padding, border and margin, and any extra space that the widget might
> be allocated.

I don't think this is exactly what Benjamin meant, i.e. we already have
that with gtk_widget_get_allocated_size.

> Widgets need the content size of themeselves, and the outer size of their
> children.

Why does "outer size" include css margins? I don't think they are ever
relevant for anything, just like widget margins never really are.
gtk_widget_size_allocate_with_baseline could simply remove those from
the widget size just like it does with widget margins. that way we could
position popovers for buttons in headerbars properly...

> We should introduce new getters for content size and outer size, and phase
> out
> get_allocation, which is defined in terms of the parent window - not very
> useful
> anymore.

get_allocation can return whatever we want of course, and in
wip/baedert/drawing, those coordinates are not relative to the parent
window, but to the parent widget's content allocation.

Anyway, the new API would e.g. be

1) gtk_widget_get_outer_allocation that returns the size of the
   widget's content allocation plus CSS padding and border (not margin
   IMO). the x/y returned are relative to the parent widget's content
   allocation.
   This way, the returned allocation can directly be used to e.g. check
   if the given coordinates in a gesture handler are inside a (direct)
   child widget's border allocation (so use the current gadget
   terminology).

2) gtk_widget_get_some_allocation which returns the widget's content
   allocation, relative to it's...? To what? Ideally this should cover
   the "is the current coordinate that I got from a gesture handler even
   inside this widget's border allocation" use case, so the returned
   allocation should be relative to the widget's own content allocation
   and return negative x/y values.

That all being said, GdkWindows won't just go away like that, we still
need them for popovers and toplevel windows at least. And popovers can
contain other popovers... so gtk_widget_translate_coordinates will have
to handle that. Does anything enforce those windows to influence widget
coordinates in any way? I've so far just encountered that having a O(1)
and very-fast way of getting window-relative widget coordinates is
handy for drawing invalidation.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list