Re: gtk_widget_draw()

[Jose Gonzalez <jose_ogp juno com>]

Alexander Larsson wrote:

> On Fri, 2010-08-20 at 09:00 -0400, Paul Davis wrote:
> > 
> > What
> > puzzles me is the mental effort that appears to go into avoiding what
> > to me seems like the inevitable conclusion of this evolution:
> > GTK-as-scene-graph. We inherited a very particular mindset from the
> > early X toolkits, and its taking us a very long time to shake off
> > their fundamental model of what a toolkit *is*.
>
> A "new" toolkit would probably this without hesitation. The cause for
> the "mental effort" is that we already have a toolkit with hundreds of
> apps and libraries that use it. We need to have some level of
> compatibility with it, or people are gonna be very pissed. 
>
> Additionally doing such a redesign has a lot more risk. We know the
> strenghts and weaknesses of the current gtk+. A large redesign may seem
> right initially, but show up significant problems after a while, so such
> a project would need a much longer development period where it takes
> shape.
>
> If I were to do something like that I'd keep gtk3 approximately as it
> now takes shape (i.e. cleanup but mostly compatible). Then create a
> completely new toolkit with a different name, based on the gtk stack
> (i.e. cairo, glib, gio, pango, etc). This is kinda what clutter does, ,
> although clutter is not really a full toolkit (no toplevel handling, no
> file dialogs, no printing, no dnd, etc, etc).
>
> I don't think its worth it though. Even when reusing the lower parts of
> the stack we're talking many man-years of work, and I think the "linux
> desktop" could spend that effort better on other things.


  If I may suggest a couple of things here...

  It's not necessary to answer the question of whether gtk "is"
or is-not a 'canvas' (or scene-graph or whatnot). That can vary
widely depending on just what your point of view is, and/or what
the actual internal implementation details are, or how far down
one wants to look.

  What's important is what functionality it could expose via its
public api and how to best implement such efficiently (and for legacy
issues, I suppose you'd want to do so without too much breakage).

  When it comes to the question of the desirability of some notion
of a canvas (or scene-graph if you like), it should be clear that
whatever such a thing might be it's best if it were a local rather
than global construct, ie. it's far more flexible if gtk *had* a
canvas widget than for it to *be* a canvas.

  Now, just what might a useful canvas notion be? Well, I'd suggest
the rather simple one of a gtk container widget which imposes no
constraints on the positioning/geometry of its child widgets. What
further properties it might allow is dependent on what you want
(likely wanted are compositing & transforming of the child widgets, etc).

  Along with such a widget, it might also be useful for gtk to have
various "gfx widgets". These are 'widgetized' versions of whatever
gfx primitives the underlying gfx rendering model has. So for example
with the standard 2d vgfx model you'd have say "line", "rectangle",...
widgets, and of course the generic "path" widget.
  Additionally, a raster-image gfx widget and possibly various kinds
of text related ones might also be desirable.
  Such gfx widgets would likely best be implemented as atomic (leaf-like)
widgets and of course as efficiently as possible.

  Of course one can then use such gfx widgets anywhere within gtk not just
with the canvas widget, and conversely one can have any widget as a child
of the canvas widget not just the 'gfx' ones.

  With just this setup (and what's already been proposed re cairo, etc)
you can get most of the modern, "rich app" functionality that people want.
  Of course one needs more, things like an anim framework, other flexible
layout containers, etc. But apart from implementation details involving
such things as whether or not only top-level widgets should correspond
to display-system windows, or other issues such as new event propagation
schemes, it may not be too great a change.
  Note that this kind of setup exists in some well-known gui toolkits...
in particular in Adobe's new flex4 and MS's wpf/silverlight.

  In any case... just some thoughts.

  All the best,

  Jose.

____________________________________________________________
Notre Dame Certificates
100% Online Programs in Negotiation Leadership and Mgmt. Enroll Today!
http://thirdpartyoffers.juno.com/TGL3141/4c6f1e148dadf7ad776st05duc