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

Re: build problems with wxGTK 3.0

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

On Fri, Jun 20, 2014 at 12:43 AM, Allin Cottrell wrote:
> On Thu, 19 Jun 2014, Ethan A Merritt wrote:
>> On Thursday, 19 June, 2014 22:27:46 Mojca Miklavec wrote:
>>> On Thu, Jun 19, 2014 at 9:31 PM, Ethan A Merritt
>>
>>>>> So please also check whether wxWidgets are using gtk2 or gtk3 before
>>>>> calling pkg-config to supply build flags.
>>>>
>>>>
>>>> That's a chicken-or-egg dilemma.
>>>> wx-config is supposed to tell us the version, but we need the version in
>>>> order to call the correct wx-config.
>>>
>>>
>>> I don't see any chicken here ;)
>>>
>>> Once gnuplot calls
>>>     WX_CXXFLAGS="`$WX_CONFIG --cxxflags
>>> it already knows which $WX_CONFIG it is calling.
>>>
>>> The problematic line is only
>>>     PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
>>>
>>> Gnuplot should run
>>>     "$WX_CONFIG" --basename | <grep something>
>>> before asking for gtk+-2.0.
>>
>>
>> On linux (at least on my machines) there are two different wx-configs,
>> one for wx2 and one for wx3.   You need to pick up the version from
>> somewhere
>> before you even know which one to run.
>
>
> Running on Mac, Mojca may or may not realize that most, if not all, modern
> Linux distros pack both gtk2 and gtk3,

Yes, I know that. I have both gtk2 and gtk3 installed myself (on a Mac).

> and therefore both variants of
> wxWidgets may also be present.

(Theoretically the number of wxWidgets installations is only limited
by the disk space.) So yes, I'm aware that one can have both gtk2 and
gtk3 installed. What I don't believe though is that any linux
distribution would ship two copies of wxWidgets30 distribution, once
compiled against GTK 2 and once compiled against GTK 3.

