On Dec 31, 2009, at 1:56 AM, Krzysztof Kosiński wrote:
I also note that "Command-line invoking functionality" is ambiguous. If this relates to scripting Inkscape, then that would be covered by DBus bindings and a convenience Python library that uses them. If it's about export options accessible from the command line, then the internal API could trivially be used to implement them.
I think a common problem we have in many places is that useful functionality is hidden in obscure functions with poorly defined interface, because whoever wrote them didn't have the courage to modify core classes, and instead tucked away his code in his own file. (I was severely affected by this when redoing the clipboard.) For example, resizing the page, pasting one SVG document into another, and removing unused defs and other invisible objects should all be methods of SPDocument.
Not really.
I think one of the things causing you difficulties (aside from those in the current implementation itself) is from missing the concepts of encapsulation and modularity.
Although, yes, many functions might be more appropriately moved to methods on classes (that's a lingering C to C++ migration issue) there are some things that should be kept to an API.
The verbs system was intended for that purpose, and should really just be tuned to work better instead of being thrown out completely.
Also, the clipboard was severely broken in the recent refactorings. We probably need to revisit that as a first step. That gives a good chance for us to restore some of the modularity, remove some of the rogue tile bug patterns and get things moving forward.
Oh, and in the long run, remember that it has been a goal for a while now to expose things to scripting languages via a live DOM interface. The initial DBus work did not have time in just the summer of code to fully move to that, but that was stated as a follow-up refactoring.