|
From: Bastian M. <bma...@we...> - 2014-12-30 19:42:31
|
Am 30.12.2014 um 19:45 schrieb sfeam:
> On Tuesday, 30 December 2014 11:06:34 AM Daniel J Sebald wrote:
>> On 12/30/2014 03:55 AM, Bastian Märkisch wrote:
>
> Thanks for the list
>
>>> Version 5.0 will be the first to have the qt terminal on Windows. While
>>> it works very well and is very fast, it still has some issues - or
>>> behaves notably different from the windows and wxt terminals:
>>>
>>> * 'raise' and 'lower' commands have no effect.
>
> raise/lower is not implemented in qt (i.e. this is not Windows-specific)
>
> -> won't fix for 5.0
>
OK. So it's an item for the release notes.
>>> * Raising the console window by pressing "space" does not work
>>> (Bug #1432).
>
> As per earlier discussion, I really think think this functionality belongs
> in the core code rather than being scattered around individual terminal
> drivers. Actually in truth I think the functionality is undesirable;
> I always build with ./configure --disable-raise-console.
> See for example the comment attached to bug #1434 where
> "space raises console rather than terminating pause mouse" is interpreted
> as a bug.
>
> -> won't fix for 5.0 (remains on wish-list for future work)
>
As discussed before, opinions on whether this is a useful feature or not
differ. Personally, I do sorely miss it if it's not there. It really
annoys me to "tab-cycle" between the plot window and the terminal window.
Anyway, point is that that feature is missing and (some) people consider
this a bug.
The problem on Windows is that this is not easy to implement. Because
the qt graph window has it's own process, Windows considers the gunplot
process an "inactive" process, which is not allowed to change its
z-order. Neither may another process (gnuplot_qt) change the z-order of
a window of the parent process.
>>> * 'pause mouse' does not work (fix in 5.1, see Bug 1502).
>
> #1502 is marked "closed - fixed".
> Is the patch attached to it suitable for 5.0?
Yes it is. But it is sizeable as you note below. The reason it only
went into 5.1 was that I wanted to see it tested there before.
>
>>> * 'pause mouse' hangs gnuplot if no plot window is open (Bug #1434).
>
> Is this fixed by the same patch as #1502?
>
>>> * In contrast to wxt or windows, the qt terminal is missing an
>>> option to raise the window when a plot is finished.
>
> That's not correct: set term qt {raise|noraise}
Oh. I missed that. But it is not working on Windows and the default is
different from wxt and windows terminals. The issue is not
straightforward to fix.
>>> * Since qt is an outboard driver, 'persist' works like on other
>>> platforms, whereas for the wxt and windows terminal 'persist'
>>> is only emulated by keeping the input loop running. (Note that
>>> "fork" is not available.)
>
> Same on all platforms, right? So this isn't a bug, it's just a
> difference among terminal types.
>
No, it's not a bug - rather an improvement - but a considerable change
in behaviour of the default terminal. Plus, so far none of the
iteractive terminals on Windows (wxt / windows) offered that.
>> I've seen some bugs appearing in WXT in the development code, by my
>> estimate after 5.0. The types of bugs I'm seeing are
>> persistent-terminal-when-shouldn't-be, crashing on exit. I can
>> investigate a few of those if you want to do a code sprint and clear out
>> some bugs. I'm a bit reluctant to attempt a fix on the persistent
>> issues for WXT, though, because of its non outboard nature. Might be
>> hard to fix without some other issue appearing, but I could be wrong.
>
> I think the last major wxWidgets + wxgtk 3.0 bug got squashed just
> 10 days ago. So if you have not tested since then, please give it
> another try.
>
>> Dan
>>
>>> As it is, "qt" will now be the default terminal on Windows. We should
>>> discuss if this should really stay that way. At least this change and
>>> the known issues should be mentioned in the release notes. Please also
>>> note that most Windows users will use the binaries provided.
>>>
So, what's the opinion on letting wxt be the default terminal on
Windows? This would be the "least surprise" option.
>>> Bastian
>
> The patch for #1502 (and #1432?) touches more code than I am happy with
> for a change at this late date.
Understood, see above. Looking at the amazing new games demos, it would
be a shame to add a "pause mouse on Windows broken" line to the release
notes, wouldn't it? Note that the actual submit to 5.1 differs a bit
from the last patch file (do not remember details). It (mostly) fixes
#1502 and #1432.
Bastian
>
> $ diffstat windows-pausemouse-2.patch
>
> src/command.c | 101 ++++++++++----------------------
> src/command.h | 5 -
> src/mouse.c | 31 +++++----
> src/mousecmn.h | 6 -
> src/plot.c | 3
> src/qtterminal/qt_term.cpp | 35 +++++------
> src/term.c | 13 ++--
> src/win/wgraph.c | 50 +++++++++++++---
> src/win/winmain.c | 23 ++++---
> src/win/wpause.c | 140 +++++++++++++++++++++++----------------------
> src/win/wtext.c | 9 ++
> term/caca.trm | 89 ++++++++++++++++++----------
> 12 files changed, 277 insertions(+), 228 deletions(-)
>
> Some of this is white-space cleanup.
> I will extract and apply the sanity check for qt_atexit() cleanup.
>
> How much of the rest is really needed for 5.0?
>
Most of it really.
>
> Ethan
>
>>>
>>>
>>> Am 29.12.2014 um 19:27 schrieb sfeam:
>>>> Hi all,
>>>>
>>>> I plan to package up gnuplot 5.0 and place the tarball on SourceForge
>>>> for release on New Year's Day. If you know of any remaining issues
>>>> that should be either fixed or mentioned in the Release Notes, please
>>>> post them here on the mailing list.
>>>>
>>>> The current text of the Release Notes is here:
>>>>
>>>> http://gnuplot.sourceforge.net/ReleaseNotes_5_0.html
>>>>
>>>> Ethan
>
|