Re: towards 4.4

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Sunday 07 February 2010, Benjamin Lindner wrote:
>> Tatsuro MATSUOKA wrote:
>>> Hello
>>>
>>> I have tried the patch.
>>>
>>> set term windows enhanced font ",14"
>>> set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
>>> plot sin(x) with linespoints, cos(x) with linespoints
>>>
>>> worked fine!!!!!!!.
>>>
>>>
>>> However,  I have tried
>>> set xrange [-pi:pi]
>>> set yrange [-pi:pi]
>>> splot sin(x*x+y*y)/(x*x+y*y)
>>>
>>> was broken as a attachment file.
>> Thanks for the report.
>>
>> I modified my patch and now I see the expected behaviour
>> with plot (lines + image), splot (surface+pm3d).
> 
> Very good. 
> 
>> I also added the keyboard shortcut Ctrl+C for copying to clipboard.
> 
> Er...
> Ctrl+C is currently documented as having another, quite different meaning.
> True, it apparently isn't working properly under Windows,
> but re-assigning it to "copy to clipboard" further confuses the issue.

Well, actually, for a windows GUI application Ctrl+C means "copy to 
clipboard"
That has been so since I don't know when, and I believe that a decent
GUI application should follow the commonly used basic shortcuts.
Coming from the windows world I find it more confusing if an application
does not follow these "standards".
It's like Ctrl+O meaning "Open", Ctrl+S "save", Ctrl+C 
copy-to-clipboard, Ctrl+V paste-from-clipboard, F1 meaning "help" etc

So having the feature that copies something to clipboard I think it
should have the shortcut Ctrl+C.

I know that in the non-windows world it has a completely different
interpretation, but it's a windows GUI application here, and I think
it should follow windows' behaviour.

> Actually, now that I think about it...
> Is it possible that the reason Ctrl+C is having problems is that
> some layer is trying to interpret it as "copy" at the same time
> another layer is trying to interpret it as "break to command line"?

I can't really tell...

> Should we give up on trying to make Ctrl-C == "break to command line"
> work under Windows?

One has to distinguish *which* application window we are
talking about.
The shortcut I implemented in the patch concerns the graph window only.
The text window (showing the prompt and doing the user-input) has a 
separate keyboard-shortcut handling queue. And Pressing Ctrl+C within
the text window can have a completely different meaning than in the
graph window. And the text window then can be either the console OR 
again a graphical window (for the GUI application).

Pressing Ctrl+C in the GUI-text window currently has no effect, but
pressing ESC bails to the "command line" (as it is a gui application 
there's no real command line in a console sense)
- again like I'd expect from a windows application (yes, talking about 
"standards" again...)

benjamin