Re: GTK+ canvas?

Havoc Pennington wrote:

Gustavo J. A. M. Carneiro wrote:

Thanks Havoc for sharing that wealth of notes with us !

I didnt really look deeply into any of these implementations and I'm not commenting
on them per se, but will happily share my thoughts with you :-)

 < Havoc >
I think an important thing to keep in mind is that a canvas is just an alternate widget system. You can think of it as a GUI toolkit with different tradeoffs from GtkWidget, or a GUI toolkit with some of the misfeatures/limitations of GtkWidget corrected. But in any case it is basically defining the same thing as gtkwidget.c,
 gtkcontainer.c and other core GTK classes.

Yes, I think having it all mixable is also a big priority, a notable advantage of GnomeCanvas is the fact that it can easily blend with normal widgets, it derives from
GtkContainer - allowing you to add widgets and canvas items.

 < 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.

     < Havoc >
     so having a markup language
     as an integral part of a canvas design is of interest.

   < Gustavo >
   Markup in the text item sounds fine.  Anything else sounds like
   reinventing HTML.

 < Havoc >
 Is Glade reinventing HTML? ;-)

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.

/me actively discourages yet another seperate builder mechanism in gtk+


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