bulia byak wrote:
Jon,
what is this new icon preview dialog? Is it temporary?
I mentioned it in a mail I sent out on the 7th at about 1:38 am
I think it needs to hang around. Might need to get the functionality tuned up and perhaps moved around, but in general 'previews' are going to be needed more for animation, SVG Tiny, etc. Not sure the best name for things, but we have a little time to work things out.
On Tue, 2005-03-08 at 19:47 -0800, Jon A. Cruz wrote:
bulia byak wrote:
Jon,
what is this new icon preview dialog? Is it temporary?
I mentioned it in a mail I sent out on the 7th at about 1:38 am
I think it needs to hang around. Might need to get the functionality tuned up and perhaps moved around, but in general 'previews' are going to be needed more for animation, SVG Tiny, etc. Not sure the best name for things, but we have a little time to work things out.
To me this has a great potential. I prefer this space-saving floating dock to a full blown new canvas view. Instant update would be neat though. *blink*, *blink*. :)
cheers
Jakub Steiner wrote:
To me this has a great potential. I prefer this space-saving floating dock to a full blown new canvas view. Instant update would be neat though. *blink*, *blink*. :)
Glad it's looking helpful. Yes, I agree. Some sort of auto-update would be good. But then that takes adding some more code. :-)
I'll see what shakes out. Also I'll probably add a side-by-side with librsvg output. That's a little tricky when only looking at part of a document, but simple when the whole document is the icon. Hmmm... might need a pop-up list to pick which document it show.
mental@...3... wrote:
You'd probably want to embed a bare SPSVGViewWidget. Live updates through the magic of MVC.
Except that it's not a live view of the same tree. Not exactly anyway.
Instead it's an alternate rendering that comes through an entirely different code path. When Inkscape loads it's SVG icons, it goes through a strange separate codepath that renders things differently. The icon view is not really a view on the same document, but a different rendering of it. Of course, at one level that could be considered the same thing, but on another it's different.
Same goes for animation. It's not going to be a separate View on the same live tree Model, but a View based on a slave Model that is sporadically updated.
This is also a new concept for Inkscape, so I was thinking it would take some time to hammer out. New paradigm and all. But we'll need it for some of the things we're slated to add down the road.
Quoting "Jon A. Cruz" <jon@...18...>:
Except that it's not a live view of the same tree. Not exactly anyway.
Instead it's an alternate rendering that comes through an entirely different code path.
Right, we need to unify the codepaths.
When Inkscape loads it's SVG icons, it goes through a strange separate codepath that renders things differently. The icon view is not really a view on the same document, but a different rendering of it. Of course, at one level that could be considered the same thing, but on another it's different.
We have too many sections of the code that are "the same, only different" already. :P
Factor out and unify the "same" parts.
Same goes for animation. It's not going to be a separate View on the same live tree Model, but a View based on a slave Model that is sporadically updated.
Shouldn't the master and slave models still present the same interface, though?
You can't get a useful animation preview without cloning the entire document down to the XML::Node level anyway, at least if we're talking about DOM-based animation.
Declarative animation, yes, we should be able to manage that from the SPObject level.
-mental
participants (4)
-
unknown＠example.com -
bulia byak -
Jakub Steiner -
Jon A. Cruz