Re: Widget, drawing and event coordinates

[Timm Bäder <mail baedert org>]

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.