> -----Original Message-----
> From: James Henstridge [mailto:[EMAIL PROTECTED]]
> Sent: woensdag 19 april 2000 8:27
> To: [EMAIL PROTECTED]
> Subject: Re: New canvas??
>
>
> On Tue, 18 Apr 2000, Alexander Larsson wrote:
>
> > Good idea.
> >
> > As I said, I've been doing some thinking about this some
> time ago (but
> > then I got distracted hacking gradients into libart...). I
> have some ideas
> > and stuff scribbled on a piece of paper here. I thought i
> might type it in
> > to generate some ideas.
> >
> > Stuff to think about when (re)designing the Dia canvas.
> >
> > * Model/View separation. The gnome-canvas does this in a
> totaly different
> > way, there each Gnome-canvas widget is a view of an app-internal
> > model. I'd like both the model and view to be supported by
> the Canvas
> > widget.
I wasn't thinking about this feature the last posting, although it was one of the main
reasons to start DiaCanvas.
<snip>
> > * Should we allow CanvasItems to be GtkWidgets? This would mean
> > subclassing from GtkLayout with all its hocus-pocus mapping
> and unmapping
> > for scrolling. It means that some stuff will be hard to
> implement too,
> > like affine transformations (or just scaling, see below) of generic
> > widgets, or rendering to non-gdk renderers. Another
> problematic thing here
> > is that GtkWidgets generally cannot be displayed at the same time in
> > different views.
>
> I don't know. We should at least aim to make it possible to
> add a Bonobo
> Embeddable to the canvas. I don't know how much adding of
> other widgets
> is used in the GnomeCanvas in cases where multiple views are used.
Can't widgets be rendered to "just another shape", which is an image and then dispayed
on the canvas?
<snip>
> > All strings in UTF-8, font selection using Pango (A must for i18n)
>
> Having good font handling is a must. If Pango isn't yet
> ready, we can use
> gnome-print's GnomeFont stuff in the mean time. It handles
> the variable
> size fonts and metrics problems
the end of the font-trouble (hell I spended a lot of time getting the text
object right!).
<snip>
> We definitely need some way to store some data for each
> canvas item keyed
> to the view (eg. we probably want to save a scaled pixbuf for
> each view),
> which can be thrown away when the view changes.
So buffered information should be stored in the Display...
> We may as well start putting together a bit of code for the new
> canvas. We should put it in a new module on CVS, in case non dia
> developers want to help. I am not sure what to call the new canvas
> objects though. Probably not GtkCanvas at the moment -- use
> some other
> name, and if it gets accepted into gtk+, change the name.
> This is what
> Havoc did with the new text widget for gtk+-1.4 (I think it
> was going by
> the name FrooTkxt).
Might wanna name it DiaCanvas2 ;-). DiaCanvas is mainly dead, so...
> >
> > / Alex
> >
>
> James.
>
Arjan
