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

Re: can you tell me, pleas?

[<br...@ph...>]

Sultan Al-Qahtani wrote:

> And i helped me in drawing curves, my question is it (gnuplot)
> supporting web application? 

That question is much too vague to be meaningful.  The term "web 
application", for starters, is hopelessly ambiguous.  There are 
literally dozens of different ways of making the services of a program 
available via HTTP.  It all depends on what interfaces your web server 
application provides, and which of those you would like to use.

gnuplot can be used in CGIs, and from many scripting languages.

Re: wxWidgets terminal commited

[<br...@ph...>]

Timothée Lecomte wrote:

> You seem to have compiled wxWidgets as shared libraries. You can also
> compile it statically in gnuplot. 

I'm aware of that.  But I really don't think a library of this size is 
suitable for static linking.  It's simply too huge for that.

[cairo, pango & friends...]

> Fortunately, we have precompiled binaries for all of these on Windows !

Yes.  But what kind of a developer uses prebuilt binaries (and outdated 
ones, at that), where source is available?

> By the way, the only problem I had with pkg-config was to set up the path
> correctly. Is it also what you mean by forcing pkg-config to work ?

pkg-config is actually quite clever.  But the main problem was that some 
packages I wanted to build insisted on having a "libpng13" --- but the 
only package I found that actually provided a pkg-config entry under 
that name appears not to be a native Win32 (--> MinGW32) version.

And then of course there's that chicken-and-egg problem between 
pkg-config and glib...

> On the wxWidgets wiki, OpenWatcom is reported to work.

Yes --- I discovered the relevant files in the meantime.  But it appears 
to be only a limited part of the overall functionality.  Anyway, the 
true challenge for OpenWatcom will be to build or at least use all that 
Cairo/Pango stuff.

Re: wxWidgets terminal (another bug report)

[<tim...@en...>]

> Configuration fails if wxWidgets is disabled:
>
> lascaux [27] ./configure --disable-wxwidgets
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> [...snip...]
> checking for pdflib.h... yes
> checking for PDF_begin_pattern in -lpdf... yes
> checking for PDF_setdashpattern in -lpdf... yes
> checking for PDF_begin_document in -lpdf... yes
> checking for multi-byte support in x11... checking for XmbDrawString in
> -lX11... yes
> configure: error: conditional "am__fastdepCXX" was never defined.
> Usually this means the macro was only invoked conditionally.
> lascaux [28]

The error is pretty explicit. The problem is that I put the following
checks in 'if' block :

AC_PROG_CXX
AC_PROG_CXXCPP

I did that because C++ is not needed if the wxWidgets terminal is not
compiled. But I have not found any information about such a case on the
web.
Obviously this doesn't work, so I will have to put them
unconditionnally... at the risk of breaking a platform where there's no
C++ compiler. Is it acceptable ?

Timoth=E9e

Re: wxWidgets terminal commited

[<tim...@en...>]

> Timoth=E9e Lecomte wrote:
>> After 11 months of development, the wxWidgets has landed to the CVS !
>
> (Belated) congratulations from me, too.
>
> To explain why it took me so long: I tried to build this thing before
> commenting any further.  On Win32, just to make it bit more interesing.
>   Gosh --- I haven't had to download and install so many other packages
> to compile a single one since the days a Linux distro was something tha=
t
> fit on two or three dozen floppies, and running X11 on it was considere=
d
> an extravagant option.
>
> Let's see: so I had to get wxWidgets, obviously.  Getting that to
> compile was, ... tricky.  And its "make install" doesn't work --- puts
> the DLLs in $(prefix)/lib place where wgnuplot.exe doesn't find them.
> Windows tradition is to put DLLs in a the same place as the executables=
,
> since they'll be searched along the PATH.

Two remarks :
wxWidgets lacks precompiled libraries. It is said to be the policy of its
developpers not to provide any binaries, because that would be unrighteou=
s
to do that for one platform (likely Windows) but not others.
You seem to have compiled wxWidgets as shared libraries. You can also
compile it statically in gnuplot. That's what I have done for all the
snapshots that I provided on sourceforge.

> On top of that then I needed to add to my MSYS/MinGW installation:
> pkg-config, fontconfig, glib, cairo, pango, libpng (had it already, but
> not "libpng13", and no pkg-config file), gettext, libiconv.  I
> eventually gave up on building cairo and pango from source.  Now that I
> forced pkg-config to work, maybe I'll revisit cairo.

Fortunately, we have precompiled binaries for all of these on Windows !
The following page helped me to find them :
http://www.freeciv.org/index.php/Install-Windows

By the way, the only problem I had with pkg-config was to set up the path
correctly. Is it also what you mean by forcing pkg-config to work ?

> And that's before I even begin investigating the possibility of using m=
y
> now favourite Windows C/C++ compiler, OpenWatcom, to do this job.  I'm
> not even sure how to compile wxWidgets with that, yet.  I may have to
> dogde that and use MinGW-compiled DLLs with an OW-compiled wgnuplot.

