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

Re: C++ in gnuplot

[Jun T. <tak...@kb...>]

On 2015/12/09, at 19:41, Mojca Miklavec <moj...@gm...> wrote:
> qtterminal/qt_conversion.cpp:129:9: error: use of undeclared
> identifier 'isnan'; did you mean 'std::isnan'?
>                                if (isnan(*image))
>                                    ^~~~~
>                                    std::isnan
> 
> which I can fix by changing isnan to std::isnan,

If I set
    export CC=clang CXX=clang++
    export CXXFLAGS='-std=c++11 -stdlib=libc++'
then I don't need to modify any source files (OS X 10.8, Qt5).

Do you get the isnan error even with this CXXFLAGS?

BTW, how did you install Qt5? I'm using the binary distribution
from http://www.qt.io/download-open-source/.

Expecting support for multiple keys and multiple files.

[Liu G. <goo...@gm...>]

I expect that gnuplot can support multiple keys and multiple files:

<1>.  Multiple keys

I expect that the keys (legends) can be manipulated in groups in stead 
of as a whole objects.

e.g.

set key 1 top right
set key 2 bottom left
plot 'data' t 't1a' key 1, '' t 't1b' key 1, '' t 't2a' key 2, '' t 
't2b' key 2

Thus, if I have many legends and there's no space to put them together, 
I can divide them into two groups
"key 1" and "key 2" and put them at different places.


<2>. Multiple files

Columns from different files can be calculated together. e.g. I have two 
files that have the same format, say, 100 row of (x, y) data, named 
'file1' and 'file2'. Now I want to plot the different between y columns 
from the two files.

plot 'file1' u 1:($2-column('file2',2)) w lp

Re: C++ in gnuplot

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

Am 09.12.2015 um 19:35 schrieb Mojca Miklavec:
> On 9 December 2015 at 16:23, Hans-Bernhard Bröker wrote:

>> But there are more problems waiting
>> to be found, including lots of unresolved reference into QString.
>
> For me the rest worked out of the box.

Interesting.  This gave me reason to re-examine the root cause of these 
problems.  Turns out that (at least on this platform), the only change 
needed to get it to build was adding "-fno-exceptions" to the CXXFLAGS.

Now I'm stuck at the old "Could not connect to existing gnuplot_qt, 
starting a new one", and "Warning: slow font initialization" nuisance. 
But since that's the same between GCC and clang builds, I'll chalk that 
on up to Qt itself.

>>> but the program crashes anyway (on exit at least) if I don't compile
>>> it against libc++ (rather than libstdc++).

"Crashes" is rather a small amount of information.  Could you dig a 
little deeper, preferrably using the debugger?

Re: C++ in gnuplot

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

Am 09.12.2015 um 20:52 schrieb pl...@pi...:

> There is a compiler switch in gcc to force only stdc syntax, IIRC
>
> -std=c99
>
> This should flush out any C11 specific code as errors. I think that is
> what you are trying to do.

All fine and dandy, but completely irrelevant to the issue at hand, 
which deals with C++, not C.

Re: C++ in gnuplot

[<pl...@pi...>]

> It's not from a package. It's a standard library that any C++ compiler
> links against.
>
> Mac OS X ships with both libstdc++ and libc++. Only libc++ supports
> C++11, but libstdc++ was the default before version 10.9.
>
> Mojca
>

There is a compiler switch in gcc to force only stdc syntax, IIRC

-std=c99

This should flush out any C11 specific code as errors. I think that is 
what you are trying to do.

If that is not exactly what you need, you will probably find there is 
another switch to turn of C11 specifics that are not in your earlier libc++

Peter

Re: C++ in gnuplot

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

On 9 December 2015 at 16:23, Hans-Bernhard Bröker wrote:
> Am 09.12.2015 um 11:41 schrieb Mojca Miklavec:
>
>> What other libraries for gnuplot (other than Qt and wxWidgets) need C++?
>
>
> Basically none.
>
>> I'm facing some problems when trying to support gnuplot built against
>> Qt 5 on OS X < 10.9.
>
>
> That bodes trouble.  I've seen various levels of incompatibility between
> clang and Qt5 for a while now (on Windows+Cygwin).
>
>>                                  if (isnan(*image))
>>                                      ^~~~~
>>                                      std::isnan
>>
>> which I can fix by changing isnan to std::isnan,
>
>
> That one would be a simple enough fix.  But there are more problems waiting
> to be found, including lots of unresolved reference into QString.

For me the rest worked out of the box.

