On Tue, 2004-08-03 at 13:24, David Turner wrote:
This patch provides a new command: "Vacuum unused defs." SVG files can accumulate cruft -- gradients, markers, etc, which aren't in use. I've chosen to make this command manual, because sometimes, you'll want to keep this cruft for later usage. But if you want smaller SVG files, for web usage (or secrecy reasons), you might try this feature.
When I wrote the first version of this patch, I didn't understand the SPObject tree. I think I do now. I'm somewhat baffled that there's no sp_object_get_child_by_tagName function already -- am I just missing it?
No, it's never been needed. I don't actually think it helps in this case either; defs can appear anywhere in the document, not just as children of the root element (plus we may also want to cover certain non-def elements as well).
I think the best thing to do for a first implementation is just to use SP_ROOT(SP_DOCUMENT_ROOT(doc))->defs.
In general, tagName_get isn't necessary either, as you can already do sp_repr_name(SP_OBJECT_REPR(obj)).
In this specific case, I think checking the name is also asking the wrong question ... what you really want to ask is "should this object be collected if it has no SVG references?", not "does this XML name of the element this object is attached to start with 'inkscape:'?".
[ for example, some future inkscape: elements might be collectable, and most of the current ones actually start with sodipodi: anyway ]
I think what I want to do in future is add another value to the orphan collection policy enum, which can indicate this. But for right now I don't think you need to worry about checking it; we don't appear to put any "special" elements in <defs> currently.
If not, it probably belongs in sp-object.cpp, but I didn't want to put it there prematurely.
Yes, I would prefer that any new "methods" be added as real C++ methods. [ note: for SPObject and derivatives, methods cannot yet be virtual, as GObject doesn't cope with vtables, but ordinary methods are OK ]
Other than these things, the patch looks good -- I would just prefer a version that didn't introduce any new APIs.
-mental