Re: gnuplot & multiplot

[Michael Goffioul]

On Thu, Oct 17, 2013 at 11:37 PM, Daniel J Sebald <address@hidden> wrote:

On 10/17/2013 09:36 AM, Rik wrote:

On 10/16/2013 10:44 PM, Daniel J Sebald wrote:

On 10/16/2013 03:02 PM, Rik wrote:

On 10/16/2013 10:00 AM, octave-maintainers-request@octave.org wrote:

6) Multiplot mode doesn't seem to behave as well as it once did.  For
example, after running freqz() and closing the figure and opening a new
figure with "figure(#)", I see:

figure(3)

multiplot>
                  ^
              line 0: function to plot expected

The issues you presented as numbers 2, 3, 4, 8 are all GUI-related
additions which could be nice to have, but shouldn't gate the release.
When you have time I would add them to the Bug Tracker.  Issue 1 is already
a bug report, and Issue 5 is already customizable, and Issue 7 has the
required Matlab compatible behavior.  The final issue, #6, might be a
problem if it is a regression from what was working in 3.6.4.  Do you have
a clear sequence which generates this error?

Not a clear sequence.  But I've noticed another behavior that might be
the source of the problem.  (Sorry I can't look into this more closely.)
  It seems that clicking the "close window" button in the upper right (or
left depending on system) corner doesn't actually "close(5)", for
example.  The window is closed, but if one plots to the same figure
number, it remembers it was in multiplot mode.  Basically, Octave's
instance of the figure isn't being closed.  I suppose we haven't really
dealt with such a thing in the past.  I wonder if we can now with the Qt
terminal.  I'll ask around later in the week.

Dan

10/17/13

Dan,

I think this is a known problem.  When the window on the gnuplot side is
closed it doesn't send an indication back to Octave so it believes the
window is still available.  This is another one of the difficult-to-solve
issues pushing us towards our own solution with OpenGL.

Actually, there may be a solution to this, but it would take a slight bit extra programming on the application side.  Before Qt gnuplot terminal, I added a feature to the x11 terminal whereby an X window ID can be passed into the gnuplot command "set term x11".  The concept is that the application creates a phantom X window that it wants gnuplot to plot to.  In that scenario, the X gnuplot driver will not create a X term, but just plot into the external window.  Thus, if the X window is closed, the application should be able to detect that.  I remember writing some kind of demo using gtk or one of those graphical interfaces that showed promise for a short while.

It appears that Qt terminal has a similar sort of thing:

 Syntax:
         set term qt {<n>}
                     {size <width>,<height>}
                     {{no}enhanced}
                     {font <font>}
                     {title "title"}
                     {{no}persist}
                     {{no}raise}
                     {{no}ctrl}
                     {close}
                     {widget <id>}

So, if Octave can recognize that gnuplot is using qt terminal, it would first create an empty Qt window and pass the ID (if it can be discovered) to gnuplot.  Octave would connect the close signal of that Qt window to a slot that does "close(5)", for example... if there were a background command queue (which I wrote in the patch tracker somewhere).

In the documentation for the Qt Widget is this member function:

http://qt-project.org/doc/qt-4.8/qwidget.html#effectiveWinId

typedef WId

Platform dependent window identifier.  I'll ask the list.

Be careful that the effective WinId is shared by multiple QWidget within the same window. So you may end up with gnuplot drawing over other widgets you might have in the window. You need to enable the native windows flag on the widget if you want it to have its own X11 ID. Also I'm wondering how portable to other platforms your suggestion is.

Michael.