Re: GTK+ canvas?
- From: Havoc Pennington <hp redhat com>
- To: Tristan Van Berkom <tristan van berkom gmail com>
- Cc: gtk-devel-list gnome org, "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Subject: Re: GTK+ canvas?
- Date: Wed, 30 Aug 2006 20:36:22 -0400
Tristan Van Berkom wrote:
< Havoc >
My opinion is that the canvas should "replace" the GTK core in a way,
i.e. GtkWidget
becomes a specialized thing you can embed in a canvas.
This obviously makes the canvas into a pretty big project.
Kindof disagree here - I think that in most cases a canvas is needed
when one
leaves the boundries of a simple UI. Core GTK widgets offer standard
tools for
standard proceedures, stock icons, hig complient dialogs and everything is
supposed to be theme friendly. On the other hand, when you want to plot
out an accel
sheet or draw a map with clickable "city" items, or anything at all
visually
specialized - then you are looking at canvas work.
What I mean is that the canvas tends to be more flexible / less
specialized while gtk focuses on displaying something specific
("widgets") - so the natural thing is that the canvas is the "base" or
the "superset" and gtkwidget is the "specialization"
Just like you can have buttons, etc. in an HTML page, but HTML as a
whole is much more free-form.
Luckily; since markup language is already an integral part of gtk+
design, it wouldnt
have to be part of the canvas design at all - canvases and canvas items
should simply
be buildable from thier properties and the GtkBuilder should take care
of it natively.
Quite possibly. Something to keep in mind though is that a builder UI
can be programmer-oriented (Glade) or designer-oriented (Flash), and you
get a really different flavor to apps depending on what this app
encourages. Sort of social engineering through software design or something.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]