On Sat, 2007-04-21 at 22:12 +0300, Kalle Vahlman wrote:
> 2007/4/21, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>:
> > I can tell you the reasons why I usually use a canvas:
> >
> > 1. Writing widgets is _very hard_ (when compared to e.g. canvas
> > items).
>
> Depends on your language (and on your widget of course). In python,
> deriving a widget not a big deal. In C, well I guess you need to grasp
> some concepts but it's hardly rocket sience.
>
Ahem,
yes, writing widgets is very hard - not because of language
orientation but because of the long history of gtk+ - interestingly
I've been away for a week since my internet is down and I see there's
been alot of discussion on the lists... interesting points I've
seen:
Havoc pointed out that - if we were to view the canvas as a completely
alternative widget system core, we would have the oportunity of having
something lightweight (A gtk+ 3.0 without gtk+ 3.0 I think he said);
this idea is very attractive at first sight... but be warned - in my
limited experience - I've found that (in this corporation where I work),
they went and trashed all the work that we did for 4 years to start a
"new generation" that; in the eyes of the salesmen would solve all of
our problems, in the end it was a huge game of appearences and worked
out well to gain investments for the company etc... but from a developer
point of view it was a big waste of time - we were already on our way
to a huge refactoring phase that would have allowed us to reposition
ourselves for future needs without trashing everything that was already
written and was already good (this was already going to be a huge cost,
but not nearly as huge as the "new generation" route)... sorry for the
long winded analogy but it just goes to say that a technically complex
problem requires alot of thought and we shouldnt shy away from trying
to understand the code that people have written 5 years ago and improve
upon it/refactor it.
Another (Clemens Eisserer) in a seperate thread[1] pointed out an
interesting way that things could be improved in gtk+, optimizing
backbuffering etc, hell from my point of view; GtkWidgets could
probably be simplified if the resource management (GdkWindow allocations
etc for every damn widget that must support GTK_NO_WINDOW cases or
not etc etc) were just deffered out of the typical GtkWidget context.
Thats why I'm replying to THIS mail in the thread, GtkWidget's are
complex and difficult to write because of the requirements that they
meet, this doesnt mean we must sadly lose all hope in them and write
something new for the sake of something new just because nobody has
the balls to go and refactor the core, Clemens has balls and for
that I salute him :)
Canvases... thats right this thread is about canvases... canvases
historically have been something great for highly customized application
environments, but there are so very many applications that need widgets,
just basic building blocks, a button here, a slider there, a nicely
resizing container - and there you have a simple GUI tool frontend for
your typical unix CLI program that is essential to your system.
I think its clear we need canvases, and we need all the themable
goodness that works out of the box that is gtk+ as well, personally
I dont think those two things go in the same boat.
A good day to you all,
-Tristan
[1]http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00074.html
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
