gnuplot-beta — Developers and beta testers of new gnuplot code

Re: wxT/Qt framework help book (was Fwd: Re: Last call ...)

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

On 01/02/2015 05:07 AM, Mojca Miklavec wrote:
> On Thu, Jan 1, 2015 at 6:21 AM, Daniel J Sebald wrote:
>> [Sorry, that should have been patch #707 in the last post, i.e.,]
>>
>> I've placed a patch for wxT HelpBook and Qt-Assistant on SourceForge:
>>
>> https://sourceforge.net/p/gnuplot/patches/707
>>
>> which should give anyone interested something to do on New Year's Day.
>>
>> There are also a couple screenshots of the two help book windows after
>> the gnuplot.htb file and the gnuplot.qch and gnuplot.qhc files are made
>> and installed.
>
> Thank you very much. This is an excellent addition (that I have been
> waiting for for a long time already and also tried to implement
> myself, but gave up too soon) and I would be extremely happy if it
> could end up in 5.0.
>
> (I would suggest releasing RC4 with this addition though since
> packagers are expected to modify their build flows slightly and some
> totally unexpected problems might arise there.)
>
> The "next level" would be to allow users to configure "help foo" to
> automatically open the help book, but that doesn't need to be done
> now.

I knew that would eventually be a request.  :-)  The concept doesn't 
appear to violate any gnuplot terminal philosophy, I guess.  It would 
just be issuing a "help xyz" to the terminal.

I think this is possible to do in Qt's case (wxT I don't know about). 
The commands that could be sent to Qt-Assistant are here:

http://doc.qt.io/qt-5/assistant-custom-help-viewer.html#using-qt-assistant-remotely

So, that part is easy.

The tricky part is that there needs to be some type of lookup file, of 
sorts, that translates "xyz" to whatever its reference is in the 
documentation, e.g., "loc432.html".  Where that should be done, I'm not 
sure (inside gnuplot core or inside qt terminal).


> I have problems with an out-of-source build of help files for Qt, but
> wxt help works very nicely.

I sent a separate note on your Qt problem.  SQL library file missing 
would be my guess, but we'll wait to see if anyone else has the same 
issue and knows an easy solution.


> One tiny problem: when I ran help in wxt for the first time, the
> dialogue window appeared. During that time the console was completely
> unresponsive. But maybe that's the expected behaviour anyway.

No, that's not expected.  I'm wondering if there is some type of strange 
bug in the wxT terminal that manifests in different ways on different 
systems.  I've noted some strange behavior (wxT terminals are always 
persistent, once in a while crashes on exit), which still exists in the 
5.1 development version.

Dan

Thanks! (was: Gnuplot version 5.0 is now available)

[Philipp K. J. <ja...@ie...>]

That's exciting news - many thanks to Ethan and
the development team!

Best,

		Ph.



On Fri, 02 Jan 2015 10:15:33 -0800
Ethan A Merritt <sf...@us...> wrote:

> Gnuplot version 5.0 is now available.
> 
> Release Notes here:
> 
>     http://gnuplot.sourceforge.net/ReleaseNotes_5_0.html
> 
> Source tarball and MSWin 32-bit binaries can be downloaded here:
> 
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.0/
> 
> 	Happy New Year
> 	     and
> 	Happy gnuplotting

Gnuplot version 5.0 is now available

[Ethan A M. <sf...@us...>]

Gnuplot version 5.0 is now available.

Release Notes here:

    http://gnuplot.sourceforge.net/ReleaseNotes_5_0.html

Source tarball and MSWin 32-bit binaries can be downloaded here:

    https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.0/

	Happy New Year
	     and
	Happy gnuplotting
-- 
Ethan Merritt (sf...@us...)
on behalf of the gnuplot development team

Re: wxT/Qt framework help book (was Fwd: Re: Last call ...)

[Mojca M. <moj...@gm...>]

