Menu
▾
▴
gnuplot-beta
|
From: L. <tim...@en...> - 2005-06-12 09:45:48
|
Hi ! I am a pleased user of gnuplot. I often use it, standalone or through Octave, to study physic datas. In order to make it more user friendly (but it already is, with a little practice), I thought to write a terminal to wxwidgets (hhtp://www.wxwidgets.org), a gui toolkit. It would have the advantage of being cross-platform. Moreover, I think it would be really easy to copy all the features of current x11 or windows terminals, and then to add toolbars and other useful buttons ou dialogs. In particular, it would be something interesting to make 3rd-party software (like Octave, or Maxima) reach a higher level of usablility. I have looked for such projects, but found none. There's a couple of projects which aim at buildung a complete gui for gnuplot, but they appear dead. And none of them was using a new terminal, as far as I guess. I am not afraid at all by such a project, and I have began to learn how to use wxwidgets. But I have a question : wxwidgets is a library for C++, and gnuplot is written in C. So, can I write a terminal for gnuplot in C++ ? Can gnuplot be compiled entirely with a C++ compiler (g++ in my case) ? Does somebody know a way to do it (I've not tried) ? Do you think the whole idea of writing a wxwidgets terminal is good ? I would be pleased to get your opinions. Timothée Lecomte French student, at the ENS, Paris (http://www.ens.fr) |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-06-12 10:25:19
|
Timoth=C3=A9e Lecomte wrote: > In order to make it more user friendly (but it already is, with a littl= e > practice), I thought to write a terminal to wxwidgets=20 > (hhtp://www.wxwidgets.org), a gui toolkit.=20 Somebody else had the same idea recently. But there's a significant=20 obstacle, esp. in the way you plan on doing it: licensing. wxwidgets is = GPLed, gnuplot's license is deemed not sufficiently compatible with GPL=20 to allow linking GPLed libraries into it. At least not in distributed=20 binaries, by the interpretation of the legalese as seen by the Debian tea= m. > be something interesting to make 3rd-party software (like Octave, > or Maxima) reach a higher level of usablility. I don't think that adding a GUI to gnuplot will make it any more easy to = use by external programs, who want to control gnuplot themselves, rather = than let the user do it. They already have enough control over gnuplot=20 as it is --- the only major exception being that they can't swallow the=20 gnuplot graph window into their own GUI yet, and that the Windows=20 version offers no access to its command line output channel. > But I have a question : wxwidgets is a library for C++, and gnuplot > is written in C. So, can I write a terminal for gnuplot in C++ ? Not really. At least the actual terminal API functions (i.e. those that = go into the termentry struct) have to be C functions, i.e. they have to=20 be qualified 'extern "C"', in C++ terms. > Can gnuplot be compiled entirely with a C++ compiler (g++ in my > case) ? Does somebody know a way to do it (I've not tried) ? You certainly shouldn't have to do that, and no, it wouldn't work. gnuplot is written in C. Trying to compile genuine, non-trivial C code=20 with a C++ compiler is generally impossible, dangerous, or both. It=20 would cause a boatload of pain in the lower back to translate gnuplot to = "C/C++", the strict common subset of both languages. [In the interest of more fluent discussion, please subscribe to=20 gnuplot-beta if you're going to continue posting to it.] |
|
From: <tim...@en...> - 2005-06-12 11:15:37
|
Hans-Bernhard Broeker wrote: > Timoth=C3=A9e Lecomte wrote: > >> In order to make it more user friendly (but it already is, with a litt= le >> practice), I thought to write a terminal to wxwidgets=20 >> (hhtp://www.wxwidgets.org), a gui toolkit.=20 > > > Somebody else had the same idea recently. But there's a significant=20 > obstacle, esp. in the way you plan on doing it: licensing. wxwidgets=20 > is GPLed, gnuplot's license is deemed not sufficiently compatible with=20 > GPL to allow linking GPLed libraries into it. At least not in=20 > distributed binaries, by the interpretation of the legalese as seen by=20 > the Debian team. Oh no ! I was aware of the non-GPL licence of gnuplot, but I have not=20 taken it into account when thinking of a wxwidgets terminal. So is there=20 any hope to use one of these wonderful gui toolkits like wxwidgets, gtk,=20 qt, etc. as terminals ? > >> be something interesting to make 3rd-party software (like Octave, >> or Maxima) reach a higher level of usablility. > > > I don't think that adding a GUI to gnuplot will make it any more easy=20 > to use by external programs, who want to control gnuplot themselves,=20 > rather than let the user do it. They already have enough control over=20 > gnuplot as it is --- the only major exception being that they can't=20 > swallow the gnuplot graph window into their own GUI yet, and that the=20 > Windows version offers no access to its command line output channel. You're right when you say that external programs want first to control=20 gnuplot themselves. However, I think the user would be pleased to have a=20 little more interaction with the terminal without having to send a new=20 plot command with modified options. That's precisely what you've added=20 with the mouse support. I was dreaming of a terminal with other options... In fact, I must admit that I had used gnuplot for months before=20 discovering the mouse support (in octave, it's not activated by default,=20 as explained in the gnuplot faq) ! That's why I want to design a more=20 intuitive terminal, regarding this point (toolbar, etc). When reading the terminal readme and the corresponding API, I have been=20 impressed by its simplicity. As far as I understand, gnuplot owns an=20 entire abstract layer which give really simple drawing commands. It is=20 really ideal to use it with a gui library like wxwidgets. > >> But I have a question : wxwidgets is a library for C++, and gnuplot >> is written in C. So, can I write a terminal for gnuplot in C++ ? > > > Not really. At least the actual terminal API functions (i.e. those=20 > that go into the termentry struct) have to be C functions, i.e. they=20 > have to be qualified 'extern "C"', in C++ terms. It's precisely what I've learned on other pages. So the mix between C=20 and C++ should not be a problem, provided the extern "C" magic words. > Trying to compile genuine, non-trivial C code with a C++ compiler is=20 > generally impossible, dangerous, or both. It would cause a boatload=20 > of pain in the lower back to translate gnuplot to "C/C++", the strict=20 > common subset of both languages. Ok, I understand. I hope we could continue this discussion to find a solution, especially=20 about the license problem. Timoth=C3=A9e Lecomte |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-06-12 11:53:01
|
Timoth=C3=A9e Lecomte wrote: > Oh no ! I was aware of the non-GPL licence of gnuplot, but I have not=20 > taken it into account when thinking of a wxwidgets terminal. So is ther= e=20 > any hope to use one of these wonderful gui toolkits like wxwidgets, gtk= ,=20 > qt, etc. as terminals? I'm afraid not without violating either gnuplot's license or the GPL, as = they both currently are. > plot command with modified options. That's precisely what you've added = > with the mouse support. I was dreaming of a terminal with other options= =2E.. Even the current mouse support is running into considerable problems=20 with remote-controlled gnuplot sessions. That's why it's kept disabled=20 by default in such cases. Having a single instance of gnuplot try to=20 serve two independently acting masters (octave and a human being, e.g.)=20 simultaneously has to cause trouble. |
|
From: V. <gae...@no...> - 2005-06-12 12:20:08
|
On Sun, Jun 12, 2005 at 01:53:42PM +0200, Hans-Bernhard Broeker wrote:
> Even the current mouse support is running into considerable problems=20
> with remote-controlled gnuplot sessions. That's why it's kept disabled=
=20
> by default in such cases. Having a single instance of gnuplot try to=20
> serve two independently acting masters (octave and a human being, e.g.)=
=20
> simultaneously has to cause trouble.
That's why a dedicated terminal would be very usefull. However have a
cross platform interactive terminal probably means either using a
toolkit, which does not seem compatible with gnuplot's current licence (a
pity) or using a dedicated terminal for the platform, wich basically
means reusing the current existing interactive terminals.
=20
Maybe what we need is more a API for interactive terminals ?
By the way, I think there should be an alias for the default platform
dependent interactive terminal. Say I want to code a script (Octave for
instance, but it could as well be Gnuplot) that work under various
platforms and switches terminals. If I want to switch back to the
platform specific interactive terminal, how do I call it ?
--
Ga=EBl
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-06-12 12:25:47
|
Ga=EBl Varoquaux wrote: > By the way, I think there should be an alias for the default platfo= rm > dependent interactive terminal. Say I want to code a script (Octave for= > instance, but it could as well be Gnuplot) that work under various > platforms and switches terminals. If I want to switch back to the > platform specific interactive terminal, how do I call it ? "poll", as in set term poll You'll want to look up the docs to see what I mean ;-) |
|
From: <tim...@en...> - 2005-06-12 17:10:48
|
Hans-Bernhard Broeker wrote:
> Timoth=C3=A9e Lecomte wrote:
>
>> Oh no ! I was aware of the non-GPL licence of gnuplot, but I have not=20
>> taken it into account when thinking of a wxwidgets terminal. So is=20
>> there any hope to use one of these wonderful gui toolkits like=20
>> wxwidgets, gtk, qt, etc. as terminals?
>
>
> I'm afraid not without violating either gnuplot's license or the GPL,=20
> as they both currently are.
>
A precision : wxwidgets is LGPL, not GPL. I'm not completely sure, but=20
it seems that it solves the license problem. Can you confirm by reading=20
the LGPL ? Here follows the piece of the license which is important :
*"6.* As an exception to the Sections above, you may also combine or=20
link a "work that uses the Library" [ A program that contains no=20
derivative of any portion of the Library, but is designed to work with=20
the Library by being compiled or linked with it ] with the Library to=20
produce a work containing portions of the Library, and distribute that=20
work under terms of your choice, provided that the terms permit=20
modification of the work for the customer's own use and reverse=20
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the=20
Library is used in it and that the Library and its use are covered by=20
this License. You must supply a copy of this License. If the work during=20
execution displays copyright notices, you must include the copyright=20
notice for the Library among them, as well as a reference directing the=20
user to the copy of this License. Also, you must do one of these things:
* *a)* Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood that
the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
* *b)* Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
* *c)* Accompany the work with a written offer, valid for at least
three years, to give the same user the materials specified in
Subsection 6a, above, for a charge no more than the cost of
performing this distribution.
* *d)* If distribution of the work is made by offering access to
copy from a designated place, offer equivalent access to copy the
above specified materials from the same place.
* *e)* Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the Library"=20
must include any data and utility programs needed for reproducing the=20
executable from it. However, as a special exception, the materials to be=20
distributed need not include anything that is normally distributed (in=20
either source or binary form) with the major components (compiler,=20
kernel, and so on) of the operating system on which the executable runs,=20
unless that component itself accompanies the executable.
It may happen that this requirement contradicts the license restrictions=20
of other proprietary libraries that do not normally accompany the=20
operating system. Such a contradiction means you cannot use both them=20
and the Library together in an executable that you distribute."
So it is possible to write a terminal which uses wxwidgets, as gnuplot=20
is open-source (although it's not gpl). We just have to notice in the=20
code that this LGPL library is used.
What do you think of it ?
Timoth=C3=A9e Lecomte
|
|
From: Petr M. <mi...@ph...> - 2005-06-13 07:35:33
|
> Somebody else had the same idea recently. But there's a significant > obstacle, esp. in the way you plan on doing it: licensing. wxwidgets is > GPLed, gnuplot's license is deemed not sufficiently compatible with GPL > to allow linking GPLed libraries into it. At least not in distributed > binaries, by the interpretation of the legalese as seen by the Debian team. The attractiveness of the wx widget is that is NOT GPL, thus it can be used in open source as well as for commercial applications. > Not really. At least the actual terminal API functions (i.e. those that The question is whether the terminal should be managed via pipes (as X11 or OS/2), i.e. an independent executable, or to be linked with gnuplot itself (like Windows). --- PM |
