On Tuesday 30 August 2005 00:46, Ted Gould wrote:
I entirely agree that it is not ideal, but I think that it works with the Inkscape architecture in the near future in a much more reasonable manner.
As I understand it, the final plugin API (which would have been much better for this, obviously) is still to be developed, and the current status is that CDing to the right directory for extension output would only break another feature that isn't yet implemented.
I don't see why a better plugin API couldn't be prioritised over network output, considering that things like NFS can be done at the kernel layer, anyway. If that was done, a temporary extension output fix could be incorporated into the design of the final plugin API, the network output could be fixed, and nothing would have broken in-between.
I'm sorry you feel that way. I hope that you'll considering adding a command line option in your utility to output the sliced html as a single file so that we can include it as an Inkscape extension. I think that, even given the limitations, it would be useful for many users.
Well, the problem is that writing the many image slices is the main point; not generating (X)HTML, so that's not going to work.
I will always choose not overwriting a user's files without notice over a new feature.
Hmm. I've already proposed a low-impact solution that would NOT overwrite user's files, so from my point of view, this isn't a valid argument.
Don't feel like you have to justify your position; it's your app, and you're entitled to develop it your way, so I'm happy to leave it here if you are. On the other hand, though, I see plugins as one of the least capable subsystems in Inkscape right now, so I think it would help to reconsider this.