On Thu, Jan 1, 2015 at 6:21 AM, Daniel J Sebald wrote:
> [Sorry, that should have been patch #707 in the last post, i.e.,]
>
> I've placed a patch for wxT HelpBook and Qt-Assistant on SourceForge:
>
> https://sourceforge.net/p/gnuplot/patches/707
>
> which should give anyone interested something to do on New Year's Day.
>
> There are also a couple screenshots of the two help book windows after
> the gnuplot.htb file and the gnuplot.qch and gnuplot.qhc files are made
> and installed.

Thank you very much. This is an excellent addition (that I have been
waiting for for a long time already and also tried to implement
myself, but gave up too soon) and I would be extremely happy if it
could end up in 5.0.

(I would suggest releasing RC4 with this addition though since
packagers are expected to modify their build flows slightly and some
totally unexpected problems might arise there.)

The "next level" would be to allow users to configure "help foo" to
automatically open the help book, but that doesn't need to be done
now.

I have problems with an out-of-source build of help files for Qt, but
wxt help works very nicely.

One tiny problem: when I ran help in wxt for the first time, the
dialogue window appeared. During that time the console was completely
unresponsive. But maybe that's the expected behaviour anyway.

Mojca

Re: Last call for issues affecting release of gnuplot 5.0

[Christoph B. <us...@be...>]

Am 29.12.2014 um 19:27 schrieb sfeam:
 >>
 >> 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.

Some time ago, Philipp K. Janert tested the `set multiplot margins`
feature which showed some problems, see
https://sourceforge.net/p/gnuplot/mailman/message/33012645/. I tried to
fix those problems and posted a patch,
https://sourceforge.net/p/gnuplot/patches/713/

This should fix some of the issues (spacing and margin must be used
together, allow value to be given as screen or character units, improved
documentation, adapted value order of the margins option to match that
of `set margins`).
But I couldn't test it thorougly.

Best,
Christoph

Re: wxT/Qt framework help book (was Fwd: Re: Last call ...)

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

[Sorry, that should have been patch #707 in the last post, i.e.,]

I've placed a patch for wxT HelpBook and Qt-Assistant on SourceForge:

https://sourceforge.net/p/gnuplot/patches/707

which should give anyone interested something to do on New Year's Day.

There are also a couple screenshots of the two help book windows after 
the gnuplot.htb file and the gnuplot.qch and gnuplot.qhc files are made 
and installed.

Dan


> -------- Original Message --------
> Subject: Re: Last call for issues affecting release of gnuplot 5.0
> Date: Mon, 29 Dec 2014 14:48:04 -0600
> From: Daniel J Sebald<dan...@ie...>
> To: sf...@us...
> CC: gnu...@li...
>
> On 12/29/2014 02:31 PM, sfeam wrote:
>> And why would you want to view it in anything other than your
>> normal preferred browser?
>
> The Help Book/Qt-Assistant format is much faster than a typical browser,
> it's a little better packaged in a way, and it doesn't require a browser
> be running.
>
> What I've done, in the case that the gnuplot.htb (Help Book) or
> gnuplot.qhc (Qt-Assistant help collection) is allow for the normal HTML
> code to be viewed in a wxWidgets or Qt window.  Both of those frameworks
> support HTML code natively.  So again, no browser is needed to use the
> HTML help for those two terminals.

wxT/Qt framework help book (was Fwd: Re: Last call ...)

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

I've placed a patch for wxT HelpBook and Qt-Assistant on SourceForge:

https://sourceforge.net/p/gnuplot/patches/704

which should give anyone interested something to do on New Year's Day.

There are also a couple screenshots of the two help book windows after 
the gnuplot.htb file and the gnuplot.qch and gnuplot.qhc files are made 
and installed.

Dan

-------- Original Message --------
Subject: Re: Last call for issues affecting release of gnuplot 5.0
Date: Mon, 29 Dec 2014 14:48:04 -0600
From: Daniel J Sebald <dan...@ie...>
To: sf...@us...
CC: gnu...@li...

On 12/29/2014 02:31 PM, sfeam wrote:
> And why would you want to view it in anything other than your
> normal preferred browser?

The Help Book/Qt-Assistant format is much faster than a typical browser,
it's a little better packaged in a way, and it doesn't require a browser
be running.

What I've done, in the case that the gnuplot.htb (Help Book) or
gnuplot.qhc (Qt-Assistant help collection) is allow for the normal HTML
code to be viewed in a wxWidgets or Qt window.  Both of those frameworks
support HTML code natively.  So again, no browser is needed to use the
HTML help for those two terminals.

Re: Last call for issues affecting release of gnuplot 5.0

[sfeam <sf...@us...>]

On Wednesday, 31 December 2014 09:53:22 AM Bastian Märkisch wrote:
> > The code changes to files in .../src/win have not been tested at all
> > by me.  Please confirm that they at least compile under MSWin!
> > It would of course be even better if they do in fact fix the
> > "pause mouse" issues.
> >
> 
> I have checked in another fragment for the wxt terminal which is 
> referenced by the code in src/win/wpause.c. Now it compiles fine. Using 
> wgnuplot, bug #1432 is resolved for wxt and windows (but not for qt and 
> caca - as expected), bug #1502 is resolved for qt, windows and wxt. 

You are referring to this bit, right?

+TBOOLEAN wxt_active_window_opened(void)
+{
+       return ((wxt_current_window != NULL) &&
+               (wxt_current_window->id == wxt_window_number) &&
+                wxt_current_window->frame->IsShown());
+}

I hope that works correctly.  It looks very similar to the malfunctioning
bit in wxt3.0 that was causing problems on linux.  The issue in that
case was that frame->IsShownOnScreen() does not act as documented;
it can return true even if the window is not currently shown.  So far
as I can tell, a correct description of the routine is something like
"returns true if a request to display the frame has previously been
registered".  In other words, it only means that the window was
requested - not that it actually was drawn and is currently visible.
I think frame->IsShown() offers an even weaker guarantee than 
frame->IsShownOnScreen().

If the same is true for the wx implementation on Windows,
you might still get stuck waiting for a mouse event in a window that
was never actually drawn to the screen for some reason.

	Ethan

Re: Last call for issues affecting release of gnuplot 5.0

[Bastian M. <bma...@we...>]

Am 31.12.2014 um 06:15 schrieb sfeam:
> ======================
> "pause mouse" on MSWin
> ======================
>
> On Tuesday, 30 December 2014 08:42:16 PM Bastian Märkisch wrote:
>>>
>>> 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
>
> I have back-ported code fragments from 5.1 that seem to cover the same
> ground as the patch attached to #1502.  As you say, the code in 5.1 does
> not really match what was in this patch.
>
> The code changes to files in .../src/ look correct to my eye and have
> been compile tested under linux.   This of course does not prove that
> they work correctly under MSWin, though I'm pretty sure they correctly
> reproduce what is currently in 5.1
>
> The code changes to files in .../src/win have not been tested at all
> by me.  Please confirm that they at least compile under MSWin!
> It would of course be even better if they do in fact fix the
> "pause mouse" issues.
>

I have checked in another fragment for the wxt terminal which is 
referenced by the code in src/win/wpause.c. Now it compiles fine. Using 
wgnuplot, bug #1432 is resolved for wxt and windows (but not for qt and 
caca - as expected), bug #1502 is resolved for qt, windows and wxt. I 
will shortly upload a testing binary to
http://www.gnuplot.info/development/binaries/


