Re: GtkCanvas requirements?

[Havoc Pennington <hp redhat com>]

Hi,

Kalle Vahlman wrote:
> >         6. I want to make slightly interactive diagrams with a clearly
> > distinctive style from regular gtk widgets, namely i want to draw math
> > plots for later export into articles.  For this kind of content, users
> > don't want their selection of gtk theme to interfere with final content,
> > and the content should have white background and simple colors, none of
> > these gradients and 3d look that widgets have.
>
> This is what I have thought as the main use of a canvas widget. This
> thread indicates that people seem to want a lot more than that though.

Remember we might need multiple solutions to avoid cramming everything 
anyone ever wanted to do into one thing.

 - Document Editor. The "interactive math plot" or "implement inkscape" 
type of use; "writing a document editor widget"

 - More Flexible Widget Kit. For creating UIs like some of the fancy 
control center shells, Mugshot, something like GMail, etc.

 - Animations and Games. The core use-cases for Flash. Note that this 
may imply that the solution is designed first for *visual designers* and 
only second for programmers (as Flash in fact is - ActionScript APIs, 
argh! - but the Flash designer app is pretty nice)

Perhaps a "nested" solution is the right one - that is, think of how 
HTML has Flash and the new <canvas> tag nested inside. Perhaps on the 
outside layer you have a "More Flexible Widget Kit" (or just an 
evolution of GtkWidget), and on the inside layer you have a 
<canvas>/Piccolo/Flash-type canvas with animations, full affine 
transforms, SVG, and even video.

The problem is that there's a good amount of intersection between the 
two. Maybe in the "Animations and Games" canvas you don't usually want 
layout, but it would still be handy sometimes, for example.

So another structure could be that there's a "core" which tries to 
encapsulate the minimum amount of structure for multiple objects to 
negotiate their usage of the screen area and keyboard, and then there 
are objects that layer in more widget-like and more svg/flash-like 
behaviors. Don't know exactly how that would work.

Federico also brings up again the great point that the whole thing 
should perhaps be designed for primarily markup, plus some scripting, 
rather than primarily as a programming API.

Maybe the as-lightweight-as-possible "core" has some ideas like:
 - the whole display is a DOM-like tree, loadable from markup
 - item painting
 - keyboard focus
 - ...

Then add a set of "widget" style items built on the core which have:
 - layout management
 - themes
 - keyboard accelerators/mnemonics
 - ...

And have a set of "SVG" items (could just be SVG embedded in the overall 
markup), used for drawing and animations.

Just brainstorming on how to break down the big picture enough to get a 
handle on it...

Havoc