On Tue, Aug 30, 2005 at 05:30:55PM -0700, Ted Gould wrote:
Should the save dialog be a file browser or a directory browser? Or both? I can't think of a way to do this intuitively, or similar to other applications, where one can select either a directory or a file. They have different semantics of things like double clicking and how you'd specify creating a new directory.
We could make it different based on which output format is selected. Well yeah, but what if the user has it as "selected from extension"? Disable the directory ones? How does that work? Changing the file format changes how the filename chooser dialog works?
So, the user interface issues get figured out... what happens on conflicts? If all the files require overwriting, that's a pretty simple case. What about one? What if two, is one so important that all the others should be cleaned up if it isn't written? Should we only allow saving into clean directories?
How should this work as a script? If files aren't passed through the pipe, what is? Is it a zip file that has all the files in it, or a list of file names in some temporary storage area? But, since this is all different, it will probably require a new extension type. Not a huge deal, but also non-trivial.
Yes, none of this is unsolvable, but it is a significantly different use model than all of these constructs were designed for. There are also significant concerns here that haven't been widely addressed. I see no solution in the short term.
I would think that a final solution would involve a "Export to Directory..." type menu item. Where a dialog that is better suited for multi-file output would come up. The a special extension type can be designed to handle these issues. The special cases listed above can be handles in a consistent way. I don't currently have any plans to work on this. I have too much on my plate as it is.
Okay, so what you're saying is that a) there are a lot of misc. technical issues to sort out, b) they're probably solveable, but c) you don't personally have the time to work on it.
It sounds to me that this is the classic situation where much good could be done by simply encouraging someone else to "send in a patch". By simply itemizing what the issues are, as you've done nicely above, then all you need is some suitably motivated developer (like Lee maybe?) who could start banging on solving the issues. Even if that person cannot do it, they may be able to make enough forward progress that someone else could.
I'm reminded about how we did not have OSX packages when Inkscape first started, and there were a whole host of technical issues hindering us, many of which weren't in our control. Hardly any developers had Windows systems, let alone a Mac. The first few people who attempted to do OSX packages did not have success and got quite frustrated. Yet each person that attempted it nudged the ball forward a little bit for the next guy, and today, while I don't know if we can call it solved, it's usable on OSX.
Anyway, in the spirit of "patch first, discuss later", perhaps you could have Lee add his code in and then you can focus on the specific implementational issues where you see there may be better ways of doing things. I think you two can come up with a pretty brilliant feature if you work together on it.
I agree, I think that adding where it saves as a single compressed file is a good start. Figuring out how to do it so that it is more useful and works within Inkscape can come in the future.
Now that you've itemized the issues, why not let Lee have a shot at coming up with his own approach for solving them? It sounds like the single compressed file approach would not be suitable for his needs, so if he can come up with a patch that addresses a fair number of the issues, it would get us fairly far along.
Bryce