>> but the program crashes anyway (on exit at least) if I don't compile
>> it against libc++ (rather than libstdc++).
>
> Huh, don't remember having seen that name.  What package does that library
> originate in?

It's not from a package. It's a standard library that any C++ compiler
links against.

Mac OS X ships with both libstdc++ and libc++. Only libc++ supports
C++11, but libstdc++ was the default before version 10.9.

Mojca

Re: C++ in gnuplot

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

Am 09.12.2015 um 11:41 schrieb Mojca Miklavec:

> What other libraries for gnuplot (other than Qt and wxWidgets) need C++?

Basically none.

> I'm facing some problems when trying to support gnuplot built against
> Qt 5 on OS X < 10.9.

That bodes trouble.  I've seen various levels of incompatibility between 
clang and Qt5 for a while now (on Windows+Cygwin).

>                                  if (isnan(*image))
>                                      ^~~~~
>                                      std::isnan
>
> which I can fix by changing isnan to std::isnan,

That one would be a simple enough fix.  But there are more problems 
waiting to be found, including lots of unresolved reference into QString.

> but the program crashes anyway (on exit at least) if I don't compile
> it against libc++ (rather than libstdc++).

Huh, don't remember having seen that name.  What package does that 
library originate in?

C++ in gnuplot

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

Hi,

What other libraries for gnuplot (other than Qt and wxWidgets) need C++?

I'm facing some problems when trying to support gnuplot built against
Qt 5 on OS X < 10.9.

It starts with:

In file included from qtterminal/qt_term.cpp:78:
qtterminal/qt_conversion.cpp:129:9: error: use of undeclared
identifier 'isnan'; did you mean 'std::isnan'?
                                if (isnan(*image))
                                    ^~~~~
                                    std::isnan

which I can fix by changing isnan to std::isnan, but the program
crashes anyway (on exit at least) if I don't compile it against libc++
(rather than libstdc++). I would like to know which other C++
libraries I would have to compile against libc++ if I want to compile
gnuplot against libc++.

Mojca

Re: CVS woes

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

On Mon, 07 Dec 2015 19:53:23 +0100
Christoph Bersch <us...@be...> wrote:

> Am 23.11.2015 um 23:24 schrieb Eric S. Raymond:
> > Allin Cottrell <cot...@wf...>:
> >> Any plans for gnuplot to migrate to git?
> >
> > I still lurk on this list because I offered to do a git conversion a
> > couple years back.  I'm a former GNUPlot contributor and now
> > maintain cvs-fast-export;
> 
> Eric, I remember your former offer, thanks for still lurking here!
> 
> Although I don't think I have a vote, I would really love to see the 
> gnuplot repository migrated to git :)

	+1

> 
> I hope, that the gnuplot maintainers can be convinced to do the
> conversion.
> 
> Christoph
> 
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for
> multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________ gnuplot-beta mailing
> list gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: CVS woes

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

Am 23.11.2015 um 23:24 schrieb Eric S. Raymond:
> Allin Cottrell <cot...@wf...>:
>> Any plans for gnuplot to migrate to git?
>
> I still lurk on this list because I offered to do a git conversion a
> couple years back.  I'm a former GNUPlot contributor and now maintain
> cvs-fast-export;

Eric, I remember your former offer, thanks for still lurking here!

Although I don't think I have a vote, I would really love to see the 
gnuplot repository migrated to git :)

I hope, that the gnuplot maintainers can be convinced to do the conversion.

Christoph

Re: qt error trapping

[<pl...@pi...>]

