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]