On the wxWidgets wiki, OpenWatcom is reported to work.

> So, lots of new things to discover.

I guess it is the price to pay to use these great toys. I just hope it is
not too expensive.

Timoth=E9e

Re: wxWidgets terminal (another bug report)

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

Configuration fails if wxWidgets is disabled:

lascaux [27] ./configure --disable-wxwidgets
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
[...snip...]
checking for pdflib.h... yes
checking for PDF_begin_pattern in -lpdf... yes
checking for PDF_setdashpattern in -lpdf... yes
checking for PDF_begin_document in -lpdf... yes
checking for multi-byte support in x11... checking for XmbDrawString in -lX11... yes
configure: error: conditional "am__fastdepCXX" was never defined.
Usually this means the macro was only invoked conditionally.
lascaux [28]


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxWidgets terminal commited

[<br...@ph...>]

Timothée Lecomte wrote:
> After 11 months of development, the wxWidgets has landed to the CVS ! 

(Belated) congratulations from me, too.

To explain why it took me so long: I tried to build this thing before 
commenting any further.  On Win32, just to make it bit more interesing. 
  Gosh --- I haven't had to download and install so many other packages 
to compile a single one since the days a Linux distro was something that 
fit on two or three dozen floppies, and running X11 on it was considered 
an extravagant option.

Let's see: so I had to get wxWidgets, obviously.  Getting that to 
compile was, ... tricky.  And its "make install" doesn't work --- puts 
the DLLs in $(prefix)/lib place where wgnuplot.exe doesn't find them. 
Windows tradition is to put DLLs in a the same place as the executables, 
since they'll be searched along the PATH.

On top of that then I needed to add to my MSYS/MinGW installation: 
pkg-config, fontconfig, glib, cairo, pango, libpng (had it already, but 
not "libpng13", and no pkg-config file), gettext, libiconv.  I 
eventually gave up on building cairo and pango from source.  Now that I 
forced pkg-config to work, maybe I'll revisit cairo.

And that's before I even begin investigating the possibility of using my 
now favourite Windows C/C++ compiler, OpenWatcom, to do this job.  I'm 
not even sure how to compile wxWidgets with that, yet.  I may have to 
dogde that and use MinGW-compiled DLLs with an OW-compiled wgnuplot.

So, lots of new things to discover.

can you tell me, pleas?

[Sultan Al-Q. <to_...@ho...>]

Hello Mr.
I was working in gnuplot v 4.0 it was very nice and powerfull program. And i
helped me in drawing curves, my question is it (gnuplot) supporting web
application? if it is yes please tell me how i use it or how i connect to it
from web sit.

see myweb sit accepts information from user and convert this information
into number then draw these numbers in curve form,

please tell as soon as you get this message

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: wxWidgets terminal (bug report)

[<tim...@en...>]

> On Saturday 29 April 2006 02:25 pm, you wrote:
>>
>> "As soon as Fontconfig is properly setup, adding fonts is just a matte=
r
>> of
>> placing them into a directory that is searched by Fontconfig. Have a
>> look
>> at /etc/fonts/fonts.conf (and perhaps /etc/fonts/local.conf) to find o=
ut
>> what directories are searched.
>
> Aha. Thanks!
> I did not know about that mechanism at all, and have not
> been using it.  Adding that file makes a lot of difference :-) :-)
> My X11 setup uses a similar mechanism, but does it through
> /etc/X11/fs/config rather than /etc/fonts/fonts.conf
>
> With that file in place, I can now use all the fonts that I
> couldn't get before in wxt.  Including "Wingdings", which I thought you
> had said before was not working.

Hmmm. Interesting. Indeed, Wingdings works for me too. You made me give
another look at the "Symbol font problem", and I finally figure out the
following :

There are two types of Symbol fonts : the Adobe one, and the Microsoft
one. The Microsoft one is likely to use a different mapping than the Adob=
e
one, and the Adobe encoding is the "official". I have a Microsoft symbol
font installed (symbol.ttf in one of the fonts paths). I also had an Adob=
e
one brought by Acrobat Reader, but not in the fontconfig path. Finally I
had the Opensymbol font, brought by Openoffice (and available on several
distributions as a separate package), but again not in the fontconfig
path.

I added the two of them to the fontconfig package, runned 'fc-cache' and
they immediately appeared in all my kde apps ! Fontconfig is great !

However, they still appear with the utf-8 encoding, that is to say that
enhancedtext.dem still won't work without the function that translates th=
e
"Symbol encoding" to the utf-8 encoding.

That means that the system knows that the Symbol encoding is special, and
handle the case separately. After looking a little more, I found the
following file :

/usr/X11R6/lib/X11/fonts/encoding/adobe-symbol.enc.gz

which contains precisely the map from the Symbol characters to Unicode !
That's why the system understands this font as a normal font, after
applying this encoding translation.

So currently the path is the following :

input in Symbol encoding -> translation from Symbol to utf-8 by wxt ->
translation from utf-8 to the custom Symbol encoding by pango/X11 ->
proper rendering in the Symbol font

