On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote: > El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió: > > > I'd step back first and do use-cases instead, and also talk about at a > > high level what the canvas is for and when it would be used, i.e.: > > Havoc is on the right track here. You can pile an immense feature list > on top of the canvas and still get a useless thing. We need use-cases. > > My use-cases for a canvas: > > - Interactive, pre-drawn graphical content which cannot be done with > stock widgets. Think of "using Inkscape instead of Glade"; think of a > poor man's Flash. People want to do this: > > canvas = new Canvas (); > svg = canvas.load_svg ("foo.svg"); > handle = svg.get_object_by_id ("bouncing-ball"); > handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4)); > > - Interactive diagrams, generated programmatically. Think of "the sexy > call-graphs in kcachegrind". A static diagram is trivial, as you can > just draw it with Cairo *once* and BitBlt() it when you need it. An > interactive diagram is harder, since you need event handling, hit > testing, painless redraw, etc. > > - Simple games are already covered by the points above.
Here's some use-cases mentioned on the GooCanvas list: - DTP app (that's what I originally wrote it for). - Multi-track audio editor (currently uses GnomeCanvas). - Genome viewer (currently uses FooCanvas). - Air traffic controller simulator. - Database relationship viewer. - PIM Synchronizer connection viewer. So basically it is all kinds of data visualization and manipulation, and the occasional animation. Plus some WYSIWYG stuff to be printed. > - I think we want to focus on simplicity and heavy use of SVG. > Thousands of programmatically-generated items ("music editor", flyweight > items, etc.) are not very interesting and could complicate the design a > lot. > > - Whoever does a canvas really really really needs to look at > Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/). The animation API is > lovely, and the support for "zoomable UIs" is lovely as well. If we had > Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs > covered. I spent quite a while reading through the Piccolo docs before writing GooCanvas, but I'm afraid I didn't like it that much. The API is horribly complicated: http://www.cs.umd.edu/hcil/piccolo/learn/piccolo/doc-1.2/api/ What was great about the animation API and zoomable UIs? As far as I could see zoomable UIs just meant using different painting code at different scales, which isn't that difficult: http://www.cs.umd.edu/hcil/piccolo/learn/patterns.shtml#Desing% 20Patterns%20for%20ZUI%20Interaces I basically copied what they did for their convenience animation functions, but it didn't work well for rotations so I had to rewrite it. I thought SVG was a much nicer model. > [Side note... at this point I think doing a canvas in C is a big > mistake. Interesting canvases will inevitably get cycles in the pointer > graph, and reference counting becomes just too painful then. [This is > irrelevant to .net or whatever; it's a general We Should Stop Writing > Nontrivial Shit In C thing. People would be really really happy with > the Piccolo.NET API implemented with pygtk or gtk-sharp.]] I don't really agree about the reference counting - noone has reported problems yet. I don't think C is that bad. GLib and GTK+ are a bit painful at times, but hard problems are hard in any language. > The canvas also needs to have performance goals defined up front. We > don't want the case where people avoid using the canvas because it is > too slow (like what happened with the antialiased GnomeCanvas). GooCanvas has a demo that creates 100,000 items over a large canvas. The main problem is startup time of about 5 seconds (creating all the items and measuring text item widths probably). But it works fine after that. Damon _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list