On 30/11/15 08:30, Daniel J Sebald wrote:
> On 11/30/2015 02:09 AM, pl...@pi... wrote:
>> On 30/11/15 04:01, Daniel J Sebald wrote:
>>> On 11/29/2015 03:38 PM, pl...@pi... wrote:
>>>> Hi,
>>>>
>>>> I just ran current cvs gnuplot while su as another user. This meant
>>>> that
>>>> gnuplot could not find the DISPLAY to connect to. However this failure
>>>> was not correctly ( at all ) trapped and I needed to ^C out to get back
>>>> to the gnupplot prompt.
>>>>
>>>> I would expect it to drop out instantly , preferably with an error
>>>> message.
>>>>
>>>>
>>>> gnuplot> plot [-pi:pi] sin(x)
>>>> QXcbConnection: Could not connect to display
>>>> q
>>>>
>>>> quit
>>>> ^C
>>>> gnuplot>
>>>>
>>>>
>>>> Presumably there are other reasons qt may fail to open the plot window
>>>> and this rather unusual situation probably highlights poor error
>>>> trapping here.
>>>>
>>>> Regards, Peter.
>>>
>>> Please create a bug report on the bug tracker with this message if you
>>> haven't done so already. The Qt terminal is pretty good, but I'm sure
>>> there are some things not done just right. Be sure to repeat what you
>>> are doing with something like the WXT terminal which also uses the
>>> graphics framework, and check if that hangs as well. Thanks.
>>>
>>> If you want to run under the root, there is "su -l" option.
>>>
>>> Dan
>>>
>>
>> Thanks Dan,
>>
>> I tired wxt and threw a seg. fault . However, after rebooting both
>> terminals seem to act correctly. There may have been some libraries
>> still in memory from before a routine update. I probably had not power
>> cycled the machine for about a week and there had been updates.
>>
>> I just tried to repeat this to get more detail and it seems to be
>> trapped correctly:
>>
>>
>> gnuplot> plot [-pi:pi] sin(x)
>> libGL error: failed to open drm device: Permission denied
>> libGL error: failed to load driver: nouveau
>> gnuplot>
>>
>>
>> Unless I see something similar again, I would conclude it was a one-off
>> error, probably due to mixed library modules lurking in memory.
>>
>> Sorry for the noise.
>>
>> Peter.
>
> I don't know what to conclude from that.  The first error
>
>>>> QXcbConnection: Could not connect to display
>
> looks like something that would happen if the gnome (or similar)
> framework is not initialized, as the root has by default.  On the other
> hand, the second case looks like libGL errors.  Nouveau is an
> experimental libGL driver intended for Nvidia cards.
>
> I think I'm able to replicate what you originally saw, just by running
> from root without the -l option.  The error I get is:
>
> Terminal type set to 'qt'
> gnuplot> plot x
> **
> GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed:
> (connection->initialization_error == NULL)
>
> exit
> ^C
> gnuplot> exit
>
> Dan
>

Just to clarify my original error , I was su into a  normal user account 
. Gnuplot works correctly for that user account when logged in directly. 
  Whatever happened before, both qt and wxt are functional in the same 
context now.

I switch user with :  su -  username

I think the error is reproduced by $DISPLAY being undefined.  This is a 
new installation where I have been doing some configuration changes so 
it may well have been that for some reason the user account was not 
properly configured when I initially hit this problem.

I think your 'root without i ' test is also creating a context where 
$DISPLAY is undefined.

Having determined that, it still comes back to some poor error trapping 
that maybe ought to be reviewed.


The libGL errors I'm now getting from qt are a bit odd because both drm 
and nouveau are loaded already. The nouveau driver has been default on 
Fedora for quite a while, it is not really that 'experimental' any more.

modprobe nouveau returns zero ( no error ) so it's odd , firstly that 
something is trying load it at this stage ( Xwindow server running ) and 
secondly that it somehow reports an error when trying.


Again this may be an invitation to check over the error trapping.

Thanks for taking an interest.

Peter.

Re: qt error trapping

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

On 11/30/2015 02:09 AM, pl...@pi... wrote:
> On 30/11/15 04:01, Daniel J Sebald wrote:
>> On 11/29/2015 03:38 PM, pl...@pi... wrote:
>>> Hi,
>>>
>>> I just ran current cvs gnuplot while su as another user. This meant that
>>> gnuplot could not find the DISPLAY to connect to. However this failure
>>> was not correctly ( at all ) trapped and I needed to ^C out to get back
>>> to the gnupplot prompt.
>>>
>>> I would expect it to drop out instantly , preferably with an error
>>> message.
>>>
>>>
>>> gnuplot> plot [-pi:pi] sin(x)
>>> QXcbConnection: Could not connect to display
>>> q
>>>
>>> quit
>>> ^C
>>> gnuplot>
>>>
>>>
>>> Presumably there are other reasons qt may fail to open the plot window
>>> and this rather unusual situation probably highlights poor error
>>> trapping here.
>>>
>>> Regards, Peter.
>>
>> Please create a bug report on the bug tracker with this message if you
>> haven't done so already. The Qt terminal is pretty good, but I'm sure
>> there are some things not done just right. Be sure to repeat what you
>> are doing with something like the WXT terminal which also uses the
>> graphics framework, and check if that hangs as well. Thanks.
>>
>> If you want to run under the root, there is "su -l" option.
>>
>> Dan
>>
>
> Thanks Dan,
>
> I tired wxt and threw a seg. fault . However, after rebooting both
> terminals seem to act correctly. There may have been some libraries
> still in memory from before a routine update. I probably had not power
> cycled the machine for about a week and there had been updates.
>
> I just tried to repeat this to get more detail and it seems to be
> trapped correctly:
>
>
> gnuplot> plot [-pi:pi] sin(x)
> libGL error: failed to open drm device: Permission denied
> libGL error: failed to load driver: nouveau
> gnuplot>
>
>
> Unless I see something similar again, I would conclude it was a one-off
> error, probably due to mixed library modules lurking in memory.
>
> Sorry for the noise.
>
> Peter.

I don't know what to conclude from that.  The first error

>>> QXcbConnection: Could not connect to display

looks like something that would happen if the gnome (or similar) 
framework is not initialized, as the root has by default.  On the other 
hand, the second case looks like libGL errors.  Nouveau is an 
experimental libGL driver intended for Nvidia cards.

I think I'm able to replicate what you originally saw, just by running 
from root without the -l option.  The error I get is:

Terminal type set to 'qt'
gnuplot> plot x
**
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: 
(connection->initialization_error == NULL)

exit
^C
gnuplot> exit

Dan

Re: qt error trapping

[<pl...@pi...>]

On 30/11/15 04:01, Daniel J Sebald wrote:
> On 11/29/2015 03:38 PM, pl...@pi... wrote:
>> Hi,
>>
>> I just ran current cvs gnuplot while su as another user. This meant that
>> gnuplot could not find the DISPLAY to connect to. However this failure
>> was not correctly  ( at all ) trapped and I needed to ^C out to get back
>> to the gnupplot prompt.
>>
>> I would expect it to drop out instantly , preferably with an error
>> message.
>>
>>
>> gnuplot>  plot [-pi:pi] sin(x)
>> QXcbConnection: Could not connect to display
>> q
>>
>> quit
>> ^C
>> gnuplot>
>>
>>
>> Presumably there are other reasons qt may fail to open the plot window
>> and this rather unusual situation probably highlights poor error
>> trapping here.
>>
>> Regards, Peter.
>
> Please create a bug report on the bug tracker with this message if you
> haven't done so already.  The Qt terminal is pretty good, but I'm sure
> there are some things not done just right.  Be sure to repeat what you
> are doing with something like the WXT terminal which also uses the
> graphics framework, and check if that hangs as well.  Thanks.
>
> If you want to run under the root, there is "su -l" option.
>
> Dan
>

Thanks Dan,

I tired wxt and threw a seg. fault .  However, after rebooting both 
terminals seem to act correctly.  There may have been some libraries 
still in memory from before a routine update.  I probably had not power 
cycled the machine for about a week and there had been updates.

I just tried to repeat this to get more detail and it seems to be 
trapped correctly:


gnuplot> plot [-pi:pi] sin(x)
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: nouveau
gnuplot>


Unless I see something similar again, I would conclude it was a one-off 
error, probably due to mixed library modules lurking in memory.

Sorry for the noise.

Peter.

Re: qt error trapping

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

On 11/29/2015 03:38 PM, pl...@pi... wrote:
> Hi,
>
> I just ran current cvs gnuplot while su as another user. This meant that
> gnuplot could not find the DISPLAY to connect to. However this failure
> was not correctly  ( at all ) trapped and I needed to ^C out to get back
> to the gnupplot prompt.
>
> I would expect it to drop out instantly , preferably with an error message.
>
>
> gnuplot>  plot [-pi:pi] sin(x)
> QXcbConnection: Could not connect to display
> q
>
> quit
> ^C
> gnuplot>
>
>
> Presumably there are other reasons qt may fail to open the plot window
> and this rather unusual situation probably highlights poor error
> trapping here.
>
> Regards, Peter.

Please create a bug report on the bug tracker with this message if you 
haven't done so already.  The Qt terminal is pretty good, but I'm sure 
there are some things not done just right.  Be sure to repeat what you 
are doing with something like the WXT terminal which also uses the 
graphics framework, and check if that hangs as well.  Thanks.

If you want to run under the root, there is "su -l" option.

Dan

qt error trapping

[<pl...@pi...>]

Hi,

I just ran current cvs gnuplot while su as another user. This meant that 
gnuplot could not find the DISPLAY to connect to. However this failure 
was not correctly  ( at all ) trapped and I needed to ^C out to get back 
to the gnupplot prompt.

I would expect it to drop out instantly , preferably with an error message.


gnuplot> plot [-pi:pi] sin(x)
QXcbConnection: Could not connect to display
q

quit
^C
gnuplot>


Presumably there are other reasons qt may fail to open the plot window 
and this rather unusual situation probably highlights poor error 
trapping here.

Regards, Peter.

Re: bugs in tikz, metapost terminals

[Allin C. <cot...@wf...>]

On Sat, 28 Nov 2015, sfeam wrote:

> On Friday, November 27, 2015 01:59:52 PM Allin Cottrell wrote:
>> In the first instance I'm just wondering if these issues are on
>> anyone's radar:
>>
>> * The tikz terminal doesn't respect the "mono" option; it produces
>> a color plot regardless.
>
> I am traveling and cannot test old versions of gnuplot, so I do not
> know if tikz mono used to work or not.   I do see that "set mono"
> works fine for the tikz terminal, so that is available as an alternative.

I've now checked, and tikz mono used to work in 4.6.0.

Allin Cottrell

Re: bugs in tikz, metapost terminals

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

On Friday, November 27, 2015 01:59:52 PM Allin Cottrell wrote:
> In the first instance I'm just wondering if these issues are on
> anyone's radar:
> 
> * The tikz terminal doesn't respect the "mono" option; it produces
> a color plot regardless.

I am traveling and cannot test old versions of gnuplot, so I do not
know if tikz mono used to work or not.   I do see that "set mono"
works fine for the tikz terminal, so that is available as an alternative.

> 
> * The metapost terminal doesn't respect the "dashed" option; it uses
> solid lines regardless.

I do not think support for the new dashed line mechanism was ever
added to the metapost terminal.

> This is in both 5.0.1 and current CVS. The mp term did dashes OK in
> gnuplot 4.6.

Version 5 uses a different API for dashed lines.
Terminals that do not support the new API are supposed to fall back
to the old dashed line sequence via the generic routine null_dashtype().
I do not know why that is failing for the metapost terminal.
I guess the first thing to check there is whether the fallback mechanism
is failing for all the old un-converted terminals or whether it is specific to 
mp.

> If nobody's working on these points I can try to come up with patches.

bugs in tikz, metapost terminals

[Allin C. <cot...@wf...>]

In the first instance I'm just wondering if these issues are on 
anyone's radar:

* The tikz terminal doesn't respect the "mono" option; it produces
a color plot regardless.

* The metapost terminal doesn't respect the "dashed" option; it uses 
solid lines regardless.

This is in both 5.0.1 and current CVS. The mp term did dashes OK in 
gnuplot 4.6.

If nobody's working on these points I can try to come up with patches.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: CVS woes: qt lacks title bar

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

On 11/27/2015 02:22 AM, Daniel J Sebald wrote:
> On 11/26/2015 11:05 PM, pl...@pi... wrote:
[snip]
>> It may be specific to lsdm but I suspect gnuplot is not setting ( or
>> mis-setting ) some window parameter, ie providing the plot window
>> coordinates instead of the frame coordinates.
>
> My guess is that's not the issue, at least not as simple as providing
> the wrong coordinates in the wrong spot.
>
> This comment in QtGnuplotWidget.cpp is slightly suspicious:
>
> // Qt has no reliable mechanism to set the size of widget while having
> // it resizable. So we heuristically use the resize function to set the
> // size of the plotting area when the plot window is already displayed.
> // When the window is not yet displayed, this does not work because the
> // window messes up with its content sizes before showing up. In this
> // case, we use the sizeHint mechanism to tell the window which size we
> // prefer for the plotting area. On MacOS, it looks like QMainWindow
> // forgets the status bar area when it layouts its contents. This makes
> // the plot area 14 pixels too small in the vertical direction when the
> // plot window is first displayed.
>
> It mentions that MacOS has a similar type of problem.  I'm wondering if
> the Qt external app is asking for layout at a time when the WM doesn't
> know what the final decorations are going to look like, then the OS
> items for the QMainWindow are added and then happen to be outside the
> screen when displayed.  It could be that other WMs are doing that too,
> but when they position they place the window not at the edge of the
> screen but somewhere near.
>
> The code is probably overlooking some more proper way of doing the
> layout in Qt.  Something in which the WM has full knowledge of the title
> bar presence.

Let's try something simple first.  Attached is a patch which simply 
reverses the order of showing the window and updating the geometry. 
Please try that.

Dan

Re: CVS woes: qt lacks title bar

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

On 11/26/2015 11:05 PM, pl...@pi... wrote:
> On 26/11/15 21:56, Ethan A Merritt wrote:
>>
>>
>>
>> On Thu, 26 Nov 2015, Daniel J Sebald wrote:
>>
>>> On 11/26/2015 05:41 AM, pl...@pi... wrote:
>>>> On 26/11/15 07:49, Daniel J Sebald wrote:
>>>>> On 11/25/2015 04:57 PM, pl...@pi... wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have just built current CVS and was quickly testing qt. ( built
>>>>>> with
>>>>>> qt5 )
>>>>>>
>>>>>> Terminal type set to 'qt'
>>>>>> gnuplot> plot sin(x*2.0*pi)
>>>>>>
>>>>>>
>>>>>> It works and resizes cleanly but the window is stuck up against the
>>>>>> top
>>>>>> left corner of the screen and I do not have a title bar on it.
>>>>>>
>>>>>> No means to move the window and no close button to get rid of it.
>>>>>>
>>>>>> Built on Fedora23 LXDE spin installation.
>>>>>
>>>>> Isn't there some type of dock you can put on the desktop that will
>>>>> allow
>>>>> minimizing applications? Does that work properly with the window?
>>>>>
>>>>> I'm not sure if many have been using qt5. Typically it is qt3 or qt4
>>>>> that is used. Unless you need qt5 for something else, try removing qt5
>>>>> from your installed software and run ./configure once again. See if
>>>>> the
>>>>> system finds qt4 and builds.
>>
>> qt5 has been fully supported for a long time now. I have never seen any
>> gnuplot problems specific to the qt version, other than finding the right
>> libraries to link when building it.
>>
>>>> yes, the minimise tool works. The configuration tool gets a proper
>>>> window with title bar and buttons. Save_As dialogue is normal. Just the
>>>> plot window is missing normal title bar.
>>
>> I don't think I understand the description. Are you saying that
>> you are getting a plot window that is not embedded in the same frame
>> as the toolbar widgets?
>>
>> Ethan
>>
>>
>>
>
> No, I was referring to the pop-up window you get when clicking on the
> spanner icon: that is normal with title bar.
>
> The problem is with the main plot window. It is connected to the boolbar
> but the two a stuck at the top left corner of the screen
>
> Ah! In attempting to get more detail on the question of the frame , I've
> found out what was happening. The WM was placing the window with the top
> of the toolbar at the edge of the screen , thus hiding the titlebar off
> screen, meaning the window could not be moved. I still had the right and
> bottom frames to resize but could not get off top-left corner.
>
> I managed to grab the top right frame corner and resized downwards at
> which point I realised the titlebar was there but not accessible.
>
> Now it is placing the new plot windows bottom-right instead.
>
> This may be a DM quirk with lxdm but I have not seen any odd behaviour
> with other programs All other windows fall within the visible screen and
> respect the window free margins defined in the DM ( I use 10 px right
> hand side margin for mouse scrolling between desktops ). I use 5
> desktops and slide windows from one to the other without issues.
>
> It may be specific to lsdm but I suspect gnuplot is not setting ( or
> mis-setting ) some window parameter, ie providing the plot window
> coordinates instead of the frame coordinates.

My guess is that's not the issue, at least not as simple as providing 
the wrong coordinates in the wrong spot.

This comment in QtGnuplotWidget.cpp is slightly suspicious:

// Qt has no reliable mechanism to set the size of widget while having
// it resizable. So we heuristically use the resize function to set the
// size of the plotting area when the plot window is already displayed.
// When the window is not yet displayed, this does not work because the
// window messes up with its content sizes before showing up. In this
// case, we use the sizeHint mechanism to tell the window which size we
// prefer for the plotting area. On MacOS, it looks like QMainWindow
// forgets the status bar area when it layouts its contents. This makes
// the plot area 14 pixels too small in the vertical direction when the
// plot window is first displayed.

It mentions that MacOS has a similar type of problem.  I'm wondering if 
the Qt external app is asking for layout at a time when the WM doesn't 
know what the final decorations are going to look like, then the OS 
items for the QMainWindow are added and then happen to be outside the 
screen when displayed.  It could be that other WMs are doing that too, 
but when they position they place the window not at the edge of the 
screen but somewhere near.

The code is probably overlooking some more proper way of doing the 
layout in Qt.  Something in which the WM has full knowledge of the title 
bar presence.

Dan

Re: CVS woes: qt lacks title bar

[<pl...@pi...>]

On 26/11/15 21:56, Ethan A Merritt wrote:
>
>
>
> On Thu, 26 Nov 2015, Daniel J Sebald wrote:
>
>> On 11/26/2015 05:41 AM, pl...@pi... wrote:
>>> On 26/11/15 07:49, Daniel J Sebald wrote:
>>>> On 11/25/2015 04:57 PM, pl...@pi... wrote:
>>>>> Hi,
>>>>>
>>>>> I have just built current CVS and was quickly testing qt. ( built with
>>>>> qt5 )
>>>>>
>>>>> Terminal type set to 'qt'
>>>>> gnuplot> plot sin(x*2.0*pi)
>>>>>
>>>>>
>>>>> It works and resizes cleanly but the window is stuck up against the
>>>>> top
>>>>> left corner of the screen and I do not have a title bar on it.
>>>>>
>>>>> No means to move the window and no close button to get rid of it.
>>>>>
>>>>> Built on Fedora23 LXDE spin installation.
>>>>
>>>> Isn't there some type of dock you can put on the desktop that will
>>>> allow
>>>> minimizing applications? Does that work properly with the window?
>>>>
>>>> I'm not sure if many have been using qt5. Typically it is qt3 or qt4
>>>> that is used. Unless you need qt5 for something else, try removing qt5
>>>> from your installed software and run ./configure once again. See if the
>>>> system finds qt4 and builds.
>
> qt5 has been fully supported for a long time now. I have never seen any
> gnuplot problems specific to the qt version, other than finding the right
> libraries to link when building it.
>
>>> yes, the minimise tool works. The configuration tool gets a proper
>>> window with title bar and buttons. Save_As dialogue is normal. Just the
>>> plot window is missing normal title bar.
>
> I don't think I understand the description. Are you saying that
> you are getting a plot window that is not embedded in the same frame
> as the toolbar widgets?
>
>      Ethan
>
>
>

No, I was referring to the pop-up window you get when clicking on the 
spanner icon: that is normal with title bar.

The problem is with the main plot window. It is connected to the boolbar 
but the two a stuck at the top left corner of the screen

Ah! In attempting to get more detail on the question of the frame , I've 
found out what was happening. The WM was placing the window with the top 
of the toolbar at the edge of the screen , thus hiding the titlebar off 
screen,  meaning the window could not be moved. I still had the right 
and bottom frames to resize but could not get off top-left corner.

I managed to grab the top right frame corner and resized downwards at 
which point I realised the titlebar was there but not accessible.

Now it is placing the new plot windows bottom-right instead.

This may be a DM quirk with lxdm but I have not seen any odd behaviour 
with other programs  All other windows fall within the visible screen 
and respect the window free margins defined in the DM ( I use 10 px 
right hand side margin for mouse scrolling between desktops ).  I use 5 
desktops and slide windows from one to the other without issues.

It may be specific to lsdm but I suspect gnuplot is not setting ( or 
mis-setting ) some window parameter, ie providing the plot window 
coordinates instead of the frame coordinates.

There is intelligent window placement on this DM which generally makes a 
good job of finding the clearest bit of screen to open a new window. 
Things like terminal windows which do not retain a 'last used position' 
usually end up against one of the four corners. They never end up with 
the title bar hidden.

All this works perfectly for everything I used except gnuplot

I just tested the dsitro packaged gnuplot and it does not have this bug.

gnuplot                    x86_64             5.0.1-2.fc23


Uninstalling and reinstalling CVS I have the same issue again.

Hopefully that gives you a clearer picture of what is happening.


Now I have found out where the titlebar is , it is just a minor 
annoyance and does not prevent me using qt terminal which is great. I've 
been using wxt ever since I install gnuplot and would like to test qt 
which I did not have on my old system.


There definitely is an issue here, though not a major one. Whether this 
is a regression or something that Fedora have fixed, I can't say.

Thanks , Peter.

Re: CVS woes: qt lacks title bar

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

On Thu, 26 Nov 2015, Daniel J Sebald wrote:

> On 11/26/2015 05:41 AM, pl...@pi... wrote:
>> On 26/11/15 07:49, Daniel J Sebald wrote:
>>> On 11/25/2015 04:57 PM, pl...@pi... wrote:
>>>> Hi,
>>>>
>>>> I have just built current CVS and was quickly testing qt. ( built with
>>>> qt5 )
>>>>
>>>> Terminal type set to 'qt'
>>>> gnuplot> plot sin(x*2.0*pi)
>>>>
>>>>
>>>> It works and resizes cleanly but the window is stuck up against the top
>>>> left corner of the screen and I do not have a title bar on it.
>>>>
>>>> No means to move the window and no close button to get rid of it.
>>>>
>>>> Built on Fedora23 LXDE spin installation.
>>>
>>> Isn't there some type of dock you can put on the desktop that will allow
>>> minimizing applications? Does that work properly with the window?
>>>
>>> I'm not sure if many have been using qt5. Typically it is qt3 or qt4
>>> that is used. Unless you need qt5 for something else, try removing qt5
>>> from your installed software and run ./configure once again. See if the
>>> system finds qt4 and builds.

qt5 has been fully supported for a long time now. I have never seen any
gnuplot problems specific to the qt version, other than finding the right
libraries to link when building it.

>> yes, the minimise tool works. The configuration tool gets a proper
>> window with title bar and buttons. Save_As dialogue is normal. Just the
>> plot window is missing normal title bar.

I don't think I understand the description. Are you saying that
you are getting a plot window that is not embedded in the same frame
as the toolbar widgets?

     Ethan

Re: CVS woes: qt lacks title bar

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

On 11/26/2015 05:41 AM, pl...@pi... wrote:
> On 26/11/15 07:49, Daniel J Sebald wrote:
>> On 11/25/2015 04:57 PM, pl...@pi... wrote:
>>> Hi,
>>>
>>> I have just built current CVS and was quickly testing qt. ( built with
>>> qt5 )
>>>
>>> Terminal type set to 'qt'
>>> gnuplot> plot sin(x*2.0*pi)
>>>
>>>
>>> It works and resizes cleanly but the window is stuck up against the top
>>> left corner of the screen and I do not have a title bar on it.
>>>
>>> No means to move the window and no close button to get rid of it.
>>>
>>> Built on Fedora23 LXDE spin installation.
>>
>> Isn't there some type of dock you can put on the desktop that will allow
>> minimizing applications? Does that work properly with the window?
>>
>> I'm not sure if many have been using qt5. Typically it is qt3 or qt4
>> that is used. Unless you need qt5 for something else, try removing qt5
>> from your installed software and run ./configure once again. See if the
>> system finds qt4 and builds.
>>
>> Dan
>>
>
> Thanks Dan,
>
> yes, the minimise tool works. The configuration tool gets a proper
> window with title bar and buttons. Save_As dialogue is normal. Just the
> plot window is missing normal title bar.

If it is that close, post a bug report to the tracker and I will look 
closely at the code and see if we can make it work for you.

Dan

Re: CVS woes: qt lacks title bar

[<pl...@pi...>]

On 26/11/15 07:49, Daniel J Sebald wrote:
> On 11/25/2015 04:57 PM, pl...@pi... wrote:
>> Hi,
>>
>> I have just built current CVS and was quickly testing qt. ( built with
>> qt5 )
>>
>> Terminal type set to 'qt'
>> gnuplot>  plot sin(x*2.0*pi)
>>
>>
>> It works and resizes cleanly but the window is stuck up against the top
>> left corner of the screen and I do not have a title bar on it.
>>
>> No means to move the window and no close button to get rid of it.
>>
>> Built on Fedora23 LXDE spin installation.
>
> Isn't there some type of dock you can put on the desktop that will allow
> minimizing applications?  Does that work properly with the window?
>
> I'm not sure if many have been using qt5.  Typically it is qt3 or qt4
> that is used.  Unless you need qt5 for something else, try removing qt5
> from your installed software and run ./configure once again.  See if the
> system finds qt4 and builds.
>
> Dan
>

Thanks Dan,

yes, the minimise tool works. The configuration tool gets a proper 
window with title bar and buttons. Save_As dialogue is normal. Just the 
plot window is missing normal title bar.

I will try qt4 later, I have other broken software to chase up first.

At some stage I need to find time to actually USE the machine as well as 
maintain it.

Thanks for the suggestions.

Peter.

Re: CVS woes: qt lacks title bar

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

On 11/25/2015 04:57 PM, pl...@pi... wrote:
> Hi,
>
> I have just built current CVS and was quickly testing qt. ( built with qt5 )
>
> Terminal type set to 'qt'
> gnuplot>  plot sin(x*2.0*pi)
>
>
> It works and resizes cleanly but the window is stuck up against the top
> left corner of the screen and I do not have a title bar on it.
>
> No means to move the window and no close button to get rid of it.
>
> Built on Fedora23 LXDE spin installation.

Isn't there some type of dock you can put on the desktop that will allow 
minimizing applications?  Does that work properly with the window?

I'm not sure if many have been using qt5.  Typically it is qt3 or qt4 
that is used.  Unless you need qt5 for something else, try removing qt5 
from your installed software and run ./configure once again.  See if the 
system finds qt4 and builds.

Dan