Re: Proposal: Saving graphs from Qt and wxt terminals

[Daniel J S. <dan...@ie...>]

On 10/31/2014 03:16 PM, Ethan A Merritt wrote:
> On Friday, 31 October, 2014 14:50:18 Daniel J Sebald wrote:
>> On 10/31/2014 02:21 PM, Ethan A Merritt wrote:
>>> On Saturday, 01 November, 2014 03:57:01 Jun T. wrote:
>>>
>>>>   I haven't been following this long thread, but
>>>
>>>>
>>>
>>>>   2014/10/31 09:03, Ethan A Merritt<sf...@us...>  wrote:
>>>
>>>>   >  I added it to cvs for 5.1 but I'd like to hear whether it does or
>>>
>>>>   >  doesn't work on Windows and OSX
>>>
>>>>
>>>
>>>>   I tried cvs HEAD and the Export to File works fine on OSX,
>>>
>>>>   but the Copy to clipboard (pasteboard) button is now gone.
>>>
>>>>   Is it possible to have both?
>>>
>>> I agree. I was hoping that someone, maybe Dan Sebald, can find a
>>>
>>> clever way to make "clipboard" act like a filetype in the selection widget.
>>>
>>>>   When copying the plot to the clipboard, I prefer PDF format rather than
>>>
>>>>   PNG (either on wxt or qt). Is this possible?
>>>
>>> I don't know.
>>
>> I think it would be possible to derive a custom button from the standard
>> button and add a right mouse click handler to the event table.
>
> That's more complicated that I had in mind.

This is actually one of the easier approaches I've come across having 
dug into WXT a bit.


> I was thinking that "clipboard" would be a label in the file-selector widget
> (that part is easy), but unlike the others it would not require a file name
> (that is the part I got stuck on).  I can make it copy to the clipboard just
> fine, but only if I first click on or type some junk file name.

Yeah, the dialog must have some type of filename, otherwise it doesn't 
pass the wxID_OK event further on to the dialog.  Unfortunately, the 
logic for this is in the particular tookkits and not in a generic 
location where one could make an easy change.  Here's GTK, for example:

https://github.com/LuaDist/wxwidgets/blob/master/src/gtk/filedlg.cpp

WXT has a bit of limitation in the sense that it is difficult to program 
in front of a widget operation.  There's access after a widget has done 
something and indicates an event, but not before.  E.g., I'm finding it 
quite difficult to get at the program flow before the "Save" button does 
its file-exists check.


>> How
>> about right mouse click on the clipboard icon opens a dialog or drop
>> down menu that configures the image format saved to file?  To make
>> things more clear, the format, e.g., "png", "pdf", "svg" could be
>> superimposed on the clipboard icon with the format selection.  And maybe
>> change the tool tip to read "Left Click: Copy, Right Click: Configure".
>
> Maybe.  My inclination is that if you want a file then Export-to-File is
> the right thing to look for.  The clipboard is typically used for cut-and-paste,
> and I don't think many program are expected a paste operation to
> contain pdf or svg.

I agree with that.  But there are a number of formats for which 
cut-and-paste will work.


> Or we could just put the Clipboard icon back as a separate widget.
> That is easy but IMHO kind of ugly compared to grouping all the
> export options in a single place.

That was what I was thinking when I queried the discussion list.  The 
clipboard icon would be present, but it could be easily configured for 
the image format.  Copying to clipboard should be a one-step operation. 
  Opening a dialog and then doing another action to copy to clipboard 
seems too much.

But if one were to go that route, maybe adding a third button to the 
file dialog, i.e., "Cancel", "Copy To Clipboard" and "Save" would be the 
most straightforward.  That then is just one additional step (provided 
the file type remains sticky, for which I just about have a patch ready).

Think it over.  I can program something this weekend.

Dan