Response interspaced
On Sat, 2009-03-28 at 19:44 -0700, Krzysztof Kosiński wrote:
I'm not seeing where changing the I/O system will do any of that. Currently nearly all export options are handled using extension parameters, whereas most of them can be handled in a generic way by modifying the SVG that is passed to the extension before saving. The second item of that could be made orders of magnitude easier with some changes to the IO extension system.
Well... your initial message seemed to make the claim about changing the I/O system to gain things. I believe I agree with you that changing the I/O system will not really do any of that in and of itself.
Currently the Export dialog can export anything. It does not need a new
I/O system to do that.
The Export dialog can only save PNGs, unless something has dramatically changed since I last looked at it. The Save dialog can save anything, but it doesn't have the options present in the Export dialog, like limiting the exported area.
Sorry. There was a bit of English sematic hair-splitting there. I was not saying that the export dialog currently *does* export all types. Just that all the pieces are that that would allow one to do so.
My intent on that point was to emphasize that existing code can be used by the export dialog pretty much as-is. Therefore no new code for just that needs to be done.
What had gone more is that there was design intent to only "export" bitmap and to leave other things separate. That is, there are not limitations in the code base but in the UI designer selecting how to present things.
Oh, and clipboard and drag-n-drop already use the extension mechanism.
The clipboard does, but it's fragile, and it requires saving to temporary files which is clearly suboptimal. That's because the extensions receive filenames instead of streams to save to or read from. Drag and drop uses an entirely different code path in interface.cpp.
There are a few different factors here. One is the use of filenames themselves. At the moment that is due to running items in external processes and using stdout to get results. That makes for a very robust and extensible system, but does place certain limitations on non-ASCII data. (not that it means it can't be done, just that extra care has to be taken in doing so)
To change that, all we need to do is add a simple stdout catcher (adapter pattern) in place of passing the explicit filename. That's a very minor change that would allow for non-file conversion. If one were to switch to GIO on the other hand, the exact same code would be needed and *then* addition GIO conversion would have to be done as a separate additional step.
By the way, I was just asking which idea would be the best, rather than which would be the worst :)
Yes, I know. However to be able to evaluate ideas for the code, it is important to know what factors might be involved. Knowing what to look at can help show which tasks might take what amount of effort, etc.