Re: Widget, drawing and event coordinates
- Date: Tue, 13 Jun 2017 10:05:59 +0200
- From: Timm Bäder <mail@xxxxxxxxxxx>
- Subject: Re: Widget, drawing and event coordinates
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
> 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
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
> get_allocation, which is defined in terms of the parent window - not very
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
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
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