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.

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