> This is already far more last-minute fiddling than I am comfortable
> with, so I am not touching anything else in this area even if it is
> related (e.g. caca.trm).
>
>   $ diffstat core_portion_of_windows_bugfix_1432_1502.patch \
>              win_portion_of_windows_bugfix_1432_1502.patch
>   src/win/wgnuplib.h |    1
>   src/win/wgraph.c   |   44 +++++++++++++++---
>   src/win/winmain.c  |   11 +++-
>   src/win/wpause.c   |  103 +++++++++++++++++++++++++++++++++----------
>   src/command.c      |  107 +++++++++++++--------------------------------
>   src/command.h      |    5 --
>   src/mouse.c        |   23 +--------
>   src/mousecmn.h     |    6 +-
>   src/plot.c         |    3 -
>   src/term.c         |   15 ++++--
>   11 files changed, 181 insertions(+), 141 deletions(-)
>

(snip)


> ==========================
> Default terminal for MSWin
> ==========================
>
> Bastian Märkisch wrote:
>> 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.
>
> Karl Ratzsch <ra...@un...> wrote:
>> I´ve been using the 5.0-rc/5.1 windows binaries with wxt (both from
>> Tatsuro (64bit,wxt30) and sf.net/homebuilt (32bit, wxt28)) for half
>> a year now at work, with no apparent problems.
>> wxt probably is a safer bet, for now.
>
> I have no opinion here.
> Do Tatsuro Matsuoka's binaries support both?

