Re: GUI Qt figure window

[Daniel J Sebald]

On 08/21/2012 12:00 PM, Jacob Dawid wrote:
> Dan,
>
>         The X11 window ID was an example.  Does Qt have an analogous
>         widget ID that is something different than X11 window ID?
>
>
>     Dan
>
>
> Difficult to answer, I think it's a wrong question :) X11 is a window
> system, Qt is a C++ application framework. Qt is object-oriented, so
> every unique QWidget object has a memory address (which identifies the
> object), so I would say that is what the ID is. In fact, the memory
> address is used to embed QWidgets in other QWidgets. I guess a Qt
> application is not primarily intended to be "swallowed" by another
> application or to expose its internals.

Checking the code, it uses

qt_socket.connectToServer

function to connect with another Qt socket.  The input to 
connectToServer is the gnuplot Qt terminal option ascii string converted 
to a QString.  This concept appears to have been added in Qt 4:

http://doc.qt.nokia.com/4.7-snapshot/qlocalsocket.html

> Is there a reason you do not want to use OpenGL?

I think you are referring to long term vision for Octave plotting, the 
discussion of which I haven't followed closely.  I'm not opposed to 
OpenGL, I just don't know that much about it other than at a conceptual 
level.  I'm just pointing out that a couple small tweaks could yield 
figures that sort of match the GUI-O using the current system.


>  I never asked this
> question before, but why doesn't gnuplot provide a C++ API that we can
> link against?

It has to do with the history of the gnuplot project and the fact it is 
rooted in a computer age before libraries for GUIs were a common thing 
and the fact that resources are very limited as far as programming base. 
 I don't think there is any opposition to a C++ API for gnuplot, but 
there isn't the programming base to do this.  That is, unless if what 
you are asking about is a simple C++ interface by which the common 
commands are issued, sort of like replacing the currently used pipe with 
some C++ interface, but that too may be a problem.

So some history:

gnuplot was originally written by two engineering students who needed a 
tool for plotting at a time when there really weren't many options.  It 
predates the era of GNU, etc. ("gnu" actually means "new", but that was 
already taken.)  The paradigm back then, because of limited memory and 
the inherent design of all software in the programming world, was to 
view plotting analogous to sending commands to a terminal.  Unix, for 
example, was developed with the concept of modularity in mind.  A bunch 
of small programs connected together in pipes, redirection, etc. as 
opposed to linking libraries into what become bigger applications and 
risk redundant uses of (at the time) valuable code space.  [Didn't we 
discuss at the coffee break for OctConf my claim that software will 
always fill memory space?]  This is why gnuplot has never stored data 
internally in the sense we now think of.  Rather it basically processes 
the data.  It was sort of born in an era where libraries weren't the 
paradigm (specialized libraries perhaps, but not GUI and OS libraries).

gnuplot has a terminal concept analogous to a dumb (or not-so-dumb) 
plotter.  So, the evolution has been a group of people who want to plot 
their data but they have limited programming time, so they concentrate 
on A) a terminal driver that works for the plotter or printer 10 feet 
from their desk, or B) some new feature for graphically presenting their 
data.  Both of these are no small task.  Given the ever evolving 
hardware/library world, there have been terminals for all sorts of 
computer plotters and basic graphics packages, some now extinct and/or 
failed.  It's both a benefit and curse, I suppose.

So, the one thing that gnuplot as a C++ API would need, i.e., a must 
have, is some way of storing all plot data internally so that it can be 
recalled for plot manipulations, refreshing screens, etc.  (For example, 
if the plot scale is changed from linear to log, the data must be resent 
because it has been processed and can't be recreated if the logarithm 
has been taken.)  Storing data hasn't been a top priority in gnuplot 
project.  I've written a patch for gnuplot along those lines, but it 
didn't fly for several reasons.  That approach is breaking the paradigm 
and there is some politics with that, and it probably wouldn't be 
perfect and the feeling on that discussion list is that if such a thing 
were to be done it should be done right, which brings us back to the 
limited programming resources.

The way John (Eaton) has solved this is to create new instances of 
gnuplot for each figure.  It may not be the best approach, but his 
thinking was that gnuplot is small so it should do while he concentrates 
on other things.  Getting back to what I said about the era in which 
gnuplot was born, gnuplot is small because the paradigm back then was 
lean and modular.  On my current computer, it takes a couple minutes to 
build gnuplot.  Octave takes over an hour to build.  For Octave to be 
this entity that holds a lot of data, then linked with a plotting engine 
that holds a lot of data would be redundant and big.  In other words, 
the current setup isn't the best, but at the same time it's not so bad, 
at least conceptually.

I should also point out that there is a huge reluctance by gnuplot 
developers to change things because developers recognize that takes a 
lot of programming effort to maintain and there is a user base to 
consider.  The historic terminals are supported indefinitely for the 
most part, old syntax (however crude or clumsy) is retained.  The 
feeling is that keeping gnuplot static promotes its use.  Too many 
changes might appease some group at the expense of another group.  So 
this means the following: Writing a new terminal driver--few political 
debates.  Adding a new feature--debate but from a programming 
syntactical standpoint it's a go.  Changing core concepts like memory 
retention, existing interface, etc.--make sure both flanks are covered.

Feel free to join the gnuplot discussion group and propose a C++ API. 
Like I say, chances aren't bad that such a thing could get the OK from 
ardent developers (new features typically require a patch from the 
proposer), but the question is whether C++ API helps Octave or other 
programs that much.

Dan