Re: rendering-cleanup-next



What's you opinion on having gtk_widget_get_width() and
gtk_widget_get_height() functions? They would just return
widget->priv->allocation.width/height for now.

Such functions would address your issues and would make writing draw
functions pretty much as simple as they are now, without having to
pass width and height. And in particular, they'd get rid of the need
to think about allocations.
Or would that be a too prominent API?

Benjamin


On Sat, Sep 11, 2010 at 5:46 PM, Havoc Pennington <hp pobox com> wrote:
> Hi,
>
> On Sat, Sep 11, 2010 at 11:16 AM, Havoc Pennington <hp pobox com> wrote:
>> I still think passing width, height to draw() is weird.
>
> btw, I guess the argument here (per IRC) is that people might be
> confused by allocation.x,y. But this is a really weak band-aid fix for
> that, which will be wrong in the long term.
>
> The solution to allocation x,y is to set the larger goal: widgets
> don't know their transform (currently GTK only supports translation
> transforms, of course). Widgets should always work in a self-relative
> coordinate system, on the rare weird occasion where they don't, they
> can use gtk_widget_translate_coordinates() which eventually could even
> support rotation and scaling, or there could be a flavor that gives
> you a matrix.
>
> The actual bug is that widget_size_allocate() receives an x,y and
> gtk_widget_get_allocation() gets an x,y. That's where the bug should
> be fixed, not by adding some confusing stuff to draw().
>
> It would take some thought to fix the leakage of x,y on the allocation
> side, but I think that thought is what's needed, rather than band-aid
> pseudo-solutions in draw().
>
> Roughly, the solution could be that:
>
> * size_allocate vfunc and wrapper change to (* size_allocate)
> (GtkWidget, int w, int h)
>
> * add gtk_widget_set_translation(widget,x,y)/get_translation()
>
> * containers now have to call
> gtk_widget_allocate_and_translate(widget, rectangle) convenience
> function instead of size_allocate(). This convenience function
> obviously calls size_allocate(rect.w, rect.h) and
> set_translation(rect.x, rect.y)
>
> This is a pretty breaking change, but porting apps is no harder than
> changing expose-event to draw.
>
> If you want to then be really sick and twisted, once you clear out
> GdkWindow you can support a full cairo_matrix_t instead of just
> translation... which would be logical and straightforward now that
> you've kicked the translation out of the allocation.
>
> Another possible solution is to keep the width,height to draw(), but
> _get rid of size allocate_; widgets would then be supposed to support
> any width,height at any time being passed to draw(), and they'd in
> practice always have to cache their last layout for performance, most
> likely. (they'd sort of make the first part of draw() do what they do
> now in size_allocate(), iff the allocation has changed, and cache the
> result). I don't think this is a very nice solution because it makes
> draw() methods multi-purpose and clunky. I think it's cleaner to have
> separate vfuncs for doing the layout and handling a paint on the
> layout, as GTK already has.
>
> Havoc
>


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