On 9/19/06, Damon Chaplin <[EMAIL PROTECTED]> wrote:
I agree with the analysis. I have no good ideas on how to avoid the problem other then designing two different API though.
I'm not sure (2) is an absolute requirement for (B). Widgets are going to look somewhat ugly and I'm not sure they are flexible enough to be used in a canvas based UI. I think having an editable text canvas item would cover most of the use cases.
Also I think some sort of layout support is a requirement for (B).
Thanks,
Marco
So how are we going to decide on a list of requirements for a canvas?
I think there seem to be two main use cases:
A) DTP/Graphics apps that want a canvas for the main document.
(A model/view split, device-independent layout, zooming & printing
are important here.)
B) Flashy user interfaces.
(Support for embedded widgets is useful here.)
Can we even agree on 2 fundamental requirements:
1) Should the canvas & items have a model/view split?
- It is very useful for (A) above but makes (B) awkward.
I agree with the analysis. I have no good ideas on how to avoid the problem other then designing two different API though.
2) Should it support embedded widgets?
- Useful for (B) but will probably always have limitations
(either you can't stack items like in GnomeCanvas, or you can't
zoom or transform widgets, or you can't print widgets).
It is also difficult to fit into a model/view architecture.
I'm not sure (2) is an absolute requirement for (B). Widgets are going to look somewhat ugly and I'm not sure they are flexible enough to be used in a canvas based UI. I think having an editable text canvas item would cover most of the use cases.
Also I think some sort of layout support is a requirement for (B).
Thanks,
Marco
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list