But for the sake of argument let's assume that a machine has all of
the following installed:
- wxWidgets 2.8 with GTK 2
- wxWidgets 2.8 with GTK 3 (maybe that's not possible)
- wxWidgets 3.0 with GTK 2
- wxWidgets 3.0 with GTK 3

Can you please write in pseudocode what exactly you mean / based on
what would you pick wxWidgets then and how?

> Software that supports both variants must therefore establish a policy. The
> software that I work on, gretl, has chosen (bowing to the apparently
> inevitable) to make gtk3 the default, if available, but we have a configure
> option
>
> --enable-gtk2
>
> Most users won't have to worry about this. If they only have gtk2, that will
> be used regardless; if they only have gtk3, that will be used regardless; if
> they have both, gtk3 will be used unless they apply this "enable" flag when
> configuring.

In the ConTeXt of gnuplot this would translate to:
- if user has only wxWidgets 3.0, use 3.0
- if user has only wxWidgets 2.8, use 2.8
- if user has both, pick wxWidgets 3.0

Or what else exactly would you do with GTK versions?

(I admit that MacPorts can have both wxWidgets 3.0 with Cocoa and
wxWidgets 3.0 with GTK installed. But they are both "well hidden" and
packages depending on either need to clearly specify the path to
wxWidgets. I don't know a better way yet.)

Mojca

Re: build problems with wxGTK 3.0

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

On Thu, 19 Jun 2014, Ethan A Merritt wrote:

> On Thursday, 19 June, 2014 22:27:46 Mojca Miklavec wrote:
>> On Thu, Jun 19, 2014 at 9:31 PM, Ethan A Merritt
>
>>>> So please also check whether wxWidgets are using gtk2 or gtk3 before
>>>> calling pkg-config to supply build flags.
>>>
>>> That's a chicken-or-egg dilemma.
>>> wx-config is supposed to tell us the version, but we need the version in
>>> order to call the correct wx-config.
>>
>> I don't see any chicken here ;)
>>
>> Once gnuplot calls
>>     WX_CXXFLAGS="`$WX_CONFIG --cxxflags
>> it already knows which $WX_CONFIG it is calling.
>>
>> The problematic line is only
>>     PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
>>
>> Gnuplot should run
>>     "$WX_CONFIG" --basename | <grep something>
>> before asking for gtk+-2.0.
>
> On linux (at least on my machines) there are two different wx-configs,
> one for wx2 and one for wx3.   You need to pick up the version from somewhere
> before you even know which one to run.

Running on Mac, Mojca may or may not realize that most, if not all, 
modern Linux distros pack both gtk2 and gtk3, and therefore both 
variants of wxWidgets may also be present.

Software that supports both variants must therefore establish a 
policy. The software that I work on, gretl, has chosen (bowing to 
the apparently inevitable) to make gtk3 the default, if available, 
but we have a configure option

--enable-gtk2

Most users won't have to worry about this. If they only have gtk2, 
that will be used regardless; if they only have gtk3, that will be 
used regardless; if they have both, gtk3 will be used unless they 
apply this "enable" flag when configuring.

Allin Cottrell

Re: build problems with wxGTK 3.0

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

On Thu, Jun 19, 2014 at 10:36 PM, Ethan A Merritt wrote:
> On Thursday, 19 June, 2014 22:27:46 Mojca Miklavec wrote:
>> On Thu, Jun 19, 2014 at 9:31 PM, Ethan A Merritt
>
>> >> So please also check whether wxWidgets are using gtk2 or gtk3 before
>> >> calling pkg-config to supply build flags.
>> >
>> > That's a chicken-or-egg dilemma.
>> > wx-config is supposed to tell us the version, but we need the version in
>> > order to call the correct wx-config.
>>
>> I don't see any chicken here ;)
>>
>> Once gnuplot calls
>>     WX_CXXFLAGS="`$WX_CONFIG --cxxflags
>> it already knows which $WX_CONFIG it is calling.
>>
>> The problematic line is only
>>     PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
>>
>> Gnuplot should run
>>     "$WX_CONFIG" --basename | <grep something>
>> before asking for gtk+-2.0.
>
> On linux (at least on my machines) there are two different wx-configs,
> one for wx2 and one for wx3.   You need to pick up the version from somewhere
> before you even know which one to run.

There are two issues here:
- picking up the right wxWidgets (wxWidgets 2.8 vs. wxWidgets 3.0)
- using the right GTK (GTK 2 or 3; if wxWidgets depends on GTK at all)

I don't know how you want to pick "the right" wxWidgets, but I prefer to use
    --with-wx-config=/path/to/the/desired/wx/bin/wx-config
or
    --with-wxdir=/path/to/the/desired/wx/bin
or in case of gnuplot (which has the argument name different from the
official one)
    --with-wx=/path/to/the/desired/wx/bin

Then the wxWidgets version is set in stone.

>> Here's what FileZilla does for example:
>>     http://svn.filezilla-project.org/filezilla/FileZilla3/trunk/configure.ac?view=markup
>>
>>     if echo "`$WX_CONFIG_WITH_ARGS --basename`" | grep -i gtk2 >
>> /dev/null 2>&1; then
>>       PKG_CHECK_MODULES(LIBGTK, gtk+-2.0,, [
>>         AC_MSG_ERROR([gtk+-2.0 was not found ...])
>>       ])
>>     fi
>>     if echo "`$WX_CONFIG_WITH_ARGS --basename`" | grep -i gtk3 >
>> /dev/null 2>&1; then
>>       PKG_CHECK_MODULES(LIBGTK, gtk+-3.0,, [
>>         AC_MSG_ERROR([gtk+-3.0 was not found ...])
>>       ])
>>     fi
>
> So what happens if both are installed?

This is not a question of what happens if both gtk 2 and 3 are
installed because that's easily the case.

But in the case above
    `$WX_CONFIG_WITH_ARGS --basename`
one gets something like:

$ wx-config --basename
wx_gtk3u

I have both GTK 2 and GTK 3 installed, but --basename tells me that
wxWidgets requires GTK 3

With the code above you cannot get both
    wx_gtk3u | grep gtk2
and
    wx_gtk3u | grep gtk3
to return you the result. In the code above exactly one GTK version
will be asked for.

>> > I suppose we can add configuration options --with-gtk={ gtk2 | gtk3 }
>>
>> No, please don't. The user has zero influence on that and that is only
>> going to lead into problems. Gnuplot should automatically determine
>> whether wxWidgets are using GTK and if so, which version. wx-config
>> --basename return wx_gtk2* or wx_gtk3* ("*" can be different endings
>> based on other characteristics of the installation).
>
> There's your chicken.

I don't understand.

You can have
- wxWidgets 2.8 compiled against GTK 2 and
- wxWidgets 3.0 compiled against GTK 2
What exacly would --with-gtk=gtk3 do in that case? GTK 3 wouldn't work
with either.

Mojca

Re: build problems with wxGTK 3.0

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

On Thu, 19 Jun 2014, Ethan A Merritt wrote:

[backtrace snipped]

> Yes, gtk and/or wxWidgets should declare what support libraries are
> required.  That is what `wx-config --libs`   is supposed to do.
> But it doesn't.
>
> I really am at a loss.  I don't see how gnuplot can determine whether
> or not wxWidgets requires X11 if it doesn't tell us.

IMO you're quite right. The breakage is in wxWidgets.

People who are packaging gnuplot for distros will work around this, 
such that end-users don't have to know. People who are building 
gnuplot for themselves and are missing the X11 link will just have 
to be savvy enough to add it themselves. It won't be the first or 
last time that such breakage has occurred in the free software 
world.

Allin Cottrell

Re: build problems with wxGTK 3.0

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

On Thursday, 19 June, 2014 22:27:46 Mojca Miklavec wrote:
> On Thu, Jun 19, 2014 at 9:31 PM, Ethan A Merritt

> >> So please also check whether wxWidgets are using gtk2 or gtk3 before
> >> calling pkg-config to supply build flags.
> >
> > That's a chicken-or-egg dilemma.
> > wx-config is supposed to tell us the version, but we need the version in
> > order to call the correct wx-config.
> 
> I don't see any chicken here ;)
> 
> Once gnuplot calls
>     WX_CXXFLAGS="`$WX_CONFIG --cxxflags
> it already knows which $WX_CONFIG it is calling.
> 
> The problematic line is only
>     PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
> 
> Gnuplot should run
>     "$WX_CONFIG" --basename | <grep something>
> before asking for gtk+-2.0.

On linux (at least on my machines) there are two different wx-configs,
one for wx2 and one for wx3.   You need to pick up the version from somewhere
before you even know which one to run.

> Here's what FileZilla does for example:
>     http://svn.filezilla-project.org/filezilla/FileZilla3/trunk/configure.ac?view=markup
> 
>     if echo "`$WX_CONFIG_WITH_ARGS --basename`" | grep -i gtk2 >
> /dev/null 2>&1; then
>       PKG_CHECK_MODULES(LIBGTK, gtk+-2.0,, [
>         AC_MSG_ERROR([gtk+-2.0 was not found ...])
>       ])
>     fi
>     if echo "`$WX_CONFIG_WITH_ARGS --basename`" | grep -i gtk3 >
> /dev/null 2>&1; then
>       PKG_CHECK_MODULES(LIBGTK, gtk+-3.0,, [
>         AC_MSG_ERROR([gtk+-3.0 was not found ...])
>       ])
>     fi

So what happens if both are installed?

> > I suppose we can add configuration options --with-gtk={ gtk2 | gtk3 }
> 
> No, please don't. The user has zero influence on that and that is only
> going to lead into problems. Gnuplot should automatically determine
> whether wxWidgets are using GTK and if so, which version. wx-config
> --basename return wx_gtk2* or wx_gtk3* ("*" can be different endings
> based on other characteristics of the installation).

There's your chicken.

> > but that won't make the gtk3 build actually work, because we already
> > know it doesn't report the correct set of libraries that are needed.
> 
> The problem above is unrelated. Adding extra flags is slightly
> different that preventing the user to even compile gnuplot (by adding
> incompatible flags).
> 
> 
> >> > 1037c1037,1038
> >> > <     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null; then
> >> > ---
> >> >>     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null && \
> >> >>       ${WX_CONFIG} --basename | grep 'wx_gtk' >/dev/null 2>&1; then
> >>
> >> Yes, checking for wx_gtk should help, even though I believe that some
> >> package (either gtk or wxwidgets) should suggest the proper flag.
> >
> > But that is exactly the problem!
> 
> I'm not saying that this is ideal. Just saying that this is better
> than the current situation where you add X11 unconditionally; it would
> help to eliminate problems at least in the cases where wxWidgets is
> not even based on GTK.
> 
> (But then again it is probably a lot easier to add compiler flags than
> to remove them.)
> 
> > Yes, gtk and/or wxWidgets should declare what support libraries are
> > required.  That is what `wx-config --libs`   is supposed to do.
> > But it doesn't.
> 
> I would ask the wxWidgets developers for advice.
> 
> Mojca

Re: build problems with wxGTK 3.0

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

On Thu, Jun 19, 2014 at 9:31 PM, Ethan A Merritt
<sf...@us...> wrote:
> On Thursday, 19 June, 2014 11:33:34 Mojca Miklavec wrote:
>> On Thu, Jun 19, 2014 at 10:05 AM, Jun T. wrote:
>> > On 2014/06/17, at 4:43, Ethan A Merritt wrote:
>> >> So I have changed gnuplot's autoconfigure script to add -lX11
>> >> itself if it sees that the newer wxWidgets is being used.
>> >
>> > This causes a problem on my Mac (and maybe on other systems);
>> > the linker dies saying "-lX11 can't be found".
>> > (OS X 10.8 / no X11 installed / wxWidgets=svn HEAD)
>>
>> Confirmed. You shouldn't unconditionally link to X11 (in particular
>> not on Mac). The check for wx_gtk should be better, but then again gtk
>> also works with quartz on OS X. Honestly I don't expect people to use
>> wxGTK 3.0 with quartz on Macs when they can use Cocoa (unless maybe
>> with wxGTK 2.8 to get support for old software that hasn't been ported
>> to 3.0, but then again wxWidgets 2.8 won't work with GTK/quartz
>> without quite a bit of patching).
>>
>> I wanted to test gnuplot with wxGTK 3.0 on Mac, but it didn't work at
>> all because I have it linked against gtk 3.0 and gnuplot fails because
>> it has a fixed idea that wxGTK is using GTK+ 2:
>>
>> if test "${enable_wxwidgets_ok}" = yes ; then
>>   WX_CXXFLAGS="`$WX_CONFIG --cxxflags | sed 's/-fno-exceptions//'`
>> $CAIROPANGO_CFLAGS"
>>   WX_LIBS="`$WX_CONFIG --libs` $CAIROPANGO_LIBS"
>>
>>   dnl Check for fork(), used for the 'persist' effect
>>   AC_FUNC_FORK
>>
>>   dnl Check for gtk (raise/lower tweaks)
>>   PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
>>   if  test "${have_gtk}" = yes ; then
>>     AC_DEFINE(HAVE_GTK, 1, [Define to use gtk/gdk tweaks])
>>     WX_CXXFLAGS="$WX_CXXFLAGS $GTK_CFLAGS"
>>     WX_LIBS="$WX_LIBS $GTK_LIBS"
>>   fi
>>
>>   dnl The user can force single-threaded mode
>>   AC_ARG_WITH(wx-single-threaded, dnl
>>   [--with-wx-single-threaded   do not use multithreaded wxgtk even if
>> available],
>>   WX_CXXFLAGS="$WX_CXXFLAGS -DWXT_MONOTHREADED",~
>>   )
>>
>>   dnl Check for gtk>2.8 for direct rendering to screen
>>   PKG_CHECK_MODULES(GTK28, [gtk+-2.0 >= 2.8.0], have_gtk28=yes, have_gtk28=no)
>>   if  test "${have_gtk28}" = yes ; then
>>     AC_DEFINE(HAVE_GTK28, 1, [Define to use gtk+ functions to handle cairo])
>>   fi
>>
>> So please also check whether wxWidgets are using gtk2 or gtk3 before
>> calling pkg-config to supply build flags.
>
> That's a chicken-or-egg dilemma.
> wx-config is supposed to tell us the version, but we need the version in
> order to call the correct wx-config.

I don't see any chicken here ;)

Once gnuplot calls
    WX_CXXFLAGS="`$WX_CONFIG --cxxflags
it already knows which $WX_CONFIG it is calling.

The problematic line is only
    PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)

Gnuplot should run
    "$WX_CONFIG" --basename | <grep something>
before asking for gtk+-2.0.

Here's what FileZilla does for example:
    http://svn.filezilla-project.org/filezilla/FileZilla3/trunk/configure.ac?view=markup

    if echo "`$WX_CONFIG_WITH_ARGS --basename`" | grep -i gtk2 >
/dev/null 2>&1; then
      PKG_CHECK_MODULES(LIBGTK, gtk+-2.0,, [
        AC_MSG_ERROR([gtk+-2.0 was not found ...])
      ])
    fi
    if echo "`$WX_CONFIG_WITH_ARGS --basename`" | grep -i gtk3 >
/dev/null 2>&1; then
      PKG_CHECK_MODULES(LIBGTK, gtk+-3.0,, [
        AC_MSG_ERROR([gtk+-3.0 was not found ...])
      ])
    fi


> I suppose we can add configuration options --with-gtk={ gtk2 | gtk3 }

No, please don't. The user has zero influence on that and that is only
going to lead into problems. Gnuplot should automatically determine
whether wxWidgets are using GTK and if so, which version. wx-config
--basename return wx_gtk2* or wx_gtk3* ("*" can be different endings
based on other characteristics of the installation).

> but that won't make the gtk3 build actually work, because we already
> know it doesn't report the correct set of libraries that are needed.

The problem above is unrelated. Adding extra flags is slightly
different that preventing the user to even compile gnuplot (by adding
incompatible flags).


>> > 1037c1037,1038
>> > <     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null; then
>> > ---
>> >>     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null && \
>> >>       ${WX_CONFIG} --basename | grep 'wx_gtk' >/dev/null 2>&1; then
>>
>> Yes, checking for wx_gtk should help, even though I believe that some
>> package (either gtk or wxwidgets) should suggest the proper flag.
>
> But that is exactly the problem!

I'm not saying that this is ideal. Just saying that this is better
than the current situation where you add X11 unconditionally; it would
help to eliminate problems at least in the cases where wxWidgets is
not even based on GTK.

(But then again it is probably a lot easier to add compiler flags than
to remove them.)

> Yes, gtk and/or wxWidgets should declare what support libraries are
> required.  That is what `wx-config --libs`   is supposed to do.
> But it doesn't.

I would ask the wxWidgets developers for advice.

Mojca

Re: build problems with wxGTK 3.0

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

On Thursday, 19 June, 2014 11:33:34 Mojca Miklavec wrote:
> On Thu, Jun 19, 2014 at 10:05 AM, Jun T. wrote:
> > On 2014/06/17, at 4:43, Ethan A Merritt wrote:
> >> So I have changed gnuplot's autoconfigure script to add -lX11
> >> itself if it sees that the newer wxWidgets is being used.
> >
> > This causes a problem on my Mac (and maybe on other systems);
> > the linker dies saying "-lX11 can't be found".
> > (OS X 10.8 / no X11 installed / wxWidgets=svn HEAD)
> 
> Confirmed. You shouldn't unconditionally link to X11 (in particular
> not on Mac). The check for wx_gtk should be better, but then again gtk
> also works with quartz on OS X. Honestly I don't expect people to use
> wxGTK 3.0 with quartz on Macs when they can use Cocoa (unless maybe
> with wxGTK 2.8 to get support for old software that hasn't been ported
> to 3.0, but then again wxWidgets 2.8 won't work with GTK/quartz
> without quite a bit of patching).
> 
> I wanted to test gnuplot with wxGTK 3.0 on Mac, but it didn't work at
> all because I have it linked against gtk 3.0 and gnuplot fails because
> it has a fixed idea that wxGTK is using GTK+ 2:
> 
> if test "${enable_wxwidgets_ok}" = yes ; then
>   WX_CXXFLAGS="`$WX_CONFIG --cxxflags | sed 's/-fno-exceptions//'`
> $CAIROPANGO_CFLAGS"
>   WX_LIBS="`$WX_CONFIG --libs` $CAIROPANGO_LIBS"
> 
>   dnl Check for fork(), used for the 'persist' effect
>   AC_FUNC_FORK
> 
>   dnl Check for gtk (raise/lower tweaks)
>   PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
>   if  test "${have_gtk}" = yes ; then
>     AC_DEFINE(HAVE_GTK, 1, [Define to use gtk/gdk tweaks])
>     WX_CXXFLAGS="$WX_CXXFLAGS $GTK_CFLAGS"
>     WX_LIBS="$WX_LIBS $GTK_LIBS"
>   fi
> 
>   dnl The user can force single-threaded mode
>   AC_ARG_WITH(wx-single-threaded, dnl
>   [--with-wx-single-threaded   do not use multithreaded wxgtk even if
> available],
>   WX_CXXFLAGS="$WX_CXXFLAGS -DWXT_MONOTHREADED",~
>   )
> 
>   dnl Check for gtk>2.8 for direct rendering to screen
>   PKG_CHECK_MODULES(GTK28, [gtk+-2.0 >= 2.8.0], have_gtk28=yes, have_gtk28=no)
>   if  test "${have_gtk28}" = yes ; then
>     AC_DEFINE(HAVE_GTK28, 1, [Define to use gtk+ functions to handle cairo])
>   fi
> 
> 
> and then the build fails with
> 
> In file included from ../../src/wxterminal/wxt_gui.cpp:97:
> In file included from ../../src/wxterminal/wxt_gui.h:183:
> In file included from /opt/local/include/gtk-2.0/gdk/gdk.h:32:
> In file included from /opt/local/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31:
> In file included from /opt/local/include/gtk-2.0/gdk/gdkscreen.h:32:
> /opt/local/include/gtk-2.0/gdk/gdktypes.h:114:39: error: typedef
> redefinition with different types ('struct _GdkDrawable' vs 'struct
> _GdkWindow')
> typedef struct _GdkDrawable           GdkWindow;
>                                       ^
> /path/to/wxGTK/3.0/include/wx-3.0/wx/defs.h:3412:31: note: previous
> definition is here
>     typedef struct _GdkWindow GdkWindow;
>                               ^
> 1 error generated.
>
> So please also check whether wxWidgets are using gtk2 or gtk3 before
> calling pkg-config to supply build flags.

That's a chicken-or-egg dilemma.
wx-config is supposed to tell us the version, but we need the version in
order to call the correct wx-config.

I suppose we can add configuration options --with-gtk={ gtk2 | gtk3 }
but that won't make the gtk3 build actually work, because we already
know it doesn't report the correct set of libraries that are needed.


> > The following may be a possible fix, but not tested at all on Linux.
> >
> >
> > Index: configure.in
> > ===================================================================
> > RCS file: /cvsroot/gnuplot/gnuplot/configure.in,v
> > retrieving revision 1.368
> > diff -r1.368 configure.in
> > 1037c1037,1038
> > <     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null; then
> > ---
> >>     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null && \
> >>       ${WX_CONFIG} --basename | grep 'wx_gtk' >/dev/null 2>&1; then
> 
> Yes, checking for wx_gtk should help, even though I believe that some
> package (either gtk or wxwidgets) should suggest the proper flag.

But that is exactly the problem!
Yes, gtk and/or wxWidgets should declare what support libraries are 
required.  That is what `wx-config --libs`   is supposed to do.
But it doesn't.    

I really am at a loss.  I don't see how gnuplot can determine whether
or not wxWidgets requires X11 if it doesn't tell us.

	Ethan

Re: Patch: Key position information

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

[snip]

> > The commands given above recreate the last position
> > of the key. By adding/subtracting appropriate values,
> > one can achieve any desired offset
> 
> So now I'm confused.
> I don't see how this addresses the problem you described before,
> that trivial changes to a key title, the terminal type, etc. can cause
> the key layout to change.  Reproducing the same center position
> won't help much if the number of columns changes, or even if the
> whole thing suddenly becomes wider.

Because this was never the problem I tried to solve!

Here is the problem I try to solve:
1) I create a plot. Gnuplot choses a key position.
2) I like the key position overall, but would like
  to move the key slightly from its default position.
3) To do so, I need to know the values of its default
  coordinates, so that I can use them to calculate
  new coordinates that I can feed to "set key at...".

I understand that changing the key content will change
everything, I also understand that changing the terminal
type will change everything. But that's not the problem
I am trying to solve.

Maybe it's best not to get hung up on the use case.
Let's focus on the overall idea: Gnuplot makes info
on the most recent plot available in GPVAL variables.
It should really include info on the key, as well.

> 
> > The patch is available here, if you want to check
> > it out:
> > 	http://www.philipp-janert.com/keypos.patch
> 
> Why not put it on the project patch tracker?
> 
> 	Ethan

Re: Patch: Key position information

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

On Thursday, 19 June, 2014 10:41:16 Philipp K. Janert wrote:
> 
> Gnuplot makes a lot of information about the most
> recent plot available through GPVAL variables. It
> seems reasonable to include information about the
> current position of the key.
> 
> I prepared a small patch that populates four new
> variables for each plot:
> 	GPVAL_KEY_XCENTER
> 	GPVAL_KEY_YCENTER
> 	GPVAL_KEY_WIDTH
> 	GPVAL_KEY_HEIGHT
> 
> Using the information in these variables, one can
> recreate the most recent positioning of the key
> as follows:
> 
> plot sin(x)
> set key center at screen \
> GPVAL_KEY_XCENTER/GPVAL_TERM_XSIZE,GPVAL_KEY_YCENTER/GPVAL_TERM_YSIZE
> replot
> 
> For 3dim graphs, there is an additional wrinkle, 
> because splot does only honor the horizontal
> (right/center/left) positioning commands, but
> always uses "top" for vertical positioning.
> Hence, one needs to modify the vertical position:
> 
> splot sin(x)*cos(y)
> set key center at screen \
> GPVAL_KEY_XCENTER/GPVAL_TERM_XSIZE, \
> (GPVAL_KEY_YCENTER+GPVAL_KEY_HEIGHT/2)/GPVAL_TERM_YSIZE
> replot
> 
> The commands given above recreate the last position
> of the key. By adding/subtracting appropriate values,
> one can achieve any desired offset

So now I'm confused.
I don't see how this addresses the problem you described before,
that trivial changes to a key title, the terminal type, etc. can cause
the key layout to change.  Reproducing the same center position
won't help much if the number of columns changes, or even if the
whole thing suddenly becomes wider.

> The patch is available here, if you want to check
> it out:
> 	http://www.philipp-janert.com/keypos.patch

Why not put it on the project patch tracker?

	Ethan

Patch: Key position information

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

Gnuplot makes a lot of information about the most
recent plot available through GPVAL variables. It
seems reasonable to include information about the
current position of the key.

I prepared a small patch that populates four new
variables for each plot:
	GPVAL_KEY_XCENTER
	GPVAL_KEY_YCENTER
	GPVAL_KEY_WIDTH
	GPVAL_KEY_HEIGHT

Using the information in these variables, one can
recreate the most recent positioning of the key
as follows:

plot sin(x)
set key center at screen \
GPVAL_KEY_XCENTER/GPVAL_TERM_XSIZE,GPVAL_KEY_YCENTER/GPVAL_TERM_YSIZE
replot

For 3dim graphs, there is an additional wrinkle, 
because splot does only honor the horizontal
(right/center/left) positioning commands, but
always uses "top" for vertical positioning.
Hence, one needs to modify the vertical position:

splot sin(x)*cos(y)
set key center at screen \
GPVAL_KEY_XCENTER/GPVAL_TERM_XSIZE, \
(GPVAL_KEY_YCENTER+GPVAL_KEY_HEIGHT/2)/GPVAL_TERM_YSIZE
replot

The commands given above recreate the last position
of the key. By adding/subtracting appropriate values,
one can achieve any desired offset.

The patch is available here, if you want to check
it out:
	http://www.philipp-janert.com/keypos.patch

Best,

		Ph.

Re: CVS build fails on Ubuntu 14.04 i386

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

On Thursday, 19 June 2014 05:05:45 PM Jun T. wrote:
> On 2014/06/17, at 4:43, Ethan A Merritt <sf...@us...> wrote:
> > So I have changed gnuplot's autoconfigure script to add -lX11
> > itself if it sees that the newer wxWidgets is being used.
> 
> This causes a problem on my Mac (and maybe on other systems);
> the linker dies saying "-lX11 can't be found".
> (OS X 10.8 / no X11 installed / wxWidgets=svn HEAD)

I was afraid of that.

This is really a problem with the wxWidgets libraries and/or packaging.

If wx requires a initialization call to X11, it should make that call
itself rather than expecting the application to to the initialization.
Failing that, the wx package should at least have the configuration
tool wx-config report the correct dependencies.   If it requires
a call to X11 then it should add -lX11 to the list generated by
`wx-config --libs` or `wx-config --linkdeps`.  

As it stands, wx-config doesn't tell us what it needs so we have to
guess.  I will try to report this as a bug against wxWidgets itself,
but that won't fix any existing installations.


> The following may be a possible fix, but not tested at all on Linux.
> diff -r1.368 configure.in
> 1037c1037,1038
> <     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null; then
> ---
> >     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null && \
> >       ${WX_CONFIG} --basename | grep 'wx_gtk' >/dev/null 2>&1; then

As I understand it, wx_gtk does not necessarily use X11 as a 
back end.  So this test would not solve the problem for instance on
a linux system using wayland as a back end.


I notice that there was a bug-fix release of wxWidgets last week
(3.0.1).  There are two items in the ChangeLog that might possibly
affect this issue.  But even if they have fixed it, that still won't
make gnuplot's autoconfigure script work correctly on existing 
wxWidgets installations.

	Ethan

Re: Suggestions for 5.0: Margin (and Key)

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

On Thursday, 19 June 2014 09:35:55 AM pl...@pi... wrote:

> As I understand PS ( which I don't use much ) it relies on the fonts of 
> the host machine at the time it is printed, unless huge font information 
> is embedded in the PS file.
> 
> I suspect this will mean that this kind of careful hand tuning may come 
> unstuck when the PS plot is printed elsewhere than on the machine where 
> the manual optimisation was done.
> 
> If you are printing locally it should work fine.

It's worse than you think.
The font choice in PostScript is made by the printer, not the machine
from which the print command originated.  So the problem can in principle
arise even when you are printing locally.  

In practice this is usually only an issue for non-standard fonts, and you
do still have the option of embedding the font in the document.

	Ethan

Re: Spacebar does not raise command window with wxt terminal

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
> I tested again wxt terminal with noraise option on Ubuntu 12.04,
> space key did not also raise command window.
> 
> Seems to be sensitive to the build environment for the wxt term.
> 
> For qt term, it seem to be platform independent fault.  


Although it seems that the issue is sensitive for the wxt terminal, 
but the same issue for the qt terminal is environmental independent.

Therefore the issue for the qt terminal filed in the bug ticket.

https://sourceforge.net/p/gnuplot/bugs/1432/

The further discussion for the issue on qt terminal should be done at the bug ticket 
shown the above but not here.

Tatsuro

Re: Suggestions for 5.0: Margin (and Key)

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

On 06/19/14 01:10, Jonathan Thornburg wrote:
>
> 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,
>

Thanks for the example.

I've started a new thread where I suggest how this text placement 
problem could be addressed, since I think the whole discussion about 
margins is a work around for this core issue of text placement and extent.

Margins is not without merit as a discussion in the context of current 
gnuplot and may have wider application, so I've split my comments as a 
new thread discuss the underlying problem separately from the work around.

As I understand PS ( which I don't use much ) it relies on the fonts of 
the host machine at the time it is printed, unless huge font information 
is embedded in the PS file.

I suspect this will mean that this kind of careful hand tuning may come 
unstuck when the PS plot is printed elsewhere than on the machine where 
the manual optimisation was done.

If you are printing locally it should work fine.


Peter.

Re: Spacebar does not raise command window with wxt terminal

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
 
> ----- Original Message -----
>>>   >>>>> 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
>> 
>>  My problems seem specific to the "raise" function.
>>  For instance, the "r" key does properly switch on
>>  the ruler (so, it's not a focus issue).
> 
> 
> I have test on 5.0-rc1 on Ubuntu 12.04 LTS and windows 7.
> 
> On Ubuntu, on wxt and qt, space key functionality does not work, while on x11, 
> it works as expected.


I tested again wxt terminal with noraise option on Ubuntu 12.04,
space key did not also raise command window.

Seems to be sensitive to the build environment for the wxt term.

For qt term, it seem to be platform independent fault.  

Tatsuro

build problems with wxGTK 3.0

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

On Thu, Jun 19, 2014 at 10:05 AM, Jun T. wrote:
> On 2014/06/17, at 4:43, Ethan A Merritt wrote:
>> So I have changed gnuplot's autoconfigure script to add -lX11
>> itself if it sees that the newer wxWidgets is being used.
>
> This causes a problem on my Mac (and maybe on other systems);
> the linker dies saying "-lX11 can't be found".
> (OS X 10.8 / no X11 installed / wxWidgets=svn HEAD)

Confirmed. You shouldn't unconditionally link to X11 (in particular
not on Mac). The check for wx_gtk should be better, but then again gtk
also works with quartz on OS X. Honestly I don't expect people to use
wxGTK 3.0 with quartz on Macs when they can use Cocoa (unless maybe
with wxGTK 2.8 to get support for old software that hasn't been ported
to 3.0, but then again wxWidgets 2.8 won't work with GTK/quartz
without quite a bit of patching).

I wanted to test gnuplot with wxGTK 3.0 on Mac, but it didn't work at
all because I have it linked against gtk 3.0 and gnuplot fails because
it has a fixed idea that wxGTK is using GTK+ 2:

if test "${enable_wxwidgets_ok}" = yes ; then
  WX_CXXFLAGS="`$WX_CONFIG --cxxflags | sed 's/-fno-exceptions//'`
$CAIROPANGO_CFLAGS"
  WX_LIBS="`$WX_CONFIG --libs` $CAIROPANGO_LIBS"

  dnl Check for fork(), used for the 'persist' effect
  AC_FUNC_FORK

  dnl Check for gtk (raise/lower tweaks)
  PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
  if  test "${have_gtk}" = yes ; then
    AC_DEFINE(HAVE_GTK, 1, [Define to use gtk/gdk tweaks])
    WX_CXXFLAGS="$WX_CXXFLAGS $GTK_CFLAGS"
    WX_LIBS="$WX_LIBS $GTK_LIBS"
  fi

  dnl The user can force single-threaded mode
  AC_ARG_WITH(wx-single-threaded, dnl
  [--with-wx-single-threaded   do not use multithreaded wxgtk even if
available],
  WX_CXXFLAGS="$WX_CXXFLAGS -DWXT_MONOTHREADED",~
  )

  dnl Check for gtk>2.8 for direct rendering to screen
  PKG_CHECK_MODULES(GTK28, [gtk+-2.0 >= 2.8.0], have_gtk28=yes, have_gtk28=no)
  if  test "${have_gtk28}" = yes ; then
    AC_DEFINE(HAVE_GTK28, 1, [Define to use gtk+ functions to handle cairo])
  fi


and then the build fails with

In file included from ../../src/wxterminal/wxt_gui.cpp:97:
In file included from ../../src/wxterminal/wxt_gui.h:183:
In file included from /opt/local/include/gtk-2.0/gdk/gdk.h:32:
In file included from /opt/local/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31:
In file included from /opt/local/include/gtk-2.0/gdk/gdkscreen.h:32:
/opt/local/include/gtk-2.0/gdk/gdktypes.h:114:39: error: typedef
redefinition with different types ('struct _GdkDrawable' vs 'struct
_GdkWindow')
typedef struct _GdkDrawable           GdkWindow;
                                      ^
/path/to/wxGTK/3.0/include/wx-3.0/wx/defs.h:3412:31: note: previous
definition is here
    typedef struct _GdkWindow GdkWindow;
                              ^
1 error generated.


So please also check whether wxWidgets are using gtk2 or gtk3 before
calling pkg-config to supply build flags.

> The following may be a possible fix, but not tested at all on Linux.
>
>
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/configure.in,v
> retrieving revision 1.368
> diff -r1.368 configure.in
> 1037c1037,1038
> <     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null; then
> ---
>>     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null && \
>>       ${WX_CONFIG} --basename | grep 'wx_gtk' >/dev/null 2>&1; then

Yes, checking for wx_gtk should help, even though I believe that some
package (either gtk or wxwidgets) should suggest the proper flag.

Mojca

Re: Addlt info

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

On 06/19/14 01:12, Philipp K. Janert wrote:
> 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.

Like the spacebar,  set t wxt noraise  does work correctly here .

  x11-libs/wxGTK-2.8.12.1

Peter.

Re: CVS build fails on Ubuntu 14.04 i386

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

On 2014/06/17, at 4:43, Ethan A Merritt <sf...@us...> wrote:
> So I have changed gnuplot's autoconfigure script to add -lX11
> itself if it sees that the newer wxWidgets is being used.

This causes a problem on my Mac (and maybe on other systems);
the linker dies saying "-lX11 can't be found".
(OS X 10.8 / no X11 installed / wxWidgets=svn HEAD)

The following may be a possible fix, but not tested at all on Linux.


Index: configure.in
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/configure.in,v
retrieving revision 1.368
diff -r1.368 configure.in
1037c1037,1038
<     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null; then
---
>     if expr ${WXWIDGETS_VERSION} \> 2.8 >/dev/null && \
>       ${WX_CONFIG} --basename | grep 'wx_gtk' >/dev/null 2>&1; then

Re: Suggestions for 5.0: Margin (and Key)

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

On 06/19/14 08:39, sfeam wrote:
>
> On Wednesday, 18 June 2014 04:10:12 PM Jonathan Thornburg wrote:
>> 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.
>
> I understand what you want, but I don't see how to get there from here.
> Even if the program printed out or saved to GPVAL_* the full bounding box of
> the key, you couldn't use that to force the same key layout in another plot.
> There is just no command or underlying code currently that would do that.
>
> I can see adding a "tweak" command that is marginally easier than finding
> magic numbers like 0.45 and 0.975.  But you'd still have to do a trial
> plot for each change in font, output device, key title, etc. The "tweak"
> would essentially say "ok - do the same thing but offset it by [x,y]
> before actually drawing it".
>
> There is a history of requests for more flexibility in key layout,
> but no one has volunteered to rewrite or replace the existing code.
> I don't mind adding some "tweak" variant, but I'm not going to tackle
> anything major in this area myself.
>
> 	Ethan
>

Correct me if I'm wrong but this is not just a key text problem. It 
affects all text elements, labels etc.

If something can be done about this, it may help at least mapping out a 
plan of how it could be approached and what needs doing. Even if no one 
has time to start now.

That was my intent with the "Improving text positioning" post.

Peter.

Improving text positioning

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

from "Re: Suggestions for 5.0: Margin (and Key)"

On 06/19/14 00:53, Ethan A Merritt wrote:
> 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


This is the perennial problem of text size and placement coming up again 
and I think it is one of the major flaws in this otherwise excellent 
software.

I know this fundamentally comes from the way gnuplot architecture was 
designed with a plotting core and independent rendering "terminals"

Terminal communication is a one way process and there is currently no 
way for the text rendering facilities available to each terminal to be 
know by the plotting core in order to correctly place text elements. 
This forces some rather crude guessing and often excessive padding to 
avoid text over running axes etc.

This is clearly sub-optimal.

Now I know there are a lot of different contexts to be handled, like a 
postscript file does not even know the  available fonts until it is 
rendered on a particular machine. However, some terminals could do this 
a lot better and it seems everything is being dragged down to a lowest 
common denominator in the present situation.

Here are some suggestions of possible ways to improve things.

  Add some kind of two way communication to terminals like png so that 
precise text extent can be known. Prior to plotting, the plotting core 
sends an extent enquiry with a text sample and the terminal returns text 
extent values that the plotting core can use to precisely place text 
elements.  Then by the time it sends the plot to be rendered it will be 
optimally placed.

For terminals that are too dumb to do this or that themselves do not 
render immediately, so do not have the font metrics available to provide 
a text extent, the fall-back would be the same as it currently is.

Most of the live terminals x11, wxt, qt should be able to provide text 
extent data and that would at least mean working live would give nice 
clean text placements without all the large gaps that are currently 
produced, especially with longer text elements.

A switch could be provided to force the fall-back case for instances 
where a live terminal is being used to prototype output for PS or whatever.


I may be missing something, but I don't see why many of the most common 
and sophisticated terminals could not be made to handle this a lot more 
accurately than is presently the case.

Regards, Peter.

Re: Spacebar does not raise command window with wxt terminal

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

On Wed, Jun 18, 2014 at 10:14 PM, Tatsuro MATSUOKA <tma...@ya...>
wrote:

>
>
> Ubuntu: wxwidgtes 2.8.12, qt 4.8.1.
> Windows wxwidgtes 3.0.0, qt 5.3.0
>
> Does someone else check the qt terminal?
>
> Tatsuro
>


​Fedora 20 (x86_64)
qt 4.8.6
wxGTK 2.8.12
gnuplot 4.6.5 and 5.0rc1

wxt, x11 --> work (both 'noraise' options​, and space-bar switching to
console)
qt --> does not work (neither function)

​I played with windows focus mode (click-to-focus, focus-follows-mouse,
etc...) --
changing the policy does not seem to make any difference.​

​Also using either Gnome or  KDE Plasma desktop does not make a difference.​

​Sincerely,​

​Dmitri.​

--
​
​

Re: Suggestions for 5.0: Margin (and Key)

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

On Wednesday, 18 June 2014 04:10:12 PM Jonathan Thornburg wrote:
> 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.

I understand what you want, but I don't see how to get there from here.
Even if the program printed out or saved to GPVAL_* the full bounding box of
the key, you couldn't use that to force the same key layout in another plot.
There is just no command or underlying code currently that would do that.

I can see adding a "tweak" command that is marginally easier than finding
magic numbers like 0.45 and 0.975.  But you'd still have to do a trial
plot for each change in font, output device, key title, etc. The "tweak"
would essentially say "ok - do the same thing but offset it by [x,y]
before actually drawing it".

There is a history of requests for more flexibility in key layout,
but no one has volunteered to rewrite or replace the existing code.
I don't mind adding some "tweak" variant, but I'm not going to tackle
anything major in this area myself.

	Ethan

Re: Spacebar does not raise command window with wxt terminal

[Tatsuro M. <tma...@ya...>]

 > I have test on 5.0-rc1 on Ubuntu 12.04 LTS and windows 7.
> 
> On Ubuntu, on wxt and qt, space key functionality does not work, while on x11, 
> it works as expected.
> On windows, on qt, space key functionality does not work, while on wxt and 
> windows, it works as expected.  
> 
> Ubuntu: wxwidgtes 2.8.12, qt 4.8.1.
> Windows wxwidgtes 3.0.0, qt 5.3.0
> 
> Does someone else check the qt terminal?


For qt terminal I have done quick look into the code,
Is void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
in the qtterminal/QtGnuplotScene.cpp related this issue?

void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
{
updateModifiers();

int key = -1;
int live;

/// @todo quit on 'q' or Ctrl+'q'

// Keypad keys
if (event->modifiers() & Qt::KeypadModifier)
switch (event->key())
{
case Qt::Key_Space    : key = GP_KP_Space    ; break;
case Qt::Key_Tab      : key = GP_KP_Tab      ; break;
case Qt::Key_Enter    : key = GP_KP_Enter    ; break;
case Qt::Key_F1       : key = GP_KP_F1       ; break;
case Qt::Key_F2       : key = GP_KP_F2       ; break;
case Qt::Key_F3       : key = GP_KP_F3       ; break;
case Qt::Key_F4       : key = GP_KP_F4       ; break;
case Qt::Key_Insert   : key = GP_KP_Insert   ; break;
case Qt::Key_End      : key = GP_KP_End      ; break;
case Qt::Key_Down     : key = GP_KP_Down     ; break;
case Qt::Key_PageDown : key = GP_KP_Page_Down; break;
case Qt::Key_Left     : key = GP_KP_Left     ; break;
case Qt::Key_Right    : key = GP_KP_Right    ; break;
case Qt::Key_Home     : key = GP_KP_Home     ; break;
case Qt::Key_Up       : key = GP_KP_Up       ; break;
case Qt::Key_PageUp   : key = GP_KP_Page_Up  ; break;
case Qt::Key_Delete   : key = GP_KP_Delete   ; break;
case Qt::Key_Equal    : key = GP_KP_Equal    ; break;
case Qt::Key_Asterisk : key = GP_KP_Multiply ; break;
case Qt::Key_Plus     : key = GP_KP_Add      ; break;
case Qt::Key_Comma    : key = GP_KP_Separator; break;
case Qt::Key_Minus    : key = GP_KP_Subtract ; break;
case Qt::Key_Period   : key = GP_KP_Decimal  ; break;
case Qt::Key_Slash    : key = GP_KP_Divide   ; break;
case Qt::Key_0        : key = GP_KP_0        ; break;
case Qt::Key_1        : key = GP_KP_1        ; break;
case Qt::Key_2        : key = GP_KP_2        ; break;
case Qt::Key_3        : key = GP_KP_3        ; break;
case Qt::Key_4        : key = GP_KP_4        ; break;
case Qt::Key_5        : key = GP_KP_5        ; break;
case Qt::Key_6        : key = GP_KP_6        ; break;
case Qt::Key_7        : key = GP_KP_7        ; break;
case Qt::Key_8        : key = GP_KP_8        ; break;
case Qt::Key_9        : key = GP_KP_9        ; break;
}
// ASCII keys
else if ((event->key() <= 0xff) && (!event->text().isEmpty()))
// event->key() does not respect the case
key = event->text()[0].toLatin1();
// Special keys
else
switch (event->key())
{
case Qt::Key_Backspace  : key = GP_BackSpace  ; break;
case Qt::Key_Tab        : key = GP_Tab        ; break;
case Qt::Key_Return     : key = GP_Return     ; break;
case Qt::Key_Escape     : key = GP_Escape     ; break;
case Qt::Key_Delete     : key = GP_Delete     ; break;
case Qt::Key_Pause      : key = GP_Pause      ; break;
case Qt::Key_ScrollLock : key = GP_Scroll_Lock; break;
case Qt::Key_Insert     : key = GP_Insert     ; break;
case Qt::Key_Home       : key = GP_Home       ; break;
case Qt::Key_Left       : key = GP_Left       ; break;
case Qt::Key_Up         : key = GP_Up         ; break;
case Qt::Key_Right      : key = GP_Right      ; break;
case Qt::Key_Down       : key = GP_Down       ; break;
case Qt::Key_PageUp     : key = GP_PageUp     ; break;
case Qt::Key_PageDown   : key = GP_PageDown   ; break;
case Qt::Key_End        : key = GP_End        ; break;
case Qt::Key_Enter      : key = GP_KP_Enter   ; break;
case Qt::Key_F1         : key = GP_F1         ; break;
case Qt::Key_F2         : key = GP_F2         ; break;
case Qt::Key_F3         : key = GP_F3         ; break;
case Qt::Key_F4         : key = GP_F4         ; break;
case Qt::Key_F5         : key = GP_F5         ; break;
case Qt::Key_F6         : key = GP_F6         ; break;
case Qt::Key_F7         : key = GP_F7         ; break;
case Qt::Key_F8         : key = GP_F8         ; break;
case Qt::Key_F9         : key = GP_F9         ; break;
case Qt::Key_F10        : key = GP_F10        ; break;
case Qt::Key_F11        : key = GP_F11        ; break;
case Qt::Key_F12        : key = GP_F12        ; break;
}

if (key >= 0)
live = m_eventHandler->postTermEvent(GE_keypress,
int(m_lastMousePos.x()), int(m_lastMousePos.y()), key, 0, m_widget);
else
live = true;

// Key handling in persist mode 
// !live means (I think!) that we are in persist mode
if (!live) {
switch (key) {
default:
break;
case 'i':
int i = m_key_boxes.count();
/* FIXME: This shouldn't happen, but it does. */
if (i > m_plot_group.count())
    i = m_plot_group.count();
while (i-- > 0) {
bool isVisible = m_plot_group[i]->isVisible();
isVisible = !isVisible;
m_plot_group[i]->setVisible(isVisible);
m_key_boxes[i].setHidden(!isVisible);
}
break;
}
}

QGraphicsScene::keyPressEvent(event);
}

Tatsuro

Re: Spacebar does not raise command window with wxt terminal

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
>>  >>>>> 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
> 
> My problems seem specific to the "raise" function.
> For instance, the "r" key does properly switch on
> the ruler (so, it's not a focus issue).


I have test on 5.0-rc1 on Ubuntu 12.04 LTS and windows 7.

On Ubuntu, on wxt and qt, space key functionality does not work, while on x11, it works as expected.
On windows, on qt, space key functionality does not work, while on wxt and windows, it works as expected.  

Ubuntu: wxwidgtes 2.8.12, qt 4.8.1.
Windows wxwidgtes 3.0.0, qt 5.3.0

Does someone else check the qt terminal?

Tatsuro 

Re: Spacebar does not raise command window with wxt terminal

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

On Wed, 18 Jun 2014 23:16:38 +0200
pl...@pi... wrote:

> 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

My problems seem specific to the "raise" function.
For instance, the "r" key does properly switch on
the ruler (so, it's not a focus issue).



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