inkscape 'export bitmap' dialog should indicate success and close after export

[neutrico]

Binary package hint: inkscape

As in topic - currently when I export some svg to bitmap then I don't know if my svg is exported or not - only when I click again on export then inkscape shows me that file already exists.

I think that inkscape should indicate status and also should close dialog after successfull export or at last ask if it should export another svg file/selection to bitmap.

[Simon Law (sfllaw)]

This is a minor usability issue. A progress bar does pop up
when Inkscape exports a graphic, and that goes to 100% before
disappearing.

[Danny Staple (danny-orionrobots)]

I cannot see a progress bar, I see no visual feedback, and I am only able to verify that there was any action at all by using a navigator/command line to list the contents of the destination folder and previewing the output there.

It is, as you say a usability issue, and maybe should be therefore marked as a wishlist item. I would certainly not say it was minor enough to be ignored, as there should be at least some visual confirmation that it has done something, even if that is to close the export dialog when you click the export button itself.

It is possible that the progress bar would only actually be visible on sufficiently complicated diagrams, hence why I did not see it on my machine, and it is otherwise disappearing possibly before it is even rendered to output, or not being visible long enough for a user to observe it. This therefore does not really help.

My tests were on Inkscape 0.44-1ubuntu1 on Edgy.

[Bryce Harrington (bryce)]

You'll note that Inkscape differentiates two types of dialogs - temporary dialogs such as open file, save file, etc. and permanent dialogs like fill and stroke, etc.

The design is this: Dialogs that we expect users will want to continually use, such as if they wished to experiment with several fill colors in succession, or change line styles of several different lines, are kept open until the user explicitly closes them. Dialogs that are typically single-use things, such as open or save-as, are automatically closed after use.

The export dialog is sort of a grey area - for some users it is used essentially the same way that the save-as dialog is used, to quickly export a png and close. However, the design intent includes the use case of icon designers who may be exporting pngs at multiple sizes, or that will be individually exporting several items from the document. For these users, clearly the dialog should stay up.

Anyway, not to argue that one use case is more important than the other, but just to explain why it behaves this way presently. I know it's lame to say, "It's not a bug, it's a feature!" but... ;-)

We have several suggestions in the Inkscape feature request tracker for ideas on improving the export dialog, so if you'd like to influence the future design of this dialog I would encourage finding and commenting on the appropriate tickets there.

[Hystrix (hystrix-)]

In my case I find usefull that the export dialog keeps open when I have a base layer acting as a background and several layers on top of it wich I show/hide in order to export several pngs each one with the same structure/background but with different contents.
Just my 0.002

[TobiasDomhan (tdomhan)]

the dialog should not close after export, it's useful when exporting more than one image in a row. I neither want to reopen it, nor I want to fill out the settings for each image to export successively.

[Guillermo Espertino (Gez) (gespertino-gmail)]

I guess that some minor changes would improve the usability of that window:
- Progress bar should appear in the same window, no popups.
- The progress bar area should change to "export succeded" when the export finished, until the user clicks on another object in the canvas that wasn't exported yet.
A status bar (as GIMP's one) in the bottom would be great: When it's ready to export, a little instruction like "select the image to convert and click export"; that status bar changes to a progress bar while the image is being exported; the status bar shows success message when the process is finished, until the user selects another object.

That window shouldn't autoclose, as it already has been explained. It's great for multiple exports.

[Peter Boström (pbos)]

I've attached a patch that makes the export dialog report to the application status bar. If it hits an error, it'll be reported there too, so any old message should never stick around to confuse the user (if an old message indicates success, while the export fails). These are mostly copies from the error messages given by the dialog.

Batch exports reports how many files were successfully exported, out of how many. "Successfully exported 3 files from 4 selected items." (Tested by setting one path to have inkscape:export-filename=/dev/path.png, which itself fails.)

[Peter Boström (pbos)]

That last one is invalid. I was incorrectly assuming that a non-false return from sp_export_png_file meant that a file was exported. I've now changed sp_export_png_file's return type to "int", and all existing code works as before, but sp_export_png_file returns 1 on success, and -1 on abort, instead of true on both.

This patch now states "Export aborted." instead of incorrectly reporting "Drawing exported to..", even though it's aborted. Hopefully that should do it, sorry about that last one!

[Jon A. Cruz (jon-joncruz)]

Instead of magic numbers, you might want to look at having things return an enum. That can make the code more legible and maintainable.

[Peter Boström (pbos)]

Yeah, I should've done that. I've attached a patch which uses an enum with EXPORT_ERROR = 0, EXPORT_OK and EXPORT_ABORTED.

[Peter Boström (pbos)]

Forgot to update a comment. Honest mistake. I'll make sure to read through my patches more thorough in the future. This should be the last one.

[Alex Valavanis (valavanisalex)]

@JazzyNico I noticed that this is still marked as "In Progress" but has no one assigned to it. Are you working on this at the moment, or was the status referring to Peter?

[jazzynico (jazzynico)]

@Alex - A patch has been submitted, but not tested and committed yet. That's the reason why this report is still marked "In Progress".

[Alex Valavanis (valavanisalex)]

@JazzyNico - That's fine, it was just my impression that "In Progress" bugs should always be assigned to the person who was working on them.

[jazzynico (jazzynico)]

@Alex - You're right. If I remember correctly, that's how it should be done according to the Status reference.
Assigning to Peter.

@Peter, I try to test it and give you some feedback as soon as possible.

[Alex Valavanis (valavanisalex)]

Great, thanks for that

[jazzynico (jazzynico)]

Compiled successfully on Ubuntu 10.04, Inkscape r9773.

Just two comments (since I'm not a C++ expert, I can't comment the code):
1. The messages are persistent, while the ones from File>Save As stay for a couple of seconds only. I don't know which behavior is the best, but since it's the same kind of action, it should be consistent.
2. Very minor: the messages should not end with a period (but I must admit that Inkscape is not very consistent in this respect...).

[Alex Valavanis (valavanisalex)]

@peter - are you still planning to work on this?

[Peter Boström (pbos)]

I don't have any experience, really, with Inkscape's code base, so I don't think I can help with the remaining issues that JazzyNico see without putting more effort into it than I have time for.

The messages I use are in the same format the 'g_strdup_printf' calls had inside the original code and I don't think I should be the one to go around and change existing behaviour. Same with deciding how long messages stay; even if I figured out how to change that, it's "for UI people" to decide how long they stay.

"Shouldn't" there be a "message type" for this kind of information messages so that they, by default, stay for an appropriate time? - Just a thought.

I don't think I can help out further, so I have no plans to work on this. Please assign this to someone more appropriate. Thanks for checking up on me! :)

[Alex Valavanis (valavanisalex)]

OK, thanks for letting us know, and thanks for your hard work so far.

@upstream - Is anyone prepared to make the final tweaks, or would you be happy to commit the patch as is?

[jazzynico (jazzynico)]

Peter> "Shouldn't" there be a "message type" for this kind of information messages so that they, by default, stay for an appropriate time? - Just a thought.

I'm almost sure there is, but I don't know where exactly...
Exploring the File>Save as code would probably help.

@Alex. The persistent message is very annoying and it isn't a good idea to commit the patch now.

[jazzynico (jazzynico)]

Tested again on Ubuntu 10.04.

Last time I tried, the message was so persistent that it took precedence over all the following messages. But this time, it is still persistent (it doesn't disappear after a few seconds like File>Save as) until another message shows up, which is far less annoying than what I first noticed.
Could someone else confirm that a new message override the export message as expected?
I'm going to test it on Windows XP. If everything is ok and this behavior confirmed, then we can commit this patch in the trunk.

[jazzynico (jazzynico)]

Correction, unexpected behavior reproduced on Ubuntu 10.04:
1. Export a drawing.
2. Select a shape tool (rectangle, ellipse, 3D...). A new contextual message shows in the status bar.
3. Move the mouse cursor to the status bar, the export message is back and stays in the status bar even if I draw another shape.

[Jon A. Cruz (jon-joncruz)]

Updated patch to work against latest trunk, however it is still in need of the mentioned refinements.

[Jon A. Cruz (jon-joncruz)]

Applied modified patch in revision #11407.

[Jon A. Cruz (jon-joncruz)]

Added close checkbox item in revision #11409.