My layer ("translation to utf-8 by the wxWidgets terminal") is useful to
maintain compatibility with enhancedtext.dem, but will not work if the
user already enters its characters in utf-8 and chooses the Symbol font...
In this case the layer should not be used, and the characters should be
sent directly to pango.

Ouch ! Still have to figure out how to satisfy all cases...

Timoth=E9e

Re: wxWidgets terminal (bug report)

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

On Saturday 29 April 2006 02:25 pm, you wrote:
> 
> "As soon as Fontconfig is properly setup, adding fonts is just a matter of
> placing them into a directory that is searched by Fontconfig. Have a look
> at /etc/fonts/fonts.conf (and perhaps /etc/fonts/local.conf) to find out
> what directories are searched.

Aha. Thanks!  
I did not know about that mechanism at all, and have not
been using it.  Adding that file makes a lot of difference :-) :-)
My X11 setup uses a similar mechanism, but does it through 
/etc/X11/fs/config rather than /etc/fonts/fonts.conf

With that file in place, I can now use all the fonts that I 
couldn't get before in wxt.  Including "Wingdings", which I thought you
had said before was not working.  However, while playing around with this
I triggered the following:

%%%%%%%%%%%%%%%%%%%%% begin session log %%%%%%%%%%%%%%%%%%%%%%%%%%%%

lascaux [515] ./gnuplot

        G N U P L O T
        Version 4.1 patchlevel 0
        last modified April 2006
        System: Linux 2.6.12-12mdksmp

        Copyright (C) 1986 - 1993, 1998, 2004
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and requests for help to
                <gnu...@li...>
        Send bugs, suggestions and mods to
                <gnu...@li...>


Terminal type set to 'wxt'
gnuplot> set term wxt font 'vivaldi,20'
Terminal type set to 'wxt'
Options are '0 font "vivaldi,20"'
gnuplot> plot sin(x)/x
gnuplot>
gnuplot> set term wxt font 'wingdings,20'
Terminal type set to 'wxt'
*** glibc detected *** free(): invalid next size (fast): 0x083df148 ***
Abort

%%%%%%%%%%%%%%%%%%%%% end session log %%%%%%%%%%%%%%%%%%%%%%%%%%%%

Any idea what that's all about?
It is not the use of wingdings per se, because the font works
fine if I select it first rather than second.

Here is a minimal crashme.dem example:

  # Demonstrate bug in wxt
  set term wxt font "arial"
  plot sin(x)
  # crashes on next line, but only if a font size is given
  set term wxt font "wingdings,20"
  replot

And here is a trace from gdb:

