Paths and file extensions in save dialogs
Hi all,
as of rev. 22010 the "Save as ..." and "Save a copy ..." dialogs should now remember the last used directories and file extensions independently of each other (this closes at least LP #184655, #386292, and perhaps even a few more, I haven't checked yet). It took me a while to understand how the different OS-specific file dialogs are implemented, and I hope I got it right. But please test extensively and let me know if there are any problems. This particularly applies to Windows users since I cannot test the changes there.
Thanks, Max
P.S.: I believe the export dialog doesn't remember its own path yet althouth I modified some parts in the corresponding source files, too. But it just occurred to me that there is an #ifdef in file.cpp to choose between different types of export dialogs, so I probably modified the wrong part. Anyway, my question is: Is it desired to store the path in the Export dialog at all, at least for the Page and Drawing tabs?
On Fri, Aug 7, 2009 at 7:50 PM, Maximilian Albert < maximilian.albert@...1439...> wrote:
Hi all,
as of rev. 22010 the "Save as ..." and "Save a copy ..." dialogs should now remember the last used directories and file extensions independently of each other (this closes at least LP #184655, #386292, and perhaps even a few more, I haven't checked yet). It took me a while to understand how the different OS-specific file dialogs are implemented, and I hope I got it right. But please test extensively and let me know if there are any problems. This particularly applies to Windows users since I cannot test the changes there.
I'll test it now. Results should be forthcoming in under an hour.
P.S.: I believe the export dialog doesn't remember its own path yet
althouth I modified some parts in the corresponding source files, too. But it just occurred to me that there is an #ifdef in file.cpp to choose between different types of export dialogs, so I probably modified the wrong part. Anyway, my question is: Is it desired to store the path in the Export dialog at all, at least for the Page and Drawing tabs?
The export dialogue does it differently; if exporting the whole drawing or an object, that object saves its own path, which can be a bit of a nuisance cross-platform - e.g. one of the inkscape website designs I was looking at was then automatically setting it to /home/..., but generally that's very useful. So to answer your question, yes it is desired to store the path, but I think it already does for Page and it does for Drawing, inside the inkscape namespace in the SVG. I'm happy with how it does it (or did before you committed anyhow in case you changed it.)
You probably knew that anyway :P
-- Chris Morgan <chris.morganiser@...400...>
I don't need a quote in my signature. It's hard enough surviving as it is without having to find a meaningful quote. Will you forgive me? Or don't you read this bit?
No go - broken. Attached is compile.lst containing just the files it broke on.
On Fri, Aug 7, 2009 at 8:25 PM, Chris Morgan <chris.morganiser@...400...>wrote:
On Fri, Aug 7, 2009 at 7:50 PM, Maximilian Albert < maximilian.albert@...1439...> wrote:
Hi all,
as of rev. 22010 the "Save as ..." and "Save a copy ..." dialogs should now remember the last used directories and file extensions independently of each other (this closes at least LP #184655, #386292, and perhaps even a few more, I haven't checked yet). It took me a while to understand how the different OS-specific file dialogs are implemented, and I hope I got it right. But please test extensively and let me know if there are any problems. This particularly applies to Windows users since I cannot test the changes there.
I'll test it now. Results should be forthcoming in under an hour.
P.S.: I believe the export dialog doesn't remember its own path yet
althouth I modified some parts in the corresponding source files, too. But it just occurred to me that there is an #ifdef in file.cpp to choose between different types of export dialogs, so I probably modified the wrong part. Anyway, my question is: Is it desired to store the path in the Export dialog at all, at least for the Page and Drawing tabs?
The export dialogue does it differently; if exporting the whole drawing or an object, that object saves its own path, which can be a bit of a nuisance cross-platform - e.g. one of the inkscape website designs I was looking at was then automatically setting it to /home/..., but generally that's very useful. So to answer your question, yes it is desired to store the path, but I think it already does for Page and it does for Drawing, inside the inkscape namespace in the SVG. I'm happy with how it does it (or did before you committed anyhow in case you changed it.)
You probably knew that anyway :P
-- Chris Morgan <chris.morganiser@...400...>
I don't need a quote in my signature. It's hard enough surviving as it is without having to find a meaningful quote. Will you forgive me? Or don't you read this bit?
-- Chris Morgan <chris.morganiser@...400...>
I don't need a quote in my signature. It's hard enough surviving as it is without having to find a meaningful quote. Will you forgive me? Or don't you read this bit?
2009/8/7 Chris Morgan <chris.morganiser@...400...>:
No go - broken. Attached is compile.lst containing just the files it broke on.
Oops, sorry. I accidentally added a parameter to the wrong method in the .h file but didn't notice since compiling on Linux disregarded the relevant sections of the file. It should be fixed now. Could you try again?
Thanks for your help! Max
2009/8/7 Maximilian Albert <maximilian.albert@...1439...>:
Please test extensively and let me know if there are any problems.
I just discovered a small glitch myself which is also described in the following bug report:
https://bugs.launchpad.net/inkscape/+bug/171932
After some investigation, I found that it's caused by the fact that Inkscape reads the SVG attribute "inkscape:output_extension" from newly opened files and uses this as the default file extension when invoking the "Save as ..." dialog for the first time. I can fix the above bug by simply discarding it, but then I'm wondering why this attribute is stored/used at all? Would it be save to discard it and simply reuse the last used file extension when the save dialog is opened? Hmm, I guess I'll just commit my changes after some further testing (not before tomorrow, though) and will wait for people to comment after testing the new behaviour.
Max
2009/8/8 Maximilian Albert <maximilian.albert@...1439...>:
After some investigation, I found that it's caused by the fact that Inkscape reads the SVG attribute "inkscape:output_extension" from newly opened files and uses this as the default file extension when invoking the "Save as ..." dialog for the first time. I can fix the above bug by simply discarding it, but then I'm wondering why this attribute is stored/used at all? Would it be save to discard it and simply reuse the last used file extension when the save dialog is opened? Hmm, I guess I'll just commit my changes after some further testing (not before tomorrow, though) and will wait for people to comment after testing the new behaviour.
I haven't heard back from anyone but I've discovered the discusion of the following bug report which says that inkscape:output_extension should be eliminated:
https://bugs.launchpad.net/inkscape/+bug/170966
Since my changes already partly achieved this I went ahead and dumped inkscape:output_extension completely from the code base in rev. 22033, where I also committed the other fixes to the behaviour of "Save as ..."/"Save a copy ..." (so that now the various types of save dialogs should remember their file extensions and paths completely independently of each other). It turned out that a good deal of code could be simplified in the process. Although the changes to the code base are not huge, they are non-neglegible, so I'd like everyone to test this thoroughly and report any problems. In particular, please test with all combinations of "Save as ...", "Save as copy ...", "Export bitmap" and various file types, different folders, several documents opened at once, etc. (I did a lot of tests myself but I may have missed some cases). If you are very nitpicky, you can double check that the saved files are actually of the types indicated by their file extensions. Feedback like "works fine for me" is also acknowledged. :-) If people feel uneasy with such a change at this point I'm also fine with holding it off until after 0.47, although I believe it could be a major improvement to this release (and it's been a long-requested fix, too).
One remark concerning the elimination of inkscape:output_extension: We now don't store the file extension on a per-document basis any more but rather on a per-save-action basis. That is, if you have two documents open at the same time and save one of them using "Save as ..." with a certain file type, switch to the other document and invoke "Save as ...", it remembers the just used file type. I hope this is desired, since it's also requested in LP #171932, but I thought I'd mention it.
Moreover, the folder is also stored on a per-save-basis, which might be confusing if you are working with two documents simultaneously each of which you want to successively "save as ..." in different folders (because the dialog always presents you with the folder of the last saved file). Should there be an option somewhere to always choose the current folder and only remember the last used file extension or is this overkill because such a workflow is unlikely?
And another thing: When saving a newly created file for the first time, I made the dialog propose "Inkscape SVG" as the file format, regardles of what previous files were saved as. I think this reasonable, but do others agree?
Thanks for any feedback! Max
On 9/8/09 16:29, Maximilian Albert wrote:
In particular, please test with all combinations of "Save as ...", "Save as copy ...", "Export bitmap" and various file types, different folders, several documents opened at once, etc. (I did a lot of tests myself but I may have missed some cases).
I haven't updated from SVN to test your changes yet (using r22028), but regarding the 'Export bitmap" dialog - there's still the attribute 'inkscape:export-filename' that needs some attention I think:
Bug #411568 “'batch export selected' exports to different paths without notice” https://bugs.launchpad.net/inkscape/+bug/411568
Could you have a look at it? What is the status of this attribute? Is it going to be removed as well as discussed in these reports: Bug #170966 in Inkscape: “move export hints from SVG files to prefs” https://bugs.launchpad.net/inkscape/+bug/170966 Bug #168958 in Inkscape: “Privacy concern with export-filename and sodipodi:absref” https://bugs.launchpad.net/inkscape/+bug/168958
~suv
On Wed, Aug 12, 2009 at 7:26 AM, ~suv<suv-sf@...58...> wrote:
I haven't updated from SVN to test your changes yet (using r22028), but regarding the 'Export bitmap" dialog - there's still the attribute 'inkscape:export-filename' that needs some attention I think:
Bug #411568 “'batch export selected' exports to different paths without notice” https://bugs.launchpad.net/inkscape/+bug/411568
It should warn you in batch export if the target path does not exist. But otherwise this is the expected behavior. I want to be able to mass-export from one master SVG to many PNGs in different dirs, and I want it to remember those dirs per object.
I propose to rename this to "Batch export should be more explicit about where it exports stuff".
Bug #170966 in Inkscape: “move export hints from SVG files to prefs” https://bugs.launchpad.net/inkscape/+bug/170966 Bug #168958 in Inkscape: “Privacy concern with export-filename and sodipodi:absref” https://bugs.launchpad.net/inkscape/+bug/168958
The point of export hints is that they are stored per-object. Storing the IDs and export data for all exported objects in all documents in prefs does not sound too elegant and will be hard to keep up to date - any deletion of an object and any ID change will have to go to prefs and update that data so it stays in sync. I don't know if it makes sense to implement all this.
Once again: I agree to add a preference option to save export hints (on by default), and/or a command to remove all hints if you want to share your file. But otherwise, the current system is simple, straightforward, and saves a lot of time in real work.
On 9/8/09 16:29, Maximilian Albert wrote:
Since my changes already partly achieved this I went ahead and dumped inkscape:output_extension completely from the code base in rev. 22033, where I also committed the other fixes to the behaviour of "Save as ..."/"Save a copy ..." (so that now the various types of save dialogs should remember their file extensions and paths completely independently of each other). It turned out that a good deal of code could be simplified in the process. Although the changes to the code base are not huge, they are non-neglegible, so I'd like everyone to test this thoroughly and report any problems. In particular, please test with all combinations of "Save as ...", "Save as copy ...", "Export bitmap" and various file types, different folders, several documents opened at once, etc. (I did a lot of tests myself but I may have missed some cases). If you are very nitpicky, you can double check that the saved files are actually of the types indicated by their file extensions. Feedback like "works fine for me" is also acknowledged. :-) If people feel uneasy with such a change at this point I'm also fine with holding it off until after 0.47, although I believe it could be a major improvement to this release (and it's been a long-requested fix, too).
On OS X 10.5.8 using Inkscape 046+devel r22058, when opening the 'Save as...' dialog for the first time, it defaults to a path inside the application bundle, which is a big 'no-no' place to ever write files created by the user. A related but different problem is when Inkscape sometimes dumps tmp files or 'inkscape_pasted_image_*.png' inside the bundle and never cleans up (see bug #389262 comment 2).
Moreover, the folder is also stored on a per-save-basis, which might be confusing if you are working with two documents simultaneously each of which you want to successively "save as ..." in different folders (because the dialog always presents you with the folder of the last saved file). Should there be an option somewhere to always choose the current folder and only remember the last used file extension or is this overkill because such a workflow is unlikely?
Once the user saved a file to a certain location, it is used as default when calling 'Save as...' again. Works for me, but for those who adapted their work flow to the old way? Big change. I think adding an option to always default to the current working directory makes sense.
~suv
On 12/8/09 14:01, ~suv wrote:
On OS X 10.5.8 using Inkscape 046+devel r22058, when opening the 'Save as...' dialog for the first time, it defaults to a path inside the application bundle,
Fix in SVN revision 22060 confirmed - on OS X Inkscape 22062 now opens the 'Save as...' dialog at first run in $HOME, like in previous versions (tested: r21924, r22028).
thanks, ~suv
Hi,
I'm very sorry that it took me so long to get back to this, but I was moving between different locations in Asia and Europe during the last few weeks and for most of the time didn't have access to emails and my computer.
Once the user saved a file to a certain location, it is used as default when calling 'Save as...' again. Works for me, but for those who adapted their work flow to the old way? Big change. I think adding an option to always default to the current working directory makes sense.
I agree. Attached is a patch which adds an option to the Preferences to choose between both kinds of behaviour. I renamed the "Autosave" page to "Save" and added the option there because it seemed most logical; please let me know if you disagree. I'm not sure if this patch is acceptable during freeze since in some sense it adds a feature, but I'd regard it more as a bug fix so I'm sending it anyway and leave it to the release wardens to decide. BTW, feel free to change the wording in the tooltip because I have the feeling that it doesn't sound as smooth as it could (that's the disadvantage of not being a native speaker).
Max
On 17/9/09 17:09, Maximilian Albert wrote:
Once the user saved a file to a certain location, it is used as default when calling 'Save as...' again. Works for me, but for those who adapted their work flow to the old way? Big change. I think adding an option to always default to the current working directory makes sense.
I agree. Attached is a patch which adds an option to the Preferences to choose between both kinds of behaviour. I renamed the "Autosave" page to "Save" and added the option there because it seemed most logical; please let me know if you disagree. I'm not sure if this patch is acceptable during freeze since in some sense it adds a feature, but I'd regard it more as a bug fix so I'm sending it anyway and leave it to the release wardens to decide. BTW, feel free to change the wording in the tooltip because I have the feeling that it doesn't sound as smooth as it could (that's the disadvantage of not being a native speaker).
I'm testing your patch now (with r22271).
Question (just to be sure I fully understand the patch): 'Save as...' and 'Save as Copy...' use independent settings i.e. 'Open...' and 'Save a Copy...' always default to its 'Last used' folder, whereas 'Save as...' can be toggled between 'Current' and 'Last used'?
BTW - I get this warning when compiling (in my build logs since 22058, not present in 22028):
extension/system.cpp:558: warning: enumeration value ‘FILE_SAVE_METHOD_EXPORT’ not handled in switch
It causes no error and compiles fine. Seems related to your latest commits in rev. 22033?
~suv
2009/9/17 Maximilian Albert <maximilian.albert@...1439...>:
I agree. Attached is a patch which adds an option to the Preferences to choose between both kinds of behaviour. I renamed the "Autosave" page to "Save" and added the option there because it seemed most logical; please let me know if you disagree. I'm not sure if this patch is acceptable during freeze since in some sense it adds a feature, but I'd regard it more as a bug fix so I'm sending it anyway and leave it to the release wardens to decide.
Any news on this?
Max
On 1/10/09 09:10, Maximilian Albert wrote:
2009/9/17 Maximilian Albert <maximilian.albert@...1439...>:
I agree. Attached is a patch which adds an option to the Preferences to choose between both kinds of behaviour. I renamed the "Autosave" page to "Save" and added the option there because it seemed most logical; please let me know if you disagree. I'm not sure if this patch is acceptable during freeze since in some sense it adds a feature, but I'd regard it more as a bug fix so I'm sending it anyway and leave it to the release wardens to decide.
Any news on this?
Patch tested and confirmed with Inkscape 0.46+devel r22293 to r22349 on OS X 10.5.8
The patch works fine and improves file handling in Inkscape IMHO. My use of the new option: once set to "use current directory for 'Save as…'" I never felt the need to go back and use 'most recent'. It takes time though to remember the different ways the file dialogs now behave:
open: most recent - good save as: current - good save a copy: most recent - good for repeated exporting to fixed folders, - less for backups/variants in current or below import: most recent - ok
I would certainly vote to include this patch for 0.47 as an important option though I still like the idea to have 'current' listed under Places in the gtk-filechooser dialog - i.e. a shortcut for the current folder available for every file command (open/save/copy/import).
~suv
On 1/10/09 09:53, ~suv wrote:
On 1/10/09 09:10, Maximilian Albert wrote:
2009/9/17 Maximilian Albert <maximilian.albert@...1439...>:
I agree. Attached is a patch which adds an option to the Preferences to choose between both kinds of behaviour. I renamed the "Autosave" page to "Save" and added the option there because it seemed most logical; please let me know if you disagree. I'm not sure if this patch is acceptable during freeze since in some sense it adds a feature, but I'd regard it more as a bug fix so I'm sending it anyway and leave it to the release wardens to decide.
Any news on this?
Patch tested and confirmed with Inkscape 0.46+devel r22293 to r22349 on OS X 10.5.8
*ping* Josh - any change this patch gets a review? I think the new Open/Save file dialog location is a major change that will affect the workflow of many users - giving them an option to keep the old behavior of the 'Save as...' dialog might be well appreciated...
~suv
On Fri, 2009-10-02 at 18:58 +0200, ~suv wrote:
On 1/10/09 09:53, ~suv wrote:
On 1/10/09 09:10, Maximilian Albert wrote:
2009/9/17 Maximilian Albert <maximilian.albert@...1439...>:
I agree. Attached is a patch which adds an option to the Preferences to choose between both kinds of behaviour. I renamed the "Autosave" page to "Save" and added the option there because it seemed most logical; please let me know if you disagree. I'm not sure if this patch is acceptable during freeze since in some sense it adds a feature, but I'd regard it more as a bug fix so I'm sending it anyway and leave it to the release wardens to decide.
Any news on this?
Patch tested and confirmed with Inkscape 0.46+devel r22293 to r22349 on OS X 10.5.8
*ping* Josh - any change this patch gets a review? I think the new Open/Save file dialog location is a major change that will affect the workflow of many users - giving them an option to keep the old behavior of the 'Save as...' dialog might be well appreciated...
Reviewed, tested, and committed (as the behavior is much better imho). I did slightly modify the tooltip per Max's comment too.
Cheers, Josh
On 2/10/09 23:20, Joshua A. Andler wrote:
On Fri, 2009-10-02 at 18:58 +0200, ~suv wrote:
On 1/10/09 09:53, ~suv wrote:
On 1/10/09 09:10, Maximilian Albert wrote:
Any news on this?
Patch tested and confirmed with Inkscape 0.46+devel r22293 to r22349 on OS X 10.5.8
*ping* Josh - any change this patch gets a review? I think the new Open/Save file dialog location is a major change that will affect the workflow of many users - giving them an option to keep the old behavior of the 'Save as...' dialog might be well appreciated...
s/change/chance ;-)
Reviewed, tested, and committed (as the behavior is much better imho). I did slightly modify the tooltip per Max's comment too.
:) Thank you!
~suv (who didn't dare to hope as release date seems imminent)
On Fri, Oct 2, 2009 at 6:20 PM, Joshua A. Andler <scislac@...400...> wrote:
Reviewed, tested, and committed (as the behavior is much better imho). I did slightly modify the tooltip per Max's comment too.
Can you or anyone please fill a Release Notes entry for this? Thanks!
On Fri, 2009-10-02 at 23:42 -0300, bulia byak wrote:
On Fri, Oct 2, 2009 at 6:20 PM, Joshua A. Andler <scislac@...400...> wrote:
Reviewed, tested, and committed (as the behavior is much better imho). I did slightly modify the tooltip per Max's comment too.
Can you or anyone please fill a Release Notes entry for this? Thanks!
Yeah, I am willing to do that (and planned on it). But, it's date night, so it won't be before tomorrow. :)
Cheers, Josh
On 9/8/09 16:29, Maximilian Albert wrote:
Moreover, the folder is also stored on a per-save-basis, which might be confusing if you are working with two documents simultaneously each of which you want to successively "save as ..." in different folders (because the dialog always presents you with the folder of the last saved file). Should there be an option somewhere to always choose the current folder and only remember the last used file extension or is this overkill because such a workflow is unlikely?
Any news on this? My issue with the new way the folder is stored on a per-save-basis:
I no longer have a way to quickly figure out where the current document is located on disk without saving it (i.e. change, save, undo) in order to see the full path name in the window title bar. Before I could open the "Save as..." dialog to immediately see the current working directory, now I have to switch to 'Recently Used' in the file chooser dialog and hover over the files to read the info in the tool tip.
This is annoying if you open a drawing from the 'Open Recent' list and e.g. want to save a snapshot/backup/variant of the document in the same folder as (or relative to the folder of) the original.
And I have 'lost' several files this way because they weren't saved in $CWD where I expected them to be: if in a rush I tend to forget to check the location (or compare it to $CWD) in the 'Save as...' or 'Save a copy...' dialogs and have to resort to the file manager to locate the misplaced copies ;-)
Some ideas: - add an entry for the 'current working directory' in the file chooser dialog (like 'home', 'system' or 'templates' under 'Places') - always display the full name (path+filename) in the window title bar - add a shortcut to display file info (full path + file name, maybe size or last Mod date) in the status line - add tool tips to the files in the 'Open Recent' list as in the file chooser dialog, displaying full path + file name
To choose in the preferences between 'always use current folder' or 'always use last used folder' doesn't help as IMHO it often fits the work-flow to use the recent folder.
~suv
Hi ~suv,
Moreover, the folder is also stored on a per-save-basis, which might be confusing if you are working with two documents simultaneously each of which you want to successively "save as ..." in different folders (because the dialog always presents you with the folder of the last saved file). Should there be an option somewhere to always choose the current folder and only remember the last used file extension or is this overkill because such a workflow is unlikely?
Any news on this? My issue with the new way the folder is stored on a per-save-basis:
I just sent a patch in reply to an earlier email of yours, but in another message you wrote that this wouldn't fully solve your issues. I apologize for my lack of understanding, but could you restate what exactly these issues are? AFAIU, it's related to not knowing the location where a document was saved. But when I save a document the full path is displayed in the windows title bar, so maybe I'm misunderstanding your problem. Could you elaborate once again? Sorry if I'm asking you to repeat yourself.
Max
Hi Max,
On 17/9/09 17:22, Maximilian Albert wrote:
On 3/9/09 19:01, ~suv wrote:
On 9/8/09 16:29, Maximilian Albert wrote:
Moreover, the folder is also stored on a per-save-basis, which might be confusing if you are working with two documents simultaneously each of which you want to successively "save as ..." in different folders (because the dialog always presents you with the folder of the last saved file). Should there be an option somewhere to always choose the current folder and only remember the last used file extension or is this overkill because such a workflow is unlikely?
Any news on this? My issue with the new way the folder is stored on a per-save-basis:
I just sent a patch in reply to an earlier email of yours, but in another message you wrote that this wouldn't fully solve your issues. I apologize for my lack of understanding, but could you restate what exactly these issues are? AFAIU, it's related to not knowing the location where a document was saved. But when I save a document the full path is displayed in the windows title bar, so maybe I'm misunderstanding your problem. Could you elaborate once again? Sorry if I'm asking you to repeat yourself.
No, it's my fault - my two earlier messages are contradictory (in hindsight) - consider the 3 weeks in-between as learning curve...
On 12/8/09 14:01, ~suv wrote:
Once the user saved a file to a certain location, it is used as default when calling 'Save as...' again. Works for me, but for those who adapted their work flow to the old way? Big change. I think adding an option to always default to the current working directory makes sense.
On 3/9/09 19:01, ~suv wrote:
To choose in the preferences between 'always use current folder' or 'always use last used folder' doesn't help as IMHO it often fits the work-flow to use the recent folder.
Basically I learned to appreciate the 'last used folder' default (after getting used to it). To have the choice 'last used folder' and 'always current working directory' is be a viable option but would force me to choose when I only miss a minor additional feature for the 'last used folder' default:
How do you figure out in an easy way what the current working directory (path to the currently open document) is - without unnecessarily modifying it to be able to save it? There may be several reasons why you want to know this - mine mostly was to avoid additional later reorganization of the files in the file manager because a save/export operation (e.g. in a second document window) placed the files in the wrong folder.
Scenario: open a document from the 'Open recent...' list 1) you want to export it (save a copy) to different formats in a folder relative to its location 2) you want to extract embedded images into the same folder (no file browser available - you need to know the path) 3) you want to open a related second drawing stored in a (sub-)folder of the currently open drawing (but the file browser dialog opens in the location of a project you worked on yesterday) 4) ...
My preferred solutions would be a) always display the full path in the window title b) add a 'Current' location to the places in the gtk file chooser (like home, system and templates)
Maybe you have a better idea or can show me existing alternatives? Or convince me that no one else ever needs to know the $CWD ;-) ?
Thank you for considering my thoughts on this,
~suv
On Fri, Aug 7, 2009 at 6:50 AM, Maximilian Albert<maximilian.albert@...1439...> wrote:
modified the wrong part. Anyway, my question is: Is it desired to store the path in the Export dialog at all, at least for the Page and Drawing tabs?
They are already stored and restored: for page/drawing in the root of the document, for individual objects, in those objects (inkscape:export-filename attributes). So they are already taken care of on per-document and even per-object basis (test it!)
2009/8/9 bulia byak <buliabyak@...400...>:
On Fri, Aug 7, 2009 at 6:50 AM, Maximilian Albert<maximilian.albert@...1439...> wrote:
modified the wrong part. Anyway, my question is: Is it desired to store the path in the Export dialog at all, at least for the Page and Drawing tabs?
They are already stored and restored: for page/drawing in the root of the document, for individual objects, in those objects (inkscape:export-filename attributes). So they are already taken care of on per-document and even per-object basis (test it!)
Yes, right. I got a bit confused from reading the code. :-) I didn't know that there are two types of export dialogs, one of which mimicks the regular Save dialog and is deactivated by default. I have never tried it anyway. Does it work and does anyone use it?
Max
On Sun, Aug 9, 2009 at 10:35 AM, Maximilian Albert<maximilian.albert@...1439...> wrote:
They are already stored and restored: for page/drawing in the root of the document, for individual objects, in those objects (inkscape:export-filename attributes). So they are already taken care of on per-document and even per-object basis (test it!)
Yes, right. I got a bit confused from reading the code. :-) I didn't know that there are two types of export dialogs, one of which mimicks the regular Save dialog and is deactivated by default. I have never tried it anyway. Does it work and does anyone use it?
The save-like dialog is for vector output, the "other" one is for bitmap export (ctrl+shift+e). Yes, the export hints are pretty fundamental to slicing and other scenarios where you export many different pngs from one svg. I'd expect we would hear if they get broken.
2009/8/9 bulia byak <buliabyak@...400...>:
Yes, right. I got a bit confused from reading the code. :-) I didn't know that there are two types of export dialogs, one of which mimicks the regular Save dialog and is deactivated by default. I have never tried it anyway. Does it work and does anyone use it?
The save-like dialog is for vector output, the "other" one is for bitmap export (ctrl+shift+e).
I'm not sure if I understand which dialog you're referring to because it sounds like the one you're describing is in regular use. I'm talking about the one which is defined in ui/dialog/filedialog.cpp starting from line #240 (as of rev. 22036) and which has #ifdefs around it. Anyway, I just tried it and it's apparently not currently used since Inkscape didn't even compile when I uncommented #define NEW_EXPORT_DIALOG. :-P
Now I put the whole code which refers to this dialog between #ifdef's and fixed the build when NEW_EXPORT_DIALOG is defined. However, the dialog crashes when trying to export any file. I'm wondering if it can be scrapped completely since it's apparently not in use and doesn't seem to have been touched since revision 12671. Any opinions?
Max
As this is at least Yann's 5th patch (that I'm aware of), I think he has deserved direct commit access! Who is administrating this?
Diederik
From: Yann Papouin [mailto:yann.papouin@...400...] Sent: 2009 aug 09 23:06 To: Maximilian Albert Cc: Inkscape Devel List; bulia byak Subject: Re: [Inkscape-devel] Paths and file extensions in save dialogs
Some namespaces are missing in rev 22036 for a Win32 build Check attached patch.
On Sun, Aug 9, 2009 at 1:56 PM, Maximilian Albert<maximilian.albert@...1439...> wrote:
Now I put the whole code which refers to this dialog between #ifdef's and fixed the build when NEW_EXPORT_DIALOG is defined. However, the dialog crashes when trying to export any file. I'm wondering if it can be scrapped completely since it's apparently not in use and doesn't seem to have been touched since revision 12671. Any opinions?
I remember there was some activity a couple years ago for a new export dialog - I remember seeing mockups, at least. I'm not sure what to do with the disfunctional code - of course the first instinct is to delete it, but I think we should first contact those who added it, in case they or anyone else might be interested in resuming the work. Of course the new export dialog must, at least, provide all the functionality of the current Ctrl+Shift+E.
May i suggest to only refactor as much as really needed to close the bugs that are open.
Wasn't there this discussion about to use export and import dialogues for non svg file formats where is a potential loss of information and to use open and save only for svg. ... Adib.
On Sun, Aug 9, 2009 at 6:56 PM, Maximilian Albert<maximilian.albert@...1439...> wrote:
2009/8/9 bulia byak <buliabyak@...400...>:
Yes, right. I got a bit confused from reading the code. :-) I didn't know that there are two types of export dialogs, one of which mimicks the regular Save dialog and is deactivated by default. I have never tried it anyway. Does it work and does anyone use it?
The save-like dialog is for vector output, the "other" one is for bitmap export (ctrl+shift+e).
I'm not sure if I understand which dialog you're referring to because it sounds like the one you're describing is in regular use. I'm talking about the one which is defined in ui/dialog/filedialog.cpp starting from line #240 (as of rev. 22036) and which has #ifdefs around it. Anyway, I just tried it and it's apparently not currently used since Inkscape didn't even compile when I uncommented #define NEW_EXPORT_DIALOG. :-P
Now I put the whole code which refers to this dialog between #ifdef's and fixed the build when NEW_EXPORT_DIALOG is defined. However, the dialog crashes when trying to export any file. I'm wondering if it can be scrapped completely since it's apparently not in use and doesn't seem to have been touched since revision 12671. Any opinions?
Max
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (8)
-
bulia byak -
Chris Morgan -
Diederik van Lierop -
Joshua A. Andler -
Maximilian Albert -
the Adib -
Yann Papouin -
~suv