#704 Add file export button and dialog to wxt terminal

[Dan Sebald]

Here is a good start for a patch that will export the plot in the wxt terminal using wxWidgets elements.

All you need to do is put your code for saving as PNG or whatnot in the location provided in the new switch statement. You may also want to tweak things, e.g., change the filters to whatever files you can save as.

This is slightly different than the way Qt behaves as far as picking a file format. It's done via the file dialog's filter feature. It makes for a more conventional method of choosing, and in fact makes for easier programming versus putting a dropdown menu associated with the toolbar button. I suggest adding your code and moving into the repository then let people compare/experiment. If people prefer the dropdown menu, I can give that a try.

[Ethan Merritt]

Thanks Dan.

OK, Here's a preliminary implementation of the save to PNG/PDF/SVG widget. It works, but could be improved.

• The saved PDF/SVG files are in the oversampled coordinate system, which means they have to be rescaled for viewing. Not an issue if you are embedding it another document, but the SVG file in particular is hard to view by itself.

• I hate modal pop-ups, but the file selector doesn't seem to work if you call it without the Modal attribute.

• I'm not sure all wxt installations provide support for svg. This might need some additional checks and #ifdefs

[Dan Sebald]

OK, very nice Ethan. I'm modifying a few things here and just about have a new version of the patch, but it will take a couple days to find time to finish. I'll write more then, but here is a brief summary.

1) I've added some code that will keep track of the user's most recent directory and filter choice. That's always nice. It easy to do this, but I also am saving these values to the configuration so that the info will be retained from one launch to the next. However, that code adds some bulkiness, and who knows if people ultimately like that as opposed to just remembering the directory/filter within one session.

2) The addition of the extension creates a bug. If the file "foo.png" exists and one types "foo", the file dialog closes and then the added ".png" will overwrite "foo.png" without asking. The way around this is to write a new class gpFileDialog that inherits wxFileDialog and add the extension in an overridden "Save" button press.

3) Yes, I don't like modal windows either. Qt is better that way in the sense that there is a way to connect a slot to the non-modal dialog. However, if with the new gpFileDialog class the PNG/SVG/PDF code is moved inside that object, it might be possible to Show() gpFileDialog as non-modal. We'll save that for after the initial patch.

[Dan Sebald]

Oh, and I wanted to point out I sort of prefer the filter method of selecting the file type. It's just that the information is where expected. With the drop down menu, selecting the file type amidst other items requires slightly too much mental hesitation.

[Ethan Merritt]

Here is an updated patch that gets the oversampling/rescaling right, saves into the current directory by default, and makes the SVG code conditional on CAIRO_HAS_SVG_SURFACE.

I don't think it's a good idea to save the current directory to the configuration file. In a new gnuplot session it's far more likely that I want to use and save files in the "real" current directory than it is that I want to save them to some other directory that I happened to be in the last time I used gnuplot.

Do you see a way to have "Copy to Clipboard" act as a selectable file type? I can get it to appear in the list of filetypes, but then when I select it the dialog won't let me proceed without typing in a useless filename.

[Dan Sebald]

OK, looks good. In the attached patch I've done the following:

1) Moved the auto-extension code hunks out of the wxt_gui.cpp file. There is no way for the logic to work out correctly when it is there. Instead, I created a new class that inherits wxFileDialog and moved the auto-extension code there.

2) Moving the auto-extension test still wasn't enough to get the program flow correct because the Save button isn't an actual button in wxWidgets. It is part of the toolkit's file dialog. Try as I may, I couldn't control the Save button action, e.g., force a button press event from the gpFileDialog::OnOk() function. So, I simply disabled the toolkit's overwrite-prompt and reimplemented an overwrite-prompt, which was easy.

3) I wanted a mechanism to disable auto-extension and the logical approach is a small checkbox just below the file directory box. However, the ability to do that isn't in 2.8, it's in 2.9. So, if you have 2.9 wxWidgets or greater, you may need to do a small amount of debugging.

My general comment is that this new patch is more in line with OOP principles. There's no way to have the auto-extension code be in the wxt_gui.cpp file and not have a bug of sorts. If the extra code isn't wanted, then get rid of auto-extension all together. I sort of prefer having auto-extension because an image file without an extension always leaves me wondering.

[Dan Sebald]

I forgot to add:

4) Record the file type and directory so that re-entering returns to the environment the user left off with. I kind of prefer that because often I put things in subdirectories and don't like to repeat following the directory path. This info is not stored in settings so is reset to current working directory with every relaunch.

[Ethan Merritt]

I would prefer to get rid of auto-extension altogether. I strikes me as a "Windows-ism".