*** glibc detected *** free(): invalid next size (fast): 0xb5c00510 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread -1229027648 (LWP 11253)]
0xffffe410 in __kernel_vsyscall ()
(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb6e43ef1 in raise () from /lib/tls/libc.so.6
#2  0xb6e4583b in abort () from /lib/tls/libc.so.6
#3  0xb6e79ff5 in __fsetlocking () from /lib/tls/libc.so.6
#4  0xb6e80587 in malloc_usable_size () from /lib/tls/libc.so.6
#5  0xb6e80a02 in free () from /lib/tls/libc.so.6
#6  0x08143215 in wxt_options () at ../term/wxt.trm:219
#7  0x080e4976 in set_terminal () at set.c:3645
#8  0x080db773 in set_command () at set.c:436
#9  0x08062221 in command () at command.c:530
#10 0x08061d2b in do_line () at command.c:382
#11 0x08061ba0 in com_line () at command.c:333
#12 0x080c1c56 in main (argc=1, argv=0xbff13294) at plot.c:638





-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxWidgets terminal commited

[<tim...@en...>]

> On Saturday 29 April 2006 12:25 am, Timoth=E9e Lecomte wrote:
>> After 11 months of development, the wxWidgets has landed to the CVS !
>
> Congrats!
>
> There are still some points that I do not understand about the terminal=
,
> even though I've been using it for a while now.
> Could you provide some additional information on
>
>  - where does the terminal find its fonts?  If I want to make a
>    new font available to it, where do I put it or what do I need
>    to change in the system configuration?

This is not explicitely detailed in the pango documentation, but it seems
reasonable to assume the following :

On Unix, pango can use any fonts that are know to FontConfig. Here is wha=
t
the GIMP documentation says about adding fonts to FontConfig:

"As soon as Fontconfig is properly setup, adding fonts is just a matter o=
f
placing them into a directory that is searched by Fontconfig. Have a look
at /etc/fonts/fonts.conf (and perhaps /etc/fonts/local.conf) to find out
what directories are searched. After copying the fonts there, you should
run fc-cache to regenerate the fonts cache. Fonts added this way will be
available to all applications using Fontconfig."

For example, on my system, /etc/fonts/fonts.conf says that it will look i=
nto:
/usr/share/fonts
/usr/X11R6/lib/X11/fonts/TTF
/usr/X11R6/lib/X11/fonts/Type1
/usr/X11R6/lib/X11//fonts/misc
/usr/X11R6/lib/X11/fonts/local
/usr/lib/X11/fonts/TTF
/usr/lib/X11/fonts/Type1
/usr/lib/X11/fonts/misc
/usr/lib/X11/fonts/local
~/.fonts

The last line allows you to install a font in your home directory, so tha=
t
you don't need administrator rights to add a font. FontConfig will also
look for user configuration in ~/.fonts.conf

This file also sets some aliases. For example, my configuration file
states that if I choose "serif" as a font, it will use either Bitstream
Vera Serif, Times New Roman, Luxi Serif, Times, etc. Pango will use the
first one that is able to represent all the characters of the string it
has to render.

Note that I have not done anything to configure this. It is usually done
by the distribution, and it is likely that you desktop environment
provides a configuration utility to add fonts to FontConfig (KDE and Gnom=
e
do).

On Windows, Pango will use the native Windows font system, so it should b=
e
customizable via the fonts control panel.

>  - How do I disable the 'q' and 'spacebar' hotkeys.
>    I know we've been discussing changing this everywhere,
>    but how do I do it right now?

Currently you can't disable it. I'm sorry !
By the way, if I implement something to optionally disable it, this
'spacebar'/'q' topic may vanish again. Let's come up with a global
solution that everybody agrees on. Then I would be glad to implement it.

>  - I do not understand what the logic is for resizing the plot
>    drawn in a resized window.  Unlike most (all?) other terminals,
>    the plot is not always redrawn so that it fills the window.
>    An explicit "replot" command always causes the plot to be redrawn
>    so that it fills the window; why does the dynamic re-sizing behave
>    differently?

It will resize the plot to fit in the window, but will keep the aspect
ratio (width/height) constant, so that if you just increase the window
width, nothing happens.

This behaviour can be discussed, and if needed, options can be added to
the configuration dialog.

>  - Also when the plot window is resized, sometimes the font size
>    stays the same, sometimes it scales smoothly, and sometimes
>    it jumps in increments.

I think it is related to the font antialiasing methods that are used by
pango. To make a font look nice on the screen, you have to make it fit to
the pixel grid. Here are the relevant parts of the cairo font
documentation :

"Hinting is the process of fitting font outlines to the pixel grid in
order to improve the appearance of the result. Since hinting outlines
involves distorting them, it also reduces the faithfulness to the origina=
l
outline shapes."

A side effect is that this fitting depends on the font size, so that the
font won't scale absolutely linearly with the window size.

>  - (programmers question): If I want to add itenms to the configuration
>    menu widget, what is required?  For instance, could one add a font
>    browser there?

The code for this widget lives in the wxtConfigDialog class.
A dialog like this is based on several controls (a checkbox, a slider,
etc.) embedded into "sizers", which will take care of their position in
the window (should the control be aligned on the left ? should it expand
with the window ? does it have a border around it ? etc.).

For example, you can easily add a checkbox for "ctrlq", which would behav=
e
as the checkbox for "raise" or "persist". When OK or APPLY is clicked, th=
e
value will be written in the wxConfig object, which represents a entry in
the registry under Windows, or a file ~/.gnuplot-wxt under Unix. This
value can then be used where appropriate.

I would be glad to give more details about it, but I would end up
rewriting the wxWidgets documentation ! (http://www.wxwidgets.org/manuals=
)

As far as a font browser is concerned, wxWidgets provides one :
http://www.wxwidgets.org/manuals/2.6.3/wx_commondialogsoverview.html#wxfo=
ntdialogoverview
It will list fonts and present a sample of the selected one.


I hope this helps.

Best regards,

Timoth=E9e

Re: wxWidgets terminal commited

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

On Saturday 29 April 2006 12:25 am, Timoth=E9e Lecomte wrote:
> After 11 months of development, the wxWidgets has landed to the CVS !=20

Congrats!

There are still some points that I do not understand about the terminal,
even though I've been using it for a while now.
Could you provide some additional information on

 - where does the terminal find its fonts?  If I want to make a
   new font available to it, where do I put it or what do I need
   to change in the system configuration?

 - How do I disable the 'q' and 'spacebar' hotkeys.
   I know we've been discussing changing this everywhere,
   but how do I do it right now?

 - I do not understand what the logic is for resizing the plot=20
   drawn in a resized window.  Unlike most (all?) other terminals,
   the plot is not always redrawn so that it fills the window.
   An explicit "replot" command always causes the plot to be redrawn
   so that it fills the window; why does the dynamic re-sizing behave
   differently?

 - Also when the plot window is resized, sometimes the font size
   stays the same, sometimes it scales smoothly, and sometimes
   it jumps in increments. =20

 - (programmers question): If I want to add itenms to the configuration
   menu widget, what is required?  For instance, could one add a font
   browser there?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

wxWidgets terminal commited

[<tim...@en...>]

Dear gnuplot developpers,

After 11 months of development, the wxWidgets has landed to the CVS ! (I
hope I did not make any mistake by the way)

I really would like to thank you, Hans-Bernhard, Ethan, Bastian, Petr,
Daniel, Ga=EBl for your help and your comments.

Let me explain a little about this work.

I think I fully fulfilled my initial goal : to contribute to an
open-source project, to learn more about programming, and to make
something to improve gnuplot, which I had used several times and
appreciated, as a graduating physics student (I now use it every day for =
a
research internship in solid-state physics).

From the pure wxWidgets terminal that it was at first, the concept evolve=
d
to a separation between the gui implemented in wxWidgets and the actual
plot rendering with cairo and pango. Meanwhile, my aim to work on
interactivity moved to rendering quality. I learned a lot about the
problems of graphics rendering. Using antialiasing intelligently is not
that straightforward, but hopefully the terminal implements it in a smart
enough way.

What to expect from this work in the future ?

First, the terminal is highly cross-platform.
To add a new supported platform, you "just" have to figure out a few thin=
gs :
- does wxWidgets on this platform require additional initialization calls
(probably not)?
- do I need to process the gui messages in a new loop (probably yes)?
- do wxWidgets on this platform support all the currently implemented
features (almost surely yes)?
- how to compile it ?

With these questions in mind, you can walk along the code in wxt_gui.cpp
and see whether you are in the wxGTK (ie wxWidgets built on top of gtk) o=
r
wxMSW (ie wxWidgets on top of Windows) case.

In addition to that, it is possible to add cairo hooks for direct
rendering to screen. It is currently implemented for Windows but not for
Unix, so that the wxWidgets terminal will be faster on Windows than on
Unix ! The code to activate it for Unix is there but not enabled because
current X servers do mostly fall back to software rendering, so it tends
to be slower than the all-software (and all cross-platform) rendering.

It means that it should be quite easy to make this terminal work for OS/2=
,
and Mac.

Then, cairo is still a very young library. It is already working quite
well : on a surface plot with pm3d, the rendering needs twice as much tim=
e
as the X11 terminal, but the plot is completely antialiased !
Nevertheless cairo is promised to a bright future. The next version (cair=
o
1.2) which is supposed to be ready in a few weeks, will add full support
for postscript and PDF output, and probably SVG. The following version to
be out at the end of this year, will be focused on performance. Currently=
,
it is worth noticing that cairo has received few attention regarding
optimization. Many algorithms (tesselator...) are said to be candidates
for a major speedup. cairo will be used in firefox 2 as the rendering
library on all platforms. It means that we will profit from a library use=
d
very broadly (gtk+ and firefox). No doubt that the wxWidgets terminal wil=
l
be faster in the next months.

Thank you again, and have fun with gnuplot !

Regards,

Timoth=E9e

Re: Bind <space> to builtin_raise in mouse.c

[<tim...@en...>]

> On Friday 28 April 2006 02:34 am, Bastian Maerkisch wrote:
>> For the standard OS/2 build we will have to leave out the linkage
>> requirement against X11 though. Too many systems do not have X11
>> installed.
>> Could we move the raise_console() code into a new executable instead?
>
> The new code must of course be subject to the same
> configuration tests and conditional compilation as we have now.

It is worth noting that there is already (a) special case(s) to
distinguish a OS/2 console and a Xterm-like console for other purposes.
For example, in readline.c (866) :

#ifdef OS2
/* We need to call different procedures, dependent on the
   session type: VIO/window or an (XFree86) xterm */
static char
os2_getch() {
  static int IsXterm =3D 0;
  static int init =3D 0;

  if (!init) {
     if (getenv("WINDOWID")) {
        IsXterm =3D 1;
     }
     init =3D 1;
  }
  if (IsXterm) {
     return ansi_getc();
  } else {
     return msdos_getch();
  }
}
#endif /* OS2 */


If this code has worked for years, and it is likely to be the case (
*_getch() is used for each input character), we can be confident that a
test for WINDOWID is enough to know who manages the console.

Timoth=E9e

Re: Bind <space> to builtin_raise in mouse.c

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

On Friday 28 April 2006 02:34 am, Bastian Maerkisch wrote:
> For the standard OS/2 build we will have to leave out the linkage
> requirement against X11 though. Too many systems do not have X11 installed.
> Could we move the raise_console() code into a new executable instead?

The new code must of course be subject to the same 
configuration tests and conditional compilation as we have now.

As to putting it in a separate executable, that's what
we have now already.  I don't see how changing from one external
executable to another helps in any way.

I'm still in favor of   ./configure --enable-console-raise
so I can turn it off permanently at build time.  OS/2 could
do the same if it is problematic.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Bind <space> to builtin_raise in mouse.c

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

Petr Mikulik wrote:
>>> Does it work for the other interactive terminals as well?
>>> I thought your wish for the API was that gnuplot is not linked=20
>>> against Xlib.
>>
>> I would prefer that, yes.  But during the course of this discussion I
>> have come to think there is no other way to correctly implement a
>> "raise console" function.  It can only be done by the core code.
>>
>> But if are to make this change, let us at least try to do it as
>> cleanly as possible.  It will definitely simplify the hot key
>> processing in gnuplot_x11, since it no longer needs to special
>> case these exceptions to the general key binding mechanism.
>> I am not familiar with the windows/pm code, but I would think
>> the same is true there.
>>
>> I am thinking that the cleanest way is to create a new core routine
>> raise_console().
>=20
> All that is fine with me.

I agree.

>=20
> Considering gnuplot under X11, the binary will have to be linked agains=
t=20
> -lX11, but as I can see it adds just 200 B of code, thus this is not an=
=20
> issue.
>=20

For the standard OS/2 build we will have to leave out the linkage
requirement against X11 though. Too many systems do not have X11 installe=
d.
Could we move the raise_console() code into a new executable instead?

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: Bind <space> to builtin_raise in mouse.c

[Petr M. <mi...@ph...>]

>> Does it work for the other interactive terminals as well?
>> I thought your wish for the API was that gnuplot is not linked against Xlib.
>
> I would prefer that, yes.  But during the course of this discussion I
> have come to think there is no other way to correctly implement a
> "raise console" function.  It can only be done by the core code.
>
> But if are to make this change, let us at least try to do it as
> cleanly as possible.  It will definitely simplify the hot key
> processing in gnuplot_x11, since it no longer needs to special
> case these exceptions to the general key binding mechanism.
> I am not familiar with the windows/pm code, but I would think
> the same is true there.
>
> I am thinking that the cleanest way is to create a new core routine
> raise_console().

All that is fine with me.

Considering gnuplot under X11, the binary will have to be linked against 
-lX11, but as I can see it adds just 200 B of code, thus this is not an 
issue.

---
PM

Re: Bind <space> to builtin_raise in mouse.c

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

On Thursday 27 April 2006 09:39 am, Petr Mikulik wrote:
> > machine and uses a different server path. Since the konsole window and
> > the plot window use different server paths, the "raise by window_id"
> > cannot work.
> 
> Yes, they run in windows launched from two different machines, in my simple 
> explanation (1st time I see "different server paths").

Sorry for any confusion; I don't know what the correct terminology is.
But it is not a question of which machine the executable is running on.
What matters is the X-server instance to which it is connected.
ssh-tunneling is a common example of why this is an issue, but
multi-head graphics setups are another example.  X-terminals
(archaic, yes, but we still have some) are another example.

 
> >>     This would need the new API for interactive terminals.
> >
> > I disagree.  The "close existing window" function is already
> > present in the current terminal interface (see x11), and the
> > raise_console function is not a terminal interface issue at all.
> > So raise_console() would have to be a core routine.
> 
> Does it work for the other interactive terminals as well?
> I thought your wish for the API was that gnuplot is not linked against Xlib.

I would prefer that, yes.  But during the course of this discussion I
have come to think there is no other way to correctly implement a
"raise console" function.  It can only be done by the core code.
Having realized that, my first preference is not to do it at all.
I fully understand that you disagree with me.

But if are to make this change, let us at least try to do it as
cleanly as possible.  It will definitely simplify the hot key 
processing in gnuplot_x11, since it no longer needs to special
case these exceptions to the general key binding mechanism.
I am not familiar with the windows/pm code, but I would think
the same is true there.

I am thinking that the cleanest way is to create a new core routine
raise_console().  It will be ugly, because it will have conditional
code for all the various platforms.  Remember that this conditional
code must match the type of the console window, not the type of the
plot window.  So, for instance, there should be no need for any
wxWidgets special code.  If you are running 'set term wx' under
windows you will need the windows code; it you are running
'set term wx' under X you will need the X code.  

I further suggest that this whole mechanism be under the control
of a configuration option, e.g.    ./configure --with-console-management
Those of us who have no need for it can omit it from the configuration.

 
> > At first I was confused, and thought that the core code should call
> > such a term->raise_console() routine. But this doesn't work for all
> > the reasons we went through earlier in this thread.
> 
> This could be for supporting "bind" commands to " " and "q":
> 
> term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, " ", ..._RAISE_CONSOLE, 0)

