On 07-Mar-2013 15:41, Johan Engelen wrote:
I don't think there is anything wrong/superfluous with the functionality of the current state, there is only functionality missing.
Agreed. Obviously I do not think we need Export at all. However, there are things missing from "save as" which in many instances would be very helpful. By going this route we could also eliminate the snapshot "export" entry from the file menu.
"Save as" would have these extra options:
1. Objects: all, selected, !selected. 2. Layers: all, current, !current, list: [list of layers] 3. On save: overwrite, create higher numbered version 4. Region: all, drawing, area: [xul,yul xlr,ylr] 5. Formats: all, lossy, lossless
The default would be as now: all, all, overwite, all, all. These options might be kept hidden in the default "Save as", with a "more options button" that to expand the menu, but any that were not at the program default must be shown.
1. Explanation - self evident. I don't think a list of objects here would be very helpful, as the number of objects typically saved is so large. If an object is to be saved anything in <defs> that it needs would also be saved.
2. Layers - mostly self evident. This is almost perfectly analogous to the page print options in most print drivers. One issue would be that layers can have any name, so listing them by name would be a lot of typing. A good solution to that would be to allow them to be listed by index number (1 to N I think, not 0 to N-1). The indices don't need to be static through the session, and they should also be shown in the layers dialog, perhaps between the eye and lock symbols. A list like "2,5,7-10,13" should be allowed.
3. On save - implements a simple data protection scheme. Overwrite is what Inkscape does now, and it is certainly capable of amplifying an end user's mistakes. The "create higher numbered version" option would be a little tricky because our target platforms do not normally have file version support enabled. One way to do it here if file numbering was enabled would be:
open test.svg (no numbered versions present) work... save (copy test.svg -> test.svg.0, save as test.svg) work... save (copy test.svg -> test.svg.1, save as test.svg) save (do nothing, there have been no changes) work... save (copy test.svg -> test.svg.2, save as test.svg) exit (if no changes since the last change, do nothing. otherwise: copy test.svg -> test.svg.3, save as test.svg)
In other words, the version with no number is the highest numbered version, effectively it is +1 from the highest explicitly numbered version. Same mechanism for any other file extension, of course. The older copies would most likely not be recognized as .svg files, but that isn't really their purpose, they are there to serve as backups. Inkscape would have to know how to scan for those sorts of files and offer to open them with the "real" extension. The name could also be something like *.svg.inkback.1, which would likely make finding them a little easier. "test.svg" would have to be locked throughout the save, to avoid problems if another application, especially another copy of inkscape, tried to do the same thing simultaneously.
Where there are numbered versions there is usually a way to trim the list or purge older versions. We can discuss that issue if/when versions are implemented.
4. Region - self evident. The area could by two points (UL,LR as here), or point,W,H. This gets rid of the current "export as bitmap" (or whatever it is called), and generalizes it to all supported output formats.
5. Formats - to make the SUM proponents happy, yet keep the behavior optional. Could we all accept that? The terms "lossy" and "lossless" are not ideal, but you get the idea. When these are selected it would grey out or remove the excluded members from the file type list.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech