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

Re: Spacebar does not raise command window with wxt terminal

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

On 06/18/14 23:03, Philipp K. Janert wrote:
>
> On Wed, 18 Jun 2014 13:52:05 -0700
> Ethan A Merritt <sf...@us...> wrote:
>
>> On Wednesday, 18 June, 2014 13:44:56 Philipp K. Janert wrote:
>>> On Wed, 18 Jun 2014 13:24:13 -0700
>>> Ethan A Merritt <sf...@us...> wrote:
>>>
>>>> On Wednesday, 18 June, 2014 13:07:40 Philipp K. Janert wrote:
>>>>>
>>>>> On my system, the spacebar does not raise the
>>>>> command window after a plot, when using the
>>>>> wxt terminal. The spacebar works as expected
>>>>> when using the x11 terminal.
>>>>>
>>>>> ctrl-space does not work either.
>>>>>
>>>>> This happens both with the "packaged" version
>>>>> of gnuplot (4.6.3) and with the RC (5rc1).
>>>>>
>>>>> I looked over the wxt terminals "settings"
>>>>> dialog, but did not find anything that seemed
>>>>> applicable.
>>>>>
>>>>> Anything else I could try? Is this a wxt-config
>>>>> issue somehow?
>>>>
>>>> It's a configuration option:
>>>>
>>>> 	./configure --enable-raise-console
>>>
>>> That should be enabled by default, isn't it?
>>>
>>> In any case - it does not work (for me), even
>>> if I enable it explicitly (as you suggest).
>>>
>>> Do others see this, too? Anything one can do
>>> about that?
>>
>>      bind ' ' "raise"
>>
>> should work for all terminals regardless of default configuration.
>>
>
> Still no cigar. Very odd. I begin to wonder
> whether my window mgr intercepts key strokes,
> or something like that (not gnuplot related).
>
> Anyway - if no-one else is seeing this, it
> must be a problem on my end. Thanks for the
> advice.
>
>

wxt here, space while mouse is over the plot window does raise the 
command window.

WM configured for 'focus follows mouse' , so this works even if the plot 
window is partially behind something else.  The plot window will have to 
have been clicked on to give it the focus if you have some other set up, 
in order for it to get passed the keystroke

Peter.

Addlt info (was: Spacebar does not raise command window with wxt terminal)

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

> 
> > > Still no cigar. Very odd. I begin to wonder
> > > whether my window mgr intercepts key strokes,
> > > or something like that (not gnuplot related).
> > >
> > > Anyway - if no-one else is seeing this, it
> > > must be a problem on my end. Thanks for the
> > > advice.
> > 
> > Neither does it work for me.
> 
> Thanks - at least I am not alone. ;-)
> 
> For reference: I use iceWM (1.3.7-5) on 
> Linux Mint-16 (64bit). (Just in case it
> is a window mgr issue.)
> 

For what it's worth, I just realized that the 
"[no]raise" option to the wxt terminal does
not work either (for me).

In other words:
	set t wxt noraise
should prevent the plot window from being 
raised after a plot. But on my system, the
plot window is raised after each plot,
regardless.

This begins to look like an issue with wxt.
My version is 2.8.12.

Re: Suggestions for 5.0: Margin (and Key)

[Jonathan T. <jt...@as...>]

Philipp K. Janert wrote:
> 3) Key position and offset
> A very similar situation arises with the positioning
> of the key. Frequently, I am happy with the automatic
> positioning, but would like to adjust it slightly.
> 
> I can see two solutions for that: one is that 
> 	show key
> would display the actual position of the margin (so
> that this position, when given to "set key at ..."
> would reproduce the previous plot), 

Ethan A Merritt <sf...@us...> replied:
: See above.  These values can be retrieved from the GPVAL
: variables.

> What variables hold the key position? When I
> do "show variables all", nothing seems appropriate.

: I meant that you can position the key box relative to the plot
: border by using, e.g.
: 
:   set key top right at graph 0.98, graph 0.98

I've had the same problem as Philipp.  It usually strikes when I'm
using the postscript terminal, where gnuplot doesn't know the actual
width of the plot key.  I end up doing a fair bit of trial and error
to determine either a "width" adjustment to, or an absolute position for,
the plot key.

An example might make this clearer:  Consider the following two gnuplot
scripts (which differ only in their "set key" lines & the names of their
output files):

--- BEGIN #1
set term postscript eps enhanced color solid 14
set output 'key-demo.eps'

set key top left Left reverse samplen 2.5 spacing 1.333

set xrange [0:10]
set yrange [-1:1]

plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
     with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
     (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
     with lines linetype 1 linewidth 3.0 linecolor 3

set output
--- END #1

--- BEGIN #2
set term postscript eps enhanced color solid 14
set output 'key-demo2.eps'

# try to mimic the positioning of
#   set key top left Left reverse samplen 2.5 spacing 1.333
set key at graph 0.45, graph 0.975 Left reverse samplen 2.5 spacing 1.333

set xrange [0:10]
set yrange [-1:1]

plot (-sin(x)) title "10^6 {/Symbol \264 D} F_{/Symbol f} via Fourier series" \
     with lines linetype 1 linewidth 3.0 linecolor rgb "#00A000",	\
     (-cos(x)) title "10^6 {/Symbol \264 D} F_t"	 		\
     with lines linetype 1 linewidth 3.0 linecolor 3

set output
--- END #2

These produce approximately the same output... but I had to find the
numbers 0.45 and 0.975 in the second script by trial and error.  Moreover,
the 0.45 must be changed (found by a new round of trial-and-error) if
I change label font, size, text length.

You can see this if you try deleting the text "via Fourier series" from
the label string.  The automatically-placed label is still in the same
place, but to get that place manually requires changing that 0.45 to
something more like 0.20 (again determined by trial and error).

What I (and I think also Philipp K. Janert) would like is a way to find
those numbers 0.45 and 0.975 without trial and error, preferably in a
way which doesn't require redoing if I change the label font, size, or
text length.

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   currently on the west coast of Canada
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

Re: Suggestions for 5.0: Margin (and Key)

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

On Wed, 18 Jun 2014 15:53:01 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 18 June, 2014 15:40:11 Philipp K. Janert wrote:
> > On Wed, 18 Jun 2014 15:31:46 -0700
> > Ethan A Merritt <sf...@us...> wrote:
> > 
> > > On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> > > 
> > > > > > 3) Key position and offset
> > > > > > A very similar situation arises with the positioning
> > > > > > of the key. Frequently, I am happy with the automatic
> > > > > > positioning, but would like to adjust it slightly.
> > > > > > 
> > > > > > I can see two solutions for that: one is that 
> > > > > > 	show key
> > > > > > would display the actual position of the margin (so
> > > > > > that this position, when given to "set key at ..."
> > > > > > would reproduce the previous plot), 
> > > > > 
> > > > > See above.  These values can be retrieved from the GPVAL
> > > > > variables.
> > > > 
> > > > What variables hold the key position? When I
> > > > do "show variables all", nothing seems appropriate.
> > > 
> > > I meant that you can position the key box relative to the plot
> > > border by using, e.g.
> > > 
> > >   set key top right at graph 0.98, graph 0.98
> > 
> > But that's not what I mean! I know that I can place
> > the key arbitrarily - IFF I know, in absolute terms,
> > where I want it!
> > 
> > My use case is this: I want to use the automatically 
> > chosen position as starting point, and then modify it.
> > This could be done through an "offset" directive in
> > "set key", but it could also be done if I could read
> > out the currently chosen key position from some 
> > automatically set GPVAL variable. But none of the
> > GPVAL vars seems to refer to the current key position.
> > 
> > Or am I missing something?
> 
> I think you are correct that it could only be done by adding a
> new parameter equivalent to "offset".   The default positioning
> uses an empirical try/oops/try-again approach that is basically
> impossible to document usefully.   Note that the empirical positioning
> can easily come out differently on different terminals, so even if
> we were to add a tweak parameter you'd have to tweak all over
> again if you changed the output device.

Yes, I understand that.

Would it be possible to add two GPVAL vars to hold
the actual (screen?) positions of the x and y coords
of the key?

> 
> 	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> 
> > > 1) Naming of margins
> > > The naming of the margin options scatters 
> > > them around in any alphabetical listing of
> > > options. I wonder whether we could add 
> > > alternative names, that put the location 
> > > last (not first) - similar to what is done
> > > in CSS: margin-top, margin-bottom, etc.
> > 
> > Where do you mean?
> > They are already collected together so far as "show margin"
> > output is concerned, or "help set margin" for that matter.
> 
> For instance in the reference manual...

Sorry - I'm not following you.
The reference manual has a section under 

Commands
   ->  Set
         -> Margin

i.e. the same as you get with "help set margin".

What are you asking for instead?

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 15:40:11 Philipp K. Janert wrote:
> On Wed, 18 Jun 2014 15:31:46 -0700
> Ethan A Merritt <sf...@us...> wrote:
> 
> > On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> > 
> > > > > 3) Key position and offset
> > > > > A very similar situation arises with the positioning
> > > > > of the key. Frequently, I am happy with the automatic
> > > > > positioning, but would like to adjust it slightly.
> > > > > 
> > > > > I can see two solutions for that: one is that 
> > > > > 	show key
> > > > > would display the actual position of the margin (so
> > > > > that this position, when given to "set key at ..."
> > > > > would reproduce the previous plot), 
> > > > 
> > > > See above.  These values can be retrieved from the GPVAL
> > > > variables.
> > > 
> > > What variables hold the key position? When I
> > > do "show variables all", nothing seems appropriate.
> > 
> > I meant that you can position the key box relative to the plot
> > border by using, e.g.
> > 
> >   set key top right at graph 0.98, graph 0.98
> 
> But that's not what I mean! I know that I can place
> the key arbitrarily - IFF I know, in absolute terms,
> where I want it!
> 
> My use case is this: I want to use the automatically 
> chosen position as starting point, and then modify it.
> This could be done through an "offset" directive in
> "set key", but it could also be done if I could read
> out the currently chosen key position from some 
> automatically set GPVAL variable. But none of the
> GPVAL vars seems to refer to the current key position.
> 
> Or am I missing something?

I think you are correct that it could only be done by adding a
new parameter equivalent to "offset".   The default positioning
uses an empirical try/oops/try-again approach that is basically
impossible to document usefully.   Note that the empirical positioning
can easily come out differently on different terminals, so even if
we were to add a tweak parameter you'd have to tweak all over
again if you changed the output device.

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Wed, 18 Jun 2014 15:31:46 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:
> 
> > > > 3) Key position and offset
> > > > A very similar situation arises with the positioning
> > > > of the key. Frequently, I am happy with the automatic
> > > > positioning, but would like to adjust it slightly.
> > > > 
> > > > I can see two solutions for that: one is that 
> > > > 	show key
> > > > would display the actual position of the margin (so
> > > > that this position, when given to "set key at ..."
> > > > would reproduce the previous plot), 
> > > 
> > > See above.  These values can be retrieved from the GPVAL
> > > variables.
> > 
> > What variables hold the key position? When I
> > do "show variables all", nothing seems appropriate.
> 
> I meant that you can position the key box relative to the plot
> border by using, e.g.
> 
>   set key top right at graph 0.98, graph 0.98

But that's not what I mean! I know that I can place
the key arbitrarily - IFF I know, in absolute terms,
where I want it!

My use case is this: I want to use the automatically 
chosen position as starting point, and then modify it.
This could be done through an "offset" directive in
"set key", but it could also be done if I could read
out the currently chosen key position from some 
automatically set GPVAL variable. But none of the
GPVAL vars seems to refer to the current key position.

Or am I missing something?

> 
> If you want to adjust that down to the individual pixel, you can
> translate those coords using GPVAL_TERM_*
> 
> 	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 15:03:32 Philipp K. Janert wrote:

> > > 3) Key position and offset
> > > A very similar situation arises with the positioning
> > > of the key. Frequently, I am happy with the automatic
> > > positioning, but would like to adjust it slightly.
> > > 
> > > I can see two solutions for that: one is that 
> > > 	show key
> > > would display the actual position of the margin (so
> > > that this position, when given to "set key at ..."
> > > would reproduce the previous plot), 
> > 
> > See above.  These values can be retrieved from the GPVAL variables.
> 
> What variables hold the key position? When I
> do "show variables all", nothing seems appropriate.

I meant that you can position the key box relative to the plot
border by using, e.g.

  set key top right at graph 0.98, graph 0.98

If you want to adjust that down to the individual pixel, you can
translate those coords using GPVAL_TERM_*

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

> > 1) Naming of margins
> > The naming of the margin options scatters 
> > them around in any alphabetical listing of
> > options. I wonder whether we could add 
> > alternative names, that put the location 
> > last (not first) - similar to what is done
> > in CSS: margin-top, margin-bottom, etc.
> 
> Where do you mean?
> They are already collected together so far as "show margin"
> output is concerned, or "help set margin" for that matter.

For instance in the reference manual...

> 
> > Alternatively (and more ambitiously) one could
> > treat the location of the margin as a sub-option,
> > like so:
> > 	set margin top 5
> > and so on. This would (in principle) allow to
> > combine settings:
> > 	set margin left right 5
> > but I am not sure how useful that would be.
> 
> Maybe just 
> 	set margins [l],[r],[t],[b]

That would be fine...

> 
> I have wanted that from time to time.
> 
> > 2) Explicit display of margin value
> > Is there a way to show the actual margin value,
> > when the margin is computed automatically? 
> 
> You mean in screen coordinates?
> 
>     set lmargin at screen GPVAL_TERM_XMIN / GPVAL_TERM_XSIZE
> 
> and so on.

I see. Yes, that would work. 

But I was actually thinking of a more direct
display, in the same coordinate system that 
"set margin" takes - in other words, using 
the current character position of the margin.

But I agree that the command above solves my
problem.

> 
> > 3) Key position and offset
> > A very similar situation arises with the positioning
> > of the key. Frequently, I am happy with the automatic
> > positioning, but would like to adjust it slightly.
> > 
> > I can see two solutions for that: one is that 
> > 	show key
> > would display the actual position of the margin (so
> > that this position, when given to "set key at ..."
> > would reproduce the previous plot), 
> 
> See above.  These values can be retrieved from the GPVAL variables.

What variables hold the key position? When I
do "show variables all", nothing seems appropriate.

> 
> 	Ethan
> 
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
> Solutions Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Spacebar does not raise command window with wxt terminal

[Dmitri A. S. <das...@gm...>]

On Wed, Jun 18, 2014 at 4:35 PM, Christoph Bersch <us...@be...> wrote:

> Zitat von "Philipp K. Janert" <ja...@ie...>:
>
> > On Wed, 18 Jun 2014 13:52:05 -0700
>
​...​


> >
> > Anyway - if no-one else is seeing this, it
> > must be a problem on my end. Thanks for the
> > advice.
>
> Neither does it work for me.
>
> Christoph
>
>
​On Fedora 20 it works as expected (in Gnome desktop at least)
with both 5rc1 and 4.6.5.

Dmitri.
-- 
 ​

Re: Spacebar does not raise command window with wxt terminal

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

> > Still no cigar. Very odd. I begin to wonder
> > whether my window mgr intercepts key strokes,
> > or something like that (not gnuplot related).
> >
> > Anyway - if no-one else is seeing this, it
> > must be a problem on my end. Thanks for the
> > advice.
> 
> Neither does it work for me.

Thanks - at least I am not alone. ;-)

For reference: I use iceWM (1.3.7-5) on 
Linux Mint-16 (64bit). (Just in case it
is a window mgr issue.)

Re: Spacebar does not raise command window with wxt terminal

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

Zitat von "Philipp K. Janert" <ja...@ie...>:

> On Wed, 18 Jun 2014 13:52:05 -0700
> Ethan A Merritt <sf...@us...> wrote:
>>
>>     bind ' ' "raise"
>>
>> should work for all terminals regardless of default configuration.
>>
>
> Still no cigar. Very odd. I begin to wonder
> whether my window mgr intercepts key strokes,
> or something like that (not gnuplot related).
>
> Anyway - if no-one else is seeing this, it
> must be a problem on my end. Thanks for the
> advice.

Neither does it work for me.

Christoph

Re: Spacebar does not raise command window with wxt terminal

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

On Wed, 18 Jun 2014 13:52:05 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 18 June, 2014 13:44:56 Philipp K. Janert wrote:
> > On Wed, 18 Jun 2014 13:24:13 -0700
> > Ethan A Merritt <sf...@us...> wrote:
> > 
> > > On Wednesday, 18 June, 2014 13:07:40 Philipp K. Janert wrote:
> > > > 
> > > > On my system, the spacebar does not raise the
> > > > command window after a plot, when using the 
> > > > wxt terminal. The spacebar works as expected
> > > > when using the x11 terminal.
> > > > 
> > > > ctrl-space does not work either.
> > > > 
> > > > This happens both with the "packaged" version
> > > > of gnuplot (4.6.3) and with the RC (5rc1).
> > > > 
> > > > I looked over the wxt terminals "settings"
> > > > dialog, but did not find anything that seemed
> > > > applicable.
> > > > 
> > > > Anything else I could try? Is this a wxt-config
> > > > issue somehow?
> > > 
> > > It's a configuration option:
> > > 
> > > 	./configure --enable-raise-console
> > 
> > That should be enabled by default, isn't it?
> > 
> > In any case - it does not work (for me), even 
> > if I enable it explicitly (as you suggest).
> > 
> > Do others see this, too? Anything one can do 
> > about that?
> 
>     bind ' ' "raise"
> 
> should work for all terminals regardless of default configuration.
> 

Still no cigar. Very odd. I begin to wonder
whether my window mgr intercepts key strokes,
or something like that (not gnuplot related).

Anyway - if no-one else is seeing this, it
must be a problem on my end. Thanks for the
advice.

Re: Suggestions for 5.0: Margin (and Key)

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

Zitat von Ethan A Merritt <sf...@us...>:

> On Wednesday, 18 June, 2014 13:01:02 Philipp K. Janert wrote:
>>
>>
>> 	set margin top 5
>> and so on. This would (in principle) allow to
>> combine settings:
>> 	set margin left right 5
>> but I am not sure how useful that would be.
>
> Maybe just
> 	set margins [l],[r],[t],[b]
>
> I have wanted that from time to time.

I would also like to see such a compact command for specifying all margins.

>
>> 2) Explicit display of margin value
>> Is there a way to show the actual margin value,
>> when the margin is computed automatically?
>
> You mean in screen coordinates?
>
>     set lmargin at screen GPVAL_TERM_XMIN / GPVAL_TERM_XSIZE
>
> and so on.

Unfortunately, that doesn't work properly for all terminals, see my  
bug report https://sourceforge.net/p/gnuplot/bugs/1291/

Christoph

Re: Spacebar does not raise command window with wxt terminal

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

On Wednesday, 18 June, 2014 13:44:56 Philipp K. Janert wrote:
> On Wed, 18 Jun 2014 13:24:13 -0700
> Ethan A Merritt <sf...@us...> wrote:
> 
> > On Wednesday, 18 June, 2014 13:07:40 Philipp K. Janert wrote:
> > > 
> > > On my system, the spacebar does not raise the
> > > command window after a plot, when using the 
> > > wxt terminal. The spacebar works as expected
> > > when using the x11 terminal.
> > > 
> > > ctrl-space does not work either.
> > > 
> > > This happens both with the "packaged" version
> > > of gnuplot (4.6.3) and with the RC (5rc1).
> > > 
> > > I looked over the wxt terminals "settings"
> > > dialog, but did not find anything that seemed
> > > applicable.
> > > 
> > > Anything else I could try? Is this a wxt-config
> > > issue somehow?
> > 
> > It's a configuration option:
> > 
> > 	./configure --enable-raise-console
> 
> That should be enabled by default, isn't it?
> 
> In any case - it does not work (for me), even 
> if I enable it explicitly (as you suggest).
> 
> Do others see this, too? Anything one can do 
> about that?

    bind ' ' "raise"

should work for all terminals regardless of default configuration.

	Ethan

Re: Spacebar does not raise command window with wxt terminal

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

On Wed, 18 Jun 2014 13:24:13 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 18 June, 2014 13:07:40 Philipp K. Janert wrote:
> > 
> > On my system, the spacebar does not raise the
> > command window after a plot, when using the 
> > wxt terminal. The spacebar works as expected
> > when using the x11 terminal.
> > 
> > ctrl-space does not work either.
> > 
> > This happens both with the "packaged" version
> > of gnuplot (4.6.3) and with the RC (5rc1).
> > 
> > I looked over the wxt terminals "settings"
> > dialog, but did not find anything that seemed
> > applicable.
> > 
> > Anything else I could try? Is this a wxt-config
> > issue somehow?
> 
> It's a configuration option:
> 
> 	./configure --enable-raise-console

That should be enabled by default, isn't it?

In any case - it does not work (for me), even 
if I enable it explicitly (as you suggest).

Do others see this, too? Anything one can do 
about that?

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June, 2014 13:01:02 Philipp K. Janert wrote:
> 
> All -
> 
> Before it is too-too late, I wanted to put 
> forward thre small suggestions concerning 
> the margins and the key.
> 
> 
> 1) Naming of margins
> The naming of the margin options scatters 
> them around in any alphabetical listing of
> options. I wonder whether we could add 
> alternative names, that put the location 
> last (not first) - similar to what is done
> in CSS: margin-top, margin-bottom, etc.

Where do you mean?
They are already collected together so far as "show margin"
output is concerned, or "help set margin" for that matter.

> Alternatively (and more ambitiously) one could
> treat the location of the margin as a sub-option,
> like so:
> 	set margin top 5
> and so on. This would (in principle) allow to
> combine settings:
> 	set margin left right 5
> but I am not sure how useful that would be.

Maybe just 
	set margins [l],[r],[t],[b]

I have wanted that from time to time.

> 2) Explicit display of margin value
> Is there a way to show the actual margin value,
> when the margin is computed automatically? 

You mean in screen coordinates?

    set lmargin at screen GPVAL_TERM_XMIN / GPVAL_TERM_XSIZE

and so on.

> 3) Key position and offset
> A very similar situation arises with the positioning
> of the key. Frequently, I am happy with the automatic
> positioning, but would like to adjust it slightly.
> 
> I can see two solutions for that: one is that 
> 	show key
> would display the actual position of the margin (so
> that this position, when given to "set key at ..."
> would reproduce the previous plot), 

See above.  These values can be retrieved from the GPVAL variables.

	Ethan

Re: Spacebar does not raise command window with wxt terminal

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

On Wednesday, 18 June, 2014 13:07:40 Philipp K. Janert wrote:
> 
> On my system, the spacebar does not raise the
> command window after a plot, when using the 
> wxt terminal. The spacebar works as expected
> when using the x11 terminal.
> 
> ctrl-space does not work either.
> 
> This happens both with the "packaged" version
> of gnuplot (4.6.3) and with the RC (5rc1).
> 
> I looked over the wxt terminals "settings"
> dialog, but did not find anything that seemed
> applicable.
> 
> Anything else I could try? Is this a wxt-config
> issue somehow?

It's a configuration option:

	./configure --enable-raise-console

I don't know if there is some additional wxt wrinkle on top of that.

	Ethan

Spacebar does not raise command window with wxt terminal

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

On my system, the spacebar does not raise the
command window after a plot, when using the 
wxt terminal. The spacebar works as expected
when using the x11 terminal.

ctrl-space does not work either.

This happens both with the "packaged" version
of gnuplot (4.6.3) and with the RC (5rc1).

I looked over the wxt terminals "settings"
dialog, but did not find anything that seemed
applicable.

Anything else I could try? Is this a wxt-config
issue somehow?

Best,

		Ph.

Suggestions for 5.0: Margin (and Key)

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

All -

Before it is too-too late, I wanted to put 
forward thre small suggestions concerning 
the margins and the key.


1) Naming of margins
The naming of the margin options scatters 
them around in any alphabetical listing of
options. I wonder whether we could add 
alternative names, that put the location 
last (not first) - similar to what is done
in CSS: margin-top, margin-bottom, etc.

This could be done in addition to the current
naming and so preserve backwards compatibility.

Alternatively (and more ambitiously) one could
treat the location of the margin as a sub-option,
like so:
	set margin top 5
and so on. This would (in principle) allow to
combine settings:
	set margin left right 5
but I am not sure how useful that would be.


2) Explicit display of margin value
Is there a way to show the actual margin value,
when the margin is computed automatically? 

Frequently, I find that I would like to adjust
the margin from its automatic value - but in 
order to do so, I have to find the ACTUAL value
first by trial and error. It would be much 
easier if the computed value was displayed, 
for example like so:
	show margin
	lmargin is computed automatically, currently 5
or similar.

(Another use case arises with multiplot, where I
am happy with the margin value chosen by one of
the plots, and now would like to fix both plots
to use that value. Again - currently, I have to
find the actual margin value by trial and error.)


3) Key position and offset
A very similar situation arises with the positioning
of the key. Frequently, I am happy with the automatic
positioning, but would like to adjust it slightly.

I can see two solutions for that: one is that 
	show key
would display the actual position of the margin (so
that this position, when given to "set key at ..."
would reproduce the previous plot), 
OR the introduction of an additional sub-option, 
"offset" to the "key" option, similar to what already
exists for xlabel, ylabel, and so on.


Any thoughts on either of these suggestions? 

Best,

		Ph.

Re: CVS build fails on Ubuntu 14.04 i386

[flapane <int...@gm...>]

Thanks, last changes did the trick.
I'll report any further non-expected behaviour,

Flavio

Re: CVS build fails on Ubuntu 14.04 i386

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

On Monday, 16 June, 2014 21:03:11 Christoph Bersch wrote:
> Zitat von flapane <int...@gm...>:
> >
> > Compiling error:
> > ----------------------
> > /usr/bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol  
> > 'XInitThreads'
> 
> I get the same error since a change related to the bug report  
> http://sourceforge.net/p/gnuplot/bugs/1401/
> 
> Since the applied 'fix' to make gnuplot work with wxWidgets 3.0  
> doesn't work properly, you can remove it using the attached patch.

I have tried to fix this in CVS.
The problem is that despite imposing a requirement that the program
calls XInitThreads, the wxt-config script doesn't actually add the 
corresponding required library to the dependency list.

So I have changed gnuplot's autoconfigure script to add -lX11
itself if it sees that the newer wxWidgets is being used.
I am a little uneasy that this may cause problems in the future
on platforms where wxWidgets using wayland or carbon rather
than X11, but I guess we'll find out.

	Ethan 

Re: CVS build fails on Ubuntu 14.04 i386

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

Zitat von flapane <int...@gm...>:
>
> Compiling error:
> ----------------------
> /usr/bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol  
> 'XInitThreads'

I get the same error since a change related to the bug report  
http://sourceforge.net/p/gnuplot/bugs/1401/

Since the applied 'fix' to make gnuplot work with wxWidgets 3.0  
doesn't work properly, you can remove it using the attached patch.

Regards,
Christoph

CVS build fails on Ubuntu 14.04 i386

[flapane <int...@gm...>]

Configure summary: http://pastebin.com/chvuWVRM

Compiling error:
----------------------
/usr/bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol 
'XInitThreads'
//usr/lib/i386-linux-gnu/libX11.so.6: error adding symbols: DSO missing 
from command line
collect2: error: ld returned 1 exit status
make[4]: *** [gnuplot] Errore 1
make[4]: uscita dalla directory "/home/flapane/.svnflap/gnuplot/src"
make[3]: *** [all-recursive] Errore 1
make[3]: uscita dalla directory "/home/flapane/.svnflap/gnuplot/src"
make[2]: *** [all] Errore 2
make[2]: uscita dalla directory "/home/flapane/.svnflap/gnuplot/src"
make[1]: *** [all-recursive] Errore 1
make[1]: uscita dalla directory "/home/flapane/.svnflap/gnuplot"
make: *** [all] Errore 2
----------------------

Re: Once more: Qt Terminal (no output)

[Dmitri A. S. <das...@gm...>]

On Sun, Jun 15, 2014 at 11:18 PM, Philipp K. Janert <ja...@ie...> wrote:

> On Sun, 15 Jun 2014 22:42:01 -0500
> "Dmitri A. Sergatskov" <das...@gm...> wrote:
>
>
> > Do you have libQt5Widgets.so.5 on your computer?
> > (mine came in qt5-qtbase-gui-5.2.1-8 package)
>
> Yes:
> 2013 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so -> libQt5Widgets.so.5.0.2
> 2013 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 -> libQt5Widgets.so.5.0.2
> 2013 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.0 ->
> libQt5Widgets.so.5.0.2
> 2013 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.0.2
>
>

​Hmm... May be it is a difference between QT5.0.2 and 5.2.1...
BTW I found that my compile against qt5 is quite buggy with
respect of font handling, so I reverted to qt4.  ​


​Dmitri.
-- 
​