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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
