Difference between revisions of "Files: Save"
(→Export) |
(→Export) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 46: | Line 46: | ||
=== Export === | === Export === | ||
[[File:Save File Types 1.4.x.png|thumb|File types from the 1.4.x Save dialog.]] | |||
Export document to a non Inkscape SVG format. | Export document to a non Inkscape SVG format. | ||
Line 55: | Line 57: | ||
I'm wondering about which file types we should still support. For example, AutoCAD R12 is from 1992 and R14 is from 1997. Flash is long deprecated, with any kind of support ending in 2020. | I'm wondering about which file types we should still support. For example, AutoCAD R12 is from 1992 and R14 is from 1997. Flash is long deprecated, with any kind of support ending in 2020. | ||
Note: Bitmap formats are only available from the Export dialog. | |||
=== Export Overwrite === | === Export Overwrite === |
Revision as of 14:47, 30 September 2024
Italic text
Introduction
With native file dialogs, we cannot add features such as check boxes for options ("Choices"). We also cannot obtain information about which file filter is selected. This breaks are current method for using file dialogs to influence how files are saved. In particular, we cannot have a checkbox to "Save as 1.1 SVG", nor can we use the file filter setting to distinguish between saving as "Inkscape SVG" or "Plain SVG". Native file dialogs are simply useful for choosing file names, nothing more, nothing less.
It's important to recognize that the Gtk::FileDialog class is NOT derived from a widget thus we cannot not change the insides. This is a necessity born from using native dialogs.
Our current (Inkscape 1.4) situation spreads options for how SVG's are saved across several places. Choosing Inkscape or Plain SVG's is done in the File menu, selecting to save to SVG 2 or SVG 1.1 is done in the File dialog, selecting which SVG 2 features are converted to SVG 1.1 fallbacks is done in the Preferences dialog. It would be better to have all of this in one place.
The Export dialog has received a lot of love over the past few years. However, it currently can handle only a subset of the file types that Inkscape can export to.
See also 2018 proposal.
Proposal
With GTK4 Inkscape, all "Export" is done through the Export dialog, where "Export" is defined as saving a document to any form other than Inkscape SVG.
The File menu will contain these options:
Save
Save a document to Inkscape SVG.
- If a document does not contain a stored filename, open up File dialog to choose a filename.
- Update internal Inkscape version and filename. Clear modified flag.
- Save.
- If save fails, revert internal Inkcape version and filename. Restore modified flag.
Save as...
Save a document as Inkscape SVG with a new different filename.
- Open up File dialog to choose a filename.
- Update internal Inkscape version and filename. Clear modified flag.
- Save.
- If save fails, revert internal Inkcape version and filename. Restore modified flag.
Save a copy...
Save a document as Inkscape SVG with a new different filename, not updating internals.
- Open up File dialog to choose a filename.
- Update internal Inkscape version and filename.
- Save.
- Revert internal Inkcape version and filename. Restore modified flag.
Save Template...
Save a document as an Inkscape template.
Export
Export document to a non Inkscape SVG format.
- Open up Export dialog to choose export file type and options..
Options shown are based on selected file type.
The 1.4.x Export dialog currently handles: PNG, Inkscape SVG (no SVG specific options), Plain SVG, JPEG (with a big warning), TIFF, and WebP. The types the 1.4.x Save dialog handles are shown in the figure.
I'm wondering about which file types we should still support. For example, AutoCAD R12 is from 1992 and R14 is from 1997. Flash is long deprecated, with any kind of support ending in 2020.
Note: Bitmap formats are only available from the Export dialog.
Export Overwrite
New (needs some thought) Export document, overwriting.
- Export to same format as import or to the previously used export filetype.
- No File dialog used.
Unification
We have export from the command line and we have export from the Export dialog. These should be unified. It should be possible to set any values from the command line that you can set within the Export dialog. This can be done either of two ways:
- Adapt the file export class used to track export options to handle more options.
- Rely completely on setting preferences as is done by the Export dialog.
The first means that options are temporary, the second means options are stored in the Preferences file. The second method is probably easier.
Notes on File dialogs
We don't need to check on overwriting files ourselves. The file dialogs on all there platforms already have overwrite protection (verify for Windows).
Linux
MacOS
The MacOS dialog will add a file extension if it doesn't already exist based on the File type filter setting (if the filter setting is set to a single file type).
Windows
Questions
Directories
We keep track of the last directories for various file dialogues in preferences. A couple dialogs will fallback to the Windows' Document directory if a preference is not set. Is this desired behavior? Should it be that way on all platforms? Should it be that way for all file dialogs? If the Document directory does not exist, should we fallback to the Home directory? Glib makes it easy to find these directories (we don't need the complicated Windows code that is in get_start_directory() at the moment).