??  But the 'bind' mechanism is implemented in the core routines,
and once set up it applies equally to all terminals used in a gnuplot
session.  You will break this if you try to make it a terminal entry point
instead.  Switching terminals would lose your key bindings.
For that matter, closing and re-opening an x11 plot window would lose your
key bindings.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bind <space> to builtin_raise in mouse.c

[Petr M. <mi...@ph...>]

> machine and uses a different server path. Since the konsole window and
> the plot window use different server paths, the "raise by window_id"
> cannot work.

Yes, they run in windows launched from two different machines, in my simple 
explanation (1st time I see "different server paths").

>>     This would need the new API for interactive terminals.
>
> I disagree.  The "close existing window" function is already
> present in the current terminal interface (see x11), and the
> raise_console function is not a terminal interface issue at all.
> So raise_console() would have to be a core routine.

Does it work for the other interactive terminals as well?
I thought your wish for the API was that gnuplot is not linked against Xlib.

> At first I was confused, and thought that the core code should call
> such a term->raise_console() routine. But this doesn't work for all
> the reasons we went through earlier in this thread.

This could be for supporting "bind" commands to " " and "q":

term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, " ", ..._RAISE_CONSOLE, 0)
term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, " ", ..._RAISE_CONSOLE, 1)
term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, "q", ..._CLOSE_WINDOW, 0)
term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, "q", ..._CLOSE_WINDOW, 1)

