I missed an interesting discussion about which objects should be selected after an effect. I started of the opinion that the previous selection should be restored in order to make affecting the same objects again simpler. But someone suggested that the effect should be able to control the selection. That sounds very interesting. How would this be done? Would an effect insert some sort of attribute (like inkscape:select-me="1") into each object that should be selected? This attribute would be discarded by Inkscape on load. Any other solution would likely pass a list of selected ids.
Id collision was one of the first things I wondered about while writing effects. What would happen if I assign a new object an id that is already taken? Inkscape of course fixes it for me. But I have been assigning no id to new objects and letting Inkscape handle the whole thing. This probably isn't a good behavior. And it wouldn't allow for ids to be passed back to Inkscape. What should an effect do to properly handle id assignments?
Aaron Spike
On 6/21/05, aaron@...749... <aaron@...749...> wrote:
I missed an interesting discussion about which objects should be selected after an effect. I started of the opinion that the previous selection should be restored in order to make affecting the same objects again simpler. But someone suggested that the effect should be able to control the selection. That sounds very interesting. How would this be done?
Same as Inkscape gives the effect the ids of objects to process, the effect can return the ids of objects to select. Just output them as a string and let Inkscape read and parse that (I don't know if it's doable, but it sounds straightforward to me).
Id collision was one of the first things I wondered about while writing effects. What would happen if I assign a new object an id that is already taken? Inkscape of course fixes it for me. But I have been assigning no id to new objects and letting Inkscape handle the whole thing. This probably isn't a good behavior.
It is a perfectly good behavior, unless you want to pass back the ids of new objects. In that case, you need to assign them. Just use a namespace approach, e.g. "effect-name:id-number" to avoid clashes.
bulia byak wrote:
On 6/21/05, aaron@...749... <aaron@...749...> wrote:
I missed an interesting discussion about which objects should be selected after an effect. I started of the opinion that the previous selection should be restored in order to make affecting the same objects again simpler. But someone suggested that the effect should be able to control the selection. That sounds very interesting. How would this be done?
Same as Inkscape gives the effect the ids of objects to process, the effect can return the ids of objects to select. Just output them as a string and let Inkscape read and parse that (I don't know if it's doable, but it sounds straightforward to me).
The way it works right now, the effect outputs the modified SVG on STDOUT. Do you suggest sending the ids on STDOUT also?
Id collision was one of the first things I wondered about while writing effects. What would happen if I assign a new object an id that is already taken? Inkscape of course fixes it for me. But I have been assigning no id to new objects and letting Inkscape handle the whole thing. This probably isn't a good behavior.
It is a perfectly good behavior, unless you want to pass back the ids of new objects. In that case, you need to assign them. Just use a namespace approach, e.g. "effect-name:id-number" to avoid clashes.
I was thinking that the effect might have to make a hash of all of the used ids in the file and makes sure it avoids them. Even with a namespace approach, something like that might be necessary to avoid collisions whne the effect is again and again, right?
Not to say that it would be a waste of time, but maybe restoring the previous selection is enough for external effect and the really cool selection behavior could wait for internal effects. The external effect will always be useful for interfacing with external programs, especially those not created speciffically for Inkscape. But I think internal scripting will be a much more fitting and powerful match for most Inkscape specific effect type tasks.
Aaron Spike
Quoting aaron@...749...:
What should an effect do to properly handle id assignments?
Inkscape will add missing ids as needed, and it will be smart enough to avoid collisions when doing so.
It's certainly not a good idea to add ids to EVERYTHING, because ids are not always going to be legal.
Big example: RDF mandates the rdf:ID attribute, the id attribute is illegal, and rdf:ID is not even legal on all RDF elements.
So, be conservative. It IS a good idea to make an effort to carry over ids you were given in the original document, when it's reasonably easy to do so. Otherwise, don't worry about setting ids unless you need to ensure a particular element has a specific id.
-mental
participants (2)
-
unknown＠example.com -
bulia byak