Yes, Tatsuro's (and my) binaries do support both. Note that the qt 
terminal only works on Windows since mid June. I propose to change the 
order on Windows in term.c, see the attached patch.

   Bastian


>
>
> 	Ethan
>
>

Re: Last call for issues affecting release of gnuplot 5.0

[sfeam <sf...@us...>]

======================
"pause mouse" on MSWin
======================

On Tuesday, 30 December 2014 08:42:16 PM Bastian Märkisch wrote:
> >
> > 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

I have back-ported code fragments from 5.1 that seem to cover the same
ground as the patch attached to #1502.  As you say, the code in 5.1 does
not really match what was in this patch.

The code changes to files in .../src/ look correct to my eye and have
been compile tested under linux.   This of course does not prove that
they work correctly under MSWin, though I'm pretty sure they correctly
reproduce what is currently in 5.1

The code changes to files in .../src/win have not been tested at all
by me.  Please confirm that they at least compile under MSWin!
It would of course be even better if they do in fact fix the 
"pause mouse" issues.

This is already far more last-minute fiddling than I am comfortable
with, so I am not touching anything else in this area even if it is
related (e.g. caca.trm).

 $ diffstat core_portion_of_windows_bugfix_1432_1502.patch \
            win_portion_of_windows_bugfix_1432_1502.patch 
 src/win/wgnuplib.h |    1 
 src/win/wgraph.c   |   44 +++++++++++++++---
 src/win/winmain.c  |   11 +++-
 src/win/wpause.c   |  103 +++++++++++++++++++++++++++++++++----------
 src/command.c      |  107 +++++++++++++--------------------------------
 src/command.h      |    5 --
 src/mouse.c        |   23 +--------
 src/mousecmn.h     |    6 +-
 src/plot.c         |    3 -
 src/term.c         |   15 ++++--
 11 files changed, 181 insertions(+), 141 deletions(-)


================
"update" command
================

Karl Ratzsch <ra...@un...> wrote:
> The "update" command
> 
>   http://sourceforge.net/p/gnuplot/bugs/1385/
> 
> might still need a change that is not backward-compatible, although
> i´d wager nobody would ever notice ;-).

I tried reverting the version 5.0 code to match 4.6.6
It didn't work (segfaults).
I am absolutely not going to fiddle with it this point even though it is
known to be broken.  The Release Notes now state:

* The "update" command for use with "fit" does not work as documented, and 
  in practice works differently on different platforms.  Use with caution.
  This command will probably be revised for subsequent gnuplot releases.

==========================
Default terminal for MSWin
==========================

Bastian Märkisch wrote:
> 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.

Karl Ratzsch <ra...@un...> wrote:
> I´ve been using the 5.0-rc/5.1 windows binaries with wxt (both from
> Tatsuro (64bit,wxt30) and sf.net/homebuilt (32bit, wxt28)) for half
> a year now at work, with no apparent problems.
> wxt probably is a safer bet, for now.

I have no opinion here.  
Do Tatsuro Matsuoka's binaries support both?


	Ethan

Re: Last call for issues affecting release of gnuplot 5.0

[sfeam <sf...@us...>]