>> If somebody wants to improve windows changes in some X11 combinations (as I
>> did for KDE, for example), he can contribute it to the appropriate place of
>> code, independently of the above ways.
>
> The "appropriate place" is exactly what we are struggling to find.

You have shown that on X11 it does not work when running gnuplot and its 
plot in windows belonging to different computers.

> It is not obvious where that place is.

BTW, I asked several times how to do the same Konsole "sheet flipping" for 
the gnome-terminal, but no one answered. So gnome-native users cannot enjoy 
the full functionality (but it works with a single gnome-terminal 
sheet/card).

---
PM

Re: Bind <space> to builtin_raise in mouse.c

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

On Wednesday 26 April 2006 11:21 pm, you wrote:
> Actually ... I've just tried to ssh' -X to our server from Konsole, 
> run xterm, run gnuplot, plot x, spacebar, and gnuplot pops up! 
  ^^^^^^^^^^
> So it should work also for you, why not?

That worked because you ran the xterm on the remote machine, so it used
the same display path as the gnuplot session.
But if you do it that way then the entire management of the xterm goes
over the net so it is relatively slow.  This faster way is to ssh in
and run gnuplot immediately (no remote xterm). That way the xterm window
is local to your seat, and fast, but the gnuplot process is on the remote
machine and uses a different server path. Since the konsole window and
the plot window use different server paths, the "raise by window_id" 
cannot work.

> In summary, there are two ways what to do:
> 1. No major changes
>     wxterminal copies the raising code from gclient, gplt_x11 and wgraph,
>     or
>     the code is moved into mousecmn.c and to be called from the above sources

I prefer the "bind" option.

> 2. Major changes
>     Let 'q' and ' ' be "bind"able. Needs routines raise_gnuplot_console

yes.

>     term->quit_window. 

but we already support this, at least for x11, with no special API.

>     This would need the new API for interactive terminals. 

I disagree.  The "close existing window" function is already 
present in the current terminal interface (see x11), and the 
raise_console function is not a terminal interface issue at all.
At first I was confused, and thought that the core code should call
such a term->raise_console() routine. But this doesn't work for all
the reasons we went through earlier in this thread.  
So raise_console() would have to be a core routine. 

> If somebody wants to improve windows changes in some X11 combinations (as I 
> did for KDE, for example), he can contribute it to the appropriate place of 
> code, independently of the above ways.

The "appropriate place" is exactly what we are struggling to find.
It is not obvious where that place is.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Bind <space> to builtin_raise in mouse.c

[Petr M. <mi...@ph...>]

>>> Give up on the whole idea of a generic mechanism for raising the console.
>>> It was not well thought out to begin with, and in fact is not even a
>>> well-defined operation.

The current spacebar is an operation which works well on "single-user" OS/2, 
Windows, and Linux. In the latter, there are many X11 window managers that 
can be set up into a dozen of behaviours, and you can set them up so the 
current spacebar operation is canceled by the window manager. But then it is 
not the private problem of gnuplot.

If you do some other tricks with X11 (logging into other servers, tunnelling 
your X11 protocol), then it may not work, as you have noticed.
Actually ... I've just tried to ssh' -X to our server from Konsole, run 
xterm, run gnuplot, plot x, spacebar, and gnuplot pops up! So it should work 
also for you, why not?

> Even still, as this currently works on my X11 system the space bar doesn't 
> even "raise the console"; it merely gives the console focus.

In all my environments it was always doing both...

>> * it will make the spacebar be a valid key to return from a pause (it is
>> * it won't break old scripts as it is only an interactive feature
>> If we finally choose this alternative, I would also drop the bound between
>> 'q' and 'close this window' :

OK with me, but let those chars to be "bind" by default.

> there's another obstacle that makes it unreliable : the 
> focus-stealing-prevention mechanism that is activated by default on 
> several desktops.

In recent versions of KDE, you must set "control center => windows behaviour 
=> advanced => protection level against stealing (??? or somehow like that) 
=> None". This info should probably go into "help mouse".


In summary, there are two ways what to do:
1. No major changes
    wxterminal copies the raising code from gclient, gplt_x11 and wgraph,
    or
    the code is moved into mousecmn.c and to be called from the above sources

2. Major changes
    Let 'q' and ' ' be "bind"able. Needs routines raise_gnuplot_console and
    term->quit_window. This would need the new API for interactive terminals.


If somebody wants to improve windows changes in some X11 combinations (as I 
did for KDE, for example), he can contribute it to the appropriate place of 
code, independently of the above ways.

---
PM

Re: Bind <space> to builtin_raise in mouse.c

[<tim...@en...>]

> On Wednesday 26 April 2006 02:24 pm, Timoth=E9e Lecomte wrote:
>> > Anyhow gnuplot already allows you to specify a window title,
>> > so all that's wanting is a way to change the prompt.
>> > 	myname =3D "Foo"
>> > 	set term x11 title myname
>> > 	set prompt myname."> "
>> >
>> >> Many programs I know are able to recognize if an instance is alread=
y
>> >> running.
>> >
>> > Probably safer to let the application do the naming.
>> > Pure numbers are not the most informative identifiers.
>>
>> Do you mean : "Probably safer to let the _user_ do the naming" ?
>
> Well no, I meant the application.   My thought
> was that if you ran applications A, B, and C simultaneously
> (or three instances A, B, and C of a single application like
> Octave), then the piped output from these apps to three separate
> gnuplot instances would respectively start with a line
> "myname =3D 'A'",  "myname =3D 'B',  or "myname =3D 'C'".
> I suppose in this case you could say the application *is* the user.

Ok, I get your point. Well, everything is already in place for such a
behaviour.

Timoth=E9e

Re: Bind <space> to builtin_raise in mouse.c

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

On Wednesday 26 April 2006 02:24 pm, Timoth=E9e Lecomte wrote:
> > Anyhow gnuplot already allows you to specify a window title,
> > so all that's wanting is a way to change the prompt.
> > 	myname =3D "Foo"
> > 	set term x11 title myname
> > 	set prompt myname."> "
> >
> >> Many programs I know are able to recognize if an instance is already
> >> running.
> >
> > Probably safer to let the application do the naming.
> > Pure numbers are not the most informative identifiers.
>=20
> Do you mean : "Probably safer to let the _user_ do the naming" ?

Well no, I meant the application.   My thought
was that if you ran applications A, B, and C simultaneously
(or three instances A, B, and C of a single application like
Octave), then the piped output from these apps to three separate
gnuplot instances would respectively start with a line
"myname =3D 'A'",  "myname =3D 'B',  or "myname =3D 'C'".
I suppose in this case you could say the application *is* the user.

But I still don't have a good picture of the environment Petr is
working in that pops up all these disconnected windows, so perhaps
this wouldn't help any.=20

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bind <space> to builtin_raise in mouse.c

[<tim...@en...>]

> Anyhow gnuplot already allows you to specify a window title,
> so all that's wanting is a way to change the prompt.
> 	myname = "Foo"
> 	set term x11 title myname
> 	set prompt myname."> "
>
>> Many programs I know are able to recognize if an instance is already
>> running.
>
> Probably safer to let the application do the naming.
> Pure numbers are not the most informative identifiers.

Do you mean : "Probably safer to let the _user_ do the naming" ?

Re: Bind <space> to builtin_raise in mouse.c

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

On Wednesday 26 April 2006 01:15 pm, you wrote:
> 
> For example, the first instance of gnuplot would have the prompt
> "gnuplot>", and the window would be entitled "gnuplot", a second instance
> could have the prompt "gnuplot(2)>", and the window would be entitled
> "gnuplot(2)", etc.

That's a window-naming policy, and can already be done in KDE.
In fact I think it defaults to that.  For instance, when I open new
terminal windows they receive banner titles "Xterm <2>" "Xterm <3>"
and so on.

Anyhow gnuplot already allows you to specify a window title,
so all that's wanting is a way to change the prompt. 
	myname = "Foo"
	set term x11 title myname
	set prompt myname."> "
 
> Many programs I know are able to recognize if an instance is already
> running. 

Probably safer to let the application do the naming.
Pure numbers are not the most informative identifiers.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bind <space> to builtin_raise in mouse.c

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

Timoth=E9e Lecomte wrote:

> Hmm... It may not be what you wanted to say, but we can take that as an
> extra argument to remove the feature, i.e .there's another obstacle tha=
t
> makes it unreliable : the focus-stealing-prevention mechanism that is
> activated by default on several desktops.

Just saying the current implementation isn't super useful.  But a focus-s=
tealing-prevention is also problematic.

> That makes me think of a different approach to associate a console wind=
ow
> and a plot window : make the prompt and the window title change
> accordingly.
>=20
> Advantage : both of them are really managed by gnuplot, so that is
> reliable and cross-platform.
> Drawback : not as straightforward,
>=20
> For example, the first instance of gnuplot would have the prompt
> "gnuplot>", and the window would be entitled "gnuplot", a second instan=
ce
> could have the prompt "gnuplot(2)>", and the window would be entitled
> "gnuplot(2)", etc.
>=20
> Many programs I know are able to recognize if an instance is already
> running. So I guess we could be able to do it too, and to use this
> information to change the prompt.
>=20
> Is that satisfying ?

Right now in Gnome I see that if I have two versions of gnuplot and gnupl=
ot_x11, the windows created for the two different gnuplot_x11 are combine=
d in the same menu group; so yeah that could be useful.  (Not something I=
'm pining for, though.)

Dan