Qua, 2006-08-30 às 16:17 -0400, Havoc Pennington escreveu: > Hi, > > I posted some sort of blue-sky canvas ideas a year ago: > http://mail.gnome.org/archives/gtk-devel-list/2005-August/msg00067.html > > > Since then I've learned HTML/CSS much more thoroughly and also used > Flash a bit. And in the last week needed to write a canvas in 2-3 days > to use for Mugshot. Which is maybe interesting as a case study - "if you > had to strongly prioritize features since you only have 2-3 days, what > would be really important for a real-world application" > > The code is here: > http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-item.c > http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas.c > http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-box.c > http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-text.c > > Remember, written in a few days for a single app; not intended to become > a maintained library API. The HippoCanvasBox is the base class for all > the items, i.e. all items are containers.
It seems this HippoCanvas has no model-view split, yet I remember you designed GtkTextBuffer/View with model/view. Do you consider model-view unimportant, or simply just got "prioritized away"? IMHO, and from experience with coding in GooCanvas, dealing with model-view split adds much complexity with very little gain. How often do you see or use e.g. the model-view split of GtkTextBuffer being used by an application? And doing layout with MVC is cumbersome; e.g. in case of GooCanvas, doing layout with text items is hard and weird: you store the position in the model, but you need the view in order to get the size that item; but from the moment you need the view for anything, which view do you choose? Effectively you lose the model-view separation... but you just have to get the job done, so you eventually stop caring about model-view. In any case, it's still possible to do multiple views on top of a single-view canvas, even if it wastes more memory. However, I would argue that to display a very large document in a canvas creating a canvas item for each document item is not the best solution; I'd rather have a pool, or cache, of visible canvas items, and just reconfigure them on the fly to show the portion of the document currently visible. > > Thoughts since last "canvas notes" > === > > - I think an important thing to keep in mind is that a canvas is just an > alternate widget system. Yeah, kind of agree. > - Along the same lines you can also think of a canvas as an alternative > to Flash or HTML/CSS, two systems many programmers will be familiar with. Don't agree so much. I would say that an HTML widget could be built on top of a canvas, but a canvas IMHO should be something lower level than HTML (can't comment about Flash). > - This poses a huge question for a canvas in GTK, namely, how much does > it overlap widgets; if I'm writing an app, when do I use the canvas vs. > widgets; exactly what is the scope of a canvas project; etc. There is some overlap. A canvas system, if done right, could lay the foundation for a next-generation widget system. > - 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. Sounds an interesting idea... > > - In fact a useful bit of discipline might be that gtkwidget.h does not > get #include'd by the canvas item implementations. (except the canvas > item that embeds a widget) > > Notes on how the Mugshot canvas worked out so far > === > [...] > - canvas items always see only their own coordinates (what gnomecanvas > called "item coordinates"), this removes a _lot_ of confusion that > GnomeCanvas had - unlike GtkAllocation, this means the canvas item only > needs to store its allocated size, not its allocated origin. Cairo makes > this possible since drawing doesn't require converting to drawable > coords (the cairo_t can have its translation matrix already set up) It works this way in GooCanvas. > - GnomeCanvas wouldn't have helped much if at all with cleaning up > hippo-bubble.c, because the disaster is all the custom layout code. So, > the canvas should support layout. GooCanvas doesn't have layout yet, but Damon mentioned some plans about this. > - I think making CanvasItem an interface worked very well, I haven't > looked at GooCanvas but I see its website says it does the same. It's true. Item and ItemView are two interfaces. > - the image item is able to tile, which is a common way to draw e.g. the > edge of a box in html So true. > - typing in C is definitely worse than HTML Try Python! ;-) > , so having a markup language > as an integral part of a canvas design is of interest. Markup in the text item sounds fine. Anything else sounds like reinventing HTML. > I think the biggest question about a canvas in gtk in my mind really is > this thing about "how far to go" - how do you define the thing, both in > absolute terms, and relative to the core gtkwidget/gtkcontainer stuff. IMHO a canvas in gtk+ should not go too far. I'm not saying an HTML widget would not be good to have in gtk+, but HTML/CSS and canvas are two separate things; HTML/CSS can be built on top of a canvas, in principle. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list