On Tuesday, 30 December 2014 09:40:57 PM Karl Ratzsch wrote:
> On 30.12.2014 19:45, sfeam wrote:
> > 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.   
> 
> Those "Glib-Critical" warnings
> (see  http://sourceforge.net/p/gnuplot/bugs/1401 )
> still appear on my system with wxgtk30/glib2.42,

Those messages do not come from gnuplot.

That is, of course they are an indirect result of running gnuplot
but it seems they indicate a non-fatal status check inside glib itself.

See for example this thread:

 http://stackoverflow.com/questions/23199699/glib-critical-source-id-xxx-was-not-found-when-attempting-to-remove-it

The warning message was introduced by this change to glib:

 https://git.gnome.org/browse/glib/commit/?id=a919be3d39150328874ff647fb2c2be7af3df996


> sometimes (once in fifty plots or so, not really reproducible) the
> terminal window gets filled in grey, no plot, no menubar. That is on
> xubuntu 14.10.


Hmm.  That's not much to work with as a symptom.
Does this happen immediately on startup, or when you're in the middle
of plotting, or what?

	Ethan

Re: Last call for issues affecting release of gnuplot 5.0

[Karl R. <ra...@un...>]

On 30.12.2014 19:45, sfeam wrote:
> 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.   

Those "Glib-Critical" warnings
(see  http://sourceforge.net/p/gnuplot/bugs/1401 )
still appear on my system with wxgtk30/glib2.42, and I noticed that
sometimes (once in fifty plots or so, not really reproducible) the
terminal window gets filled in grey, no plot, no menubar. That is on
xubuntu 14.10.

>>> 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.

I´ve been using the 5.0-rc/5.1 windows binaries with wxt (both from
Tatsuro (64bit,wxt30) and sf.net/homebuilt (32bit, wxt28)) for half
a year now at work, with no apparent problems.

wxt probably is a safer bet, for now.

  Karl




-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum, Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg i. Br.
Tel.: 0761/203-4748 Fax: -4701

Re: Last call for issues affecting release of gnuplot 5.0

[Bastian M. <bma...@we...>]

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
>

Re: Last call for issues affecting release of gnuplot 5.0

[sfeam <sf...@us...>]

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

> >     * 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)

> >     * '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?

> >     * '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}

> >     * 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.

> 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.
> >
> >     Bastian

The patch for #1502 (and #1432?) touches more code than I am happy with
for a change at this late date.

$ 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?


	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

Re: Last call for issues affecting release of gnuplot 5.0

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

On 12/30/2014 03:55 AM, Bastian Märkisch wrote:
> 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.
>     * Raising the console window by pressing "space" does not work
>       (Bug #1432).
>     * 'pause mouse' does not work (fix in 5.1, see Bug 1502).
>     * 'pause mouse' hangs gnuplot if no plot window is open (Bug #1434).
>     * In contrast to wxt or windows, the qt terminal is missing an
>       option to raise the window when a plot is finished.
>     * 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.)

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.

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.
>
>     Bastian
>
>
> 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

Re: Last call for issues affecting release of gnuplot 5.0

[Bastian M. <bma...@we...>]

There's a fix pending for "pause mouse" on Windows. It has been in 5.1 
now for a while, but has not been applied to 5.0 yet. More info can be 
found in the bug trackers
https://sourceforge.net/p/gnuplot/bugs/1502/
and
https://sourceforge.net/p/gnuplot/bugs/1434/

Support for the qt terminal is still incomplete and there remain issues 
with wxt for console mode gnuplot.

   Bastian

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

Re: Last call for issues affecting release of gnuplot 5.0

[Bastian M. <bma...@we...>]

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.
   * Raising the console window by pressing "space" does not work
     (Bug #1432).
   * 'pause mouse' does not work (fix in 5.1, see Bug 1502).
   * 'pause mouse' hangs gnuplot if no plot window is open (Bug #1434).
   * In contrast to wxt or windows, the qt terminal is missing an
     option to raise the window when a plot is finished.
   * 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.)

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.

   Bastian


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
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Last call for issues affecting release of gnuplot 5.0

[Ethan M. <merritt@u.washington.edu>]

On Monday, 29 December 2014 09:53:27 PM Karl Ratzsch wrote:
> The "update" command
> 
> http://sourceforge.net/p/gnuplot/bugs/1385/
> 
> might still need a change that is not backward-compatible, although
> i´d wager nobody would ever notice ;-).

Urk.  I let that one slip.  Thanks for pointing it out.

The version of "update" in both 5.0 and 5.1 simply doesn't work,
for the reasons given in the bug tracker.

Back in September I reverted the equivalent broken code for 4.6.6
to the previous long-standing version used through 4.6.5.
The idea was to fix it properly for version 5 but that never happened.

I'll think about this overnight, but probably it's too late
to do anything other than revert the code in gnuplot 5.0 also.
That will make "update" will behave exactly as it did in gnuplot 4.6,
buggy or not.  Better to have backwards compatibility with quirks
than to have neither backwards compatibility nor working code.

> I´d propose to make it always overwrite the ".old" backup file
> (which is the (unintended) behaviour on linux now, but not e.g.
> windows).

Unfortunately the behaviour on linux now is that it cannot even find
the old file reliably, because the existfile() routine knows nothing
about search paths.  So it always writes a new file in the current
directory, regardless of whether that was wanted.

	Ethan

> 
> 
> (And while at it:)
> fit.c contains an stale variant for the case when the parameter file
> does not exist and no previous fit was done. Should the file with
> all parameters marked FIXED be written or not? I´d vote for the
> former. It seems rather arbitrary to deny it.
> ==fit.c:1521==
> #if 1
> Eex2("'update' requires a prior 'fit' since the parameter file %s
> does not exist yet.", ofilename);
> #else
> fprintf(stderr, "'update' without a prior 'fit' and without a
> previous parameter file:\n");
> fprintf(stderr, " all variables will be marked '# FIXED'!\n");
> #endif
> =========
> 
>   Karl
> 
> 
> On 29.12.2014 19:27, sfeam wrote:
> > 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
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming! The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> > 
> 
> 

-- 
mail:   Biomolecular Structure Center,  K-428 Health Sciences Bldg
        MS 357742,   University of Washington, Seattle 98195-7742

Re: Last call for issues affecting release of gnuplot 5.0

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

On 12/29/2014 02:31 PM, sfeam wrote:
> On Monday, 29 December 2014 12:39:27 PM Daniel J Sebald wrote:
>> On 12/29/2014 12:27 PM, sfeam wrote:
>>> 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
>>
>> Are some of the recent WXT/Qt mods going to be in 5.0?  Or is that 5.1?
>
> wxt -definitely.  This was one of the major items holding up release of 5.0
>
> qt - not sure what you have in mind.
>       There is not yet any divergence between qt in 5.0 and 5.1
>
>> I'm very close to completing HTML documentation and help manuals (i.e.,
>> Help Book and Qt-Assistant) for those terminals.
>
> Not sure I'm in favor of this.
> I don't really see the point.
> If you want html documentation, why would it be terminal-specific?

The Help Book format is something that Bastian attempted and requested 
integrated into wxWidgets terminal.  It takes the gnuplot Doc material 
and formats it so that it can be used in the common Windows Help Book 
viewer.  You may have not seen that utility, and I don't use it too 
often, but it presents the documentation with a TOC on the left window 
with quick access to any of the topics.

Qt has something that duplicates that utility called Qt-Assistant.  It 
looks very much the same, but has the added feature of being able to 
search the documentation.


> And why would you want to view it in anything other than your
> normal preferred browser?

The Help Book/Qt-Assistant format is much faster than a typical browser, 
it's a little better packaged in a way, and it doesn't require a browser 
be running.

What I've done, in the case that the gnuplot.htb (Help Book) or 
gnuplot.qhc (Qt-Assistant help collection) is allow for the normal HTML 
code to be viewed in a wxWidgets or Qt window.  Both of those frameworks 
support HTML code natively.  So again, no browser is needed to use the 
HTML help for those two terminals.

Go forward with 5.0.  This can be evaluated for 5.1.

Dan

PS: Very nice having the option for "build" in a completely different 
directory from the source tree.  Can keep all the object files in some 
different account/location that isn't backed up.

Re: Last call for issues affecting release of gnuplot 5.0

[Karl R. <ra...@un...>]

The "update" command

http://sourceforge.net/p/gnuplot/bugs/1385/

might still need a change that is not backward-compatible, although
i´d wager nobody would ever notice ;-).

I´d propose to make it always overwrite the ".old" backup file
(which is the (unintended) behaviour on linux now, but not e.g.
windows).


(And while at it:)
fit.c contains an stale variant for the case when the parameter file
does not exist and no previous fit was done. Should the file with
all parameters marked FIXED be written or not? I´d vote for the
former. It seems rather arbitrary to deny it.
==fit.c:1521==
#if 1
Eex2("'update' requires a prior 'fit' since the parameter file %s
does not exist yet.", ofilename);
#else
fprintf(stderr, "'update' without a prior 'fit' and without a
previous parameter file:\n");
fprintf(stderr, " all variables will be marked '# FIXED'!\n");
#endif
=========

  Karl


On 29.12.2014 19:27, sfeam wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum, Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg i. Br.
Tel.: 0761/203-4748 Fax: -4701

Re: Last call for issues affecting release of gnuplot 5.0

[sfeam <sf...@us...>]

On Monday, 29 December 2014 12:39:27 PM Daniel J Sebald wrote:
> On 12/29/2014 12:27 PM, sfeam wrote:
> > 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
> 
> Are some of the recent WXT/Qt mods going to be in 5.0?  Or is that 5.1?

wxt -definitely.  This was one of the major items holding up release of 5.0

qt - not sure what you have in mind.
     There is not yet any divergence between qt in 5.0 and 5.1

> I'm very close to completing HTML documentation and help manuals (i.e., 
> Help Book and Qt-Assistant) for those terminals.  

Not sure I'm in favor of this.
I don't really see the point.
If you want html documentation, why would it be terminal-specific?
And why would you want to view it in anything other than your
normal preferred browser?

	Ethan


> Looks nice.  I should 
> have a version done in the next couple days, but review/testing will 
> probably take a week because there are some installations for the 
> manuals and we'd need to make sure it works on all developers' systems.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Last call for issues affecting release of gnuplot 5.0

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

On 12/29/2014 12:27 PM, sfeam wrote:
> 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

Are some of the recent WXT/Qt mods going to be in 5.0?  Or is that 5.1?

I'm very close to completing HTML documentation and help manuals (i.e., 
Help Book and Qt-Assistant) for those terminals.  Looks nice.  I should 
have a version done in the next couple days, but review/testing will 
probably take a week because there are some installations for the 
manuals and we'd need to make sure it works on all developers' systems.

Dan

Last call for issues affecting release of gnuplot 5.0

[sfeam <sf...@us...>]

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

Re: autotools update

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

On 12/16/2014 05:00 PM, Hans-Bernhard Bröker wrote:
> Hello all,
>
> I went ahead and committed the auto tools update mentioned in two
> earlier discussions.  The only major difference you're likely to notice
> is that configure.in has been renamed configure.ac.  CVS doesn't really
> support file renames, so this had to be done by adding the new and
> dropping the old.

I've tested by doing the --without-lua, --with-lua configuration and 
things work as planned:

[sebald@ ~]$ gnuplot

	G N U P L O T
	Version 5.1 patchlevel 0    last modified 2014-12-16
[snip]
gnuplot> help tikz
Sorry, no help for 'tikz'
gnuplot> exit
[sebald@ ~]$ gnuplot

	G N U P L O T
	Version 5.1 patchlevel 0    last modified 2014-12-16
[snip]
gnuplot> help tikz
  This driver creates output for use with the TikZ package of graphics 
macros
  in TeX.  It is currently implemented via an external lua script, and
  `set term tikz` is a short form of the command `set term lua tikz`.
  See `term lua` for more information.  Use the command `set term tikz help`
  to print terminal options.

Thanks,

Dan

autotools update

[Hans-Bernhard B. <HBB...@t-...>]

Hello all,

I went ahead and committed the auto tools update mentioned in two 
earlier discussions.  The only major difference you're likely to notice 
is that configure.in has been renamed configure.ac.  CVS doesn't really 
support file renames, so this had to be done by adding the new and 
dropping the old.

The other noticable effect is that the test for RETSIGTYPE was removed, 
so its value is now fixed to its former default value of 'void' from 
syscfg.h.  We could s/RETSIGTYPE/void/g later, but for now, the existing 
definition works as well.

HBB