Effect that modifies the document properties?
Hello. I'm trying to write an Effect extension that will allow the creation of cover templates for perfect bound books, which involves changing the document properties and adding guides lines to the current document. I have a Ruby script and an .inx file set up correctly, and when I examine the XML output from the script, the SVG that is returned is correct. When this file is written back to stdout at the end of the script, no changes occur within Inkscape. Can Effects modify the document properties and, if they can't, would it be a good idea to add a new type of extension that could?
Thanks,
John
On 10/17/07, John Bintz <jcoswell@...1414...> wrote:
Hello. I'm trying to write an Effect extension that will allow the creation of cover templates for perfect bound books, which involves changing the document properties and adding guides lines to the current document. I have a Ruby script and an .inx file set up correctly, and when I examine the XML output from the script, the SVG that is returned is correct. When this file is written back to stdout at the end of the script, no changes occur within Inkscape.
And if you look into XML editor? are the changes there?
My guess is that things in namedview are simply not reread, because they are not SPObjects and therefore lack the automatic read-from-repr-on-change machinery that SPObjects have. Perhaps you just need to add a hook to recreate namedview object from repr after each effect runs.
On Wed, 2007-10-17 at 23:53 -0300, bulia byak wrote:
On 10/17/07, John Bintz <jcoswell@...1414...> wrote:
Hello. I'm trying to write an Effect extension that will allow the creation of cover templates for perfect bound books, which involves changing the document properties and adding guides lines to the current document. I have a Ruby script and an .inx file set up correctly, and when I examine the XML output from the script, the SVG that is returned is correct. When this file is written back to stdout at the end of the script, no changes occur within Inkscape.
And if you look into XML editor? are the changes there?
My guess is that things in namedview are simply not reread, because they are not SPObjects and therefore lack the automatic read-from-repr-on-change machinery that SPObjects have. Perhaps you just need to add a hook to recreate namedview object from repr after each effect runs.
We're calling 'sp_namedview_update_layers_from_document()' what else needs to be run?
--Ted
On Wed, 17 Oct 2007 23:53:39 -0300, "bulia byak" <buliabyak@...400...> wrote:
And if you look into XML editor? are the changes there?
IIRC they aren't, which is the weird thing. The extension script _is_ correctly emitting the modified document on stdout, as far as I could tell.
-mental
Ted Gould wrote:
On Wed, 2007-10-17 at 23:53 -0300, bulia byak wrote:
On 10/17/07, John Bintz <jcoswell@...1414...> wrote:
Hello. I'm trying to write an Effect extension that will allow the creation of cover templates for perfect bound books, which involves changing the document properties and adding guides lines to the current document. I have a Ruby script and an .inx file set up correctly, and when I examine the XML output from the script, the SVG that is returned is correct. When this file is written back to stdout at the end of the script, no changes occur within Inkscape.
And if you look into XML editor? are the changes there?
My guess is that things in namedview are simply not reread, because they are not SPObjects and therefore lack the automatic read-from-repr-on-change machinery that SPObjects have. Perhaps you just need to add a hook to recreate namedview object from repr after each effect runs.
We're calling 'sp_namedview_update_layers_from_document()' what else needs to be run?
IIRC There used to be a check in the code that explicitly skipped <defs /> and <namedview /> on document reload while using effects. A while back Ted or I removed the <defs /> portion of the clause and this allowed the color effects to work with gradients and altering the color of markers and other things in effects. But we left the <namedview /> check in there.
Aaron Spike
On Thu, 2007-10-18 at 10:01 -0500, Aaron Spike wrote:
IIRC There used to be a check in the code that explicitly skipped <defs /> and <namedview /> on document reload while using effects. A while back Ted or I removed the <defs /> portion of the clause and this allowed the color effects to work with gradients and altering the color of markers and other things in effects. But we left the <namedview /> check in there.
Aaron is entirely right here. I'm not sure why we're avoiding the namedview, but we are. The offending function is:
/src/extension/implementation/script.cpp:copy_doc
Try taking it out and see what happens?
--Ted
Ted Gould said:
On Thu, 2007-10-18 at 10:01 -0500, Aaron Spike wrote:
IIRC There used to be a check in the code that explicitly skipped <defs /> and <namedview /> on document reload while using effects. A while back Ted or I removed the <defs /> portion of the clause and this allowed the color effects to work with gradients and altering the color of markers and other things in effects. But we left the <namedview /> check in there.
Aaron is entirely right here. I'm not sure why we're avoiding the namedview, but we are. The offending function is:
/src/extension/implementation/script.cpp:copy_doc
Try taking it out and see what happens?
Giving the code a quick glance, removing that check should allow the guides to copy over. The only other thing I'll need it to do is copy the width and height attributes from the incoming XML doc root to the new doc root, to allow the document to be resized by the effect. I'll experiment with that code tonight or tomorrow night and see how far I can get with it.
Thanks,
John
On Thu, 2007-10-18 at 09:30 -0700, John Bintz wrote:
Ted Gould said:
Aaron is entirely right here. I'm not sure why we're avoiding the namedview, but we are. The offending function is:
/src/extension/implementation/script.cpp:copy_doc
Try taking it out and see what happens?
Giving the code a quick glance, removing that check should allow the guides to copy over. The only other thing I'll need it to do is copy the width and height attributes from the incoming XML doc root to the new doc root, to allow the document to be resized by the effect. I'll experiment with that code tonight or tomorrow night and see how far I can get with it.
If I remember right, you won't be able to copy over the namedview directly, you'll need to copy some of the components. I think there is something about it being the document itself, stuff that doesn't get reread. It might be easier to pull out the components that you want by having it parse further into the structure.
--Ted
Ted Gould wrote:
If I remember right, you won't be able to copy over the namedview directly, you'll need to copy some of the components. I think there is something about it being the document itself, stuff that doesn't get reread. It might be easier to pull out the components that you want by having it parse further into the structure.
OK, I just made the change. Let me know how well it works for you. One thing I noticed is that, when updating the document dimensions via effect, the dimensions in Document Properties don't get updated.
Thanks,
John
participants (5)
-
Aaron Spike -
bulia byak -
John Bintz -
MenTaLguY -
Ted Gould