[Dan Sebald]

OK, here's a patch that only has mods for wxt_gui.cpp. It removes the existing auto-extension and also adds the memory for the directory/file type.

The benefit is that it uses the system's overwrite-prompt dialog. I guess I'm on the fence about it. I always thought that gimp had autoextension, but I've just tried than and it appears it does auto-extension, but if the file name is "foo", the saved file is "foo.xcf" and not in the file type listed in the combo box. That I don't like. I'd much rather have the combo box selection determine the file type rather than have the code look at what the extension is and then adjust appropriately. I don't know. Why don't you try saving some files in gimp and see what you think?

One small issue I hadn't noticed until now is that with no "All Files" selection in the combo box there is no way to see any files beyond "svg", "png" and "pdf". In some sense that may not be bad because it inherently forces the user to use the right file type even though they have the ability to use whatever extension they'd like. I'd say leave it as is until complaints get to be too much.

[Karl Ratzsch]

You can actually see all files, just type a * wildcard at the file name prompt.

I just saw (http://docs.wxwidgets.org/trunk/overview_html.html) that wxwidgets is principally able to display MS windows hhc/hhp/hhk help files, that are created by doc2html(?), without need for MS utilities. Has that been tried?

[Bastian Märkisch]

Yes. The doc2html conversion utitity is able to generate appropriate output and at some stage I even added a target to Makefile.am. Wether that still works I don't know. Not being familiar enough with wxWidgets, I wasn't able to get the help system running though. Maybe Dan can help out here?

[Dan Sebald]

To avoid confusing this patch thread, I've started a new patch thread for what I think you are suggesting:

707 Html help/doc via GUI terminal
https://sourceforge.net/p/gnuplot/patches/707/

[Karl Ratzsch]

Changing the directory in the "save as png/pdf/svg" dialog also changes the directory for gnuplot. (here on 5.1-cvs win7/mingw/wxt2.8)
I don´t think this is intended.

[Dan Sebald]

It's not intended. I'll look at this later this week. I'm suspecting that the wxWidgets tools for system directory use the same tools as what the gnuplot command line is using. (I assumed they aren't connected, i.e., that wxWidgets has its own setup.)

It shouldn't be a difficult fix. I'm guessing wxFD_SAVE needs to be removed as an option for the wxFileDialog instantiation. Then for the file save dialog to return to the previously saved directory we simply get the path from exportFileDialog.GetPath() and save that in a static variable.

Do you agree that the file save dialog should remember the directory it saved to previously? It seems the convenient thing to do.

[Karl Ratzsch]

I think it definitely should. Probably reset it when the terminal window gets closed or when the path in gnuplot is changed?

[Ethan Merritt]

I removed wxFD_CHANGE_DIR from the source, but that may not change anything on MSWin depending on the version.
From the wxt 2.8.4 docs:

NB: Previous versions of wxWidgets used wxFD_CHANGE_DIR
 by default under MS Windows which allowed the program
 to simply remember the last directory where user 
selected the files to open/save. This (desired) 
functionality must be implemented in the program itself
 now (manually remember the last path used and pass it
 to the dialog the next time it is called) or by using 
this flag.

[Karl Ratzsch]

I´ve got wxMSW 2.8.12 here on win7/mingw, where the gp path is not changed any more now.

It´d be cool if the save dialog remembered the path after the first use (see above), but i´m not sure when it should be reset.

[Dan Sebald]

I think remembering the path is good. Most programs do so, and I personally dislike having to repeat stepping through directories to save files. The command line path and the save-plot path should be independent, however. It's quite common to be working with data in some directory and want to save plots in some subdirectory, or some completely different directory related to, say, a publication.

I think there should be no resetting of the directory path. It's simply too difficult to anticipate where the user wants plot output to go. If the user removes a subdirectory outside of gnuplot, I believe the file browser will inherently figure that out. For other programs, I've notice the file browser goes back to the account directory.

Anyway, it's easy to make them independent. However, I won't have time until later in the week. There are a couple other features (i.e., Windows help book) I'll get to then as well.

[Dan Sebald]

Please give the attached patch a try. It's quite simple; just store the current directory into a static string which is used to set the current directory the next time a file dialog is created.

In addition to that, I've removed the code that appends an extension onto the file name if one isn't present that matches the file type. You might recall this leads to a bug, at least the way I see it. If by adding the extension a file name is created that matches one already existing in the directory, the preexisting file will be overwritten without any prompting yes/no. I do like the idea of appending a file type extension, but unless it can be done (easily) in a foolproof way, I'd just as soon not add an extension.

[Ethan Merritt]

applied - thanks