Re: GUI Qt figure window

[Daniel J Sebald]

On 08/21/2012 04:01 PM, Michael Goffioul wrote:
> On Tue, Aug 21, 2012 at 8:04 PM, Daniel J Sebald <address@hidden
> <mailto:address@hidden>> wrote:
>
>     On 08/21/2012 12:17 PM, Michael Goffioul wrote:
>
>         On Tue, Aug 21, 2012 at 6:00 PM, Jacob Dawid
>         <address@hidden <mailto:address@hidden>
>         <mailto:address@hidden <mailto:address@hidden>>__>
>         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.
>
>
>         Embedding one application's widget into another application's
>         container
>         is done through the XEmbed protocol under X11. Qt provides
>         container and
>         widget classes implementing the XEmbed protocol (QX11EmbedWidget and
>         QX11EmbedContainer). This, however, is a X11-only solution (though
>         equivalent exists under Windows, I don't know about OS X).
>
>         Michael.
>
>
>     I'm not real knowledgeable on Qt, but perhaps what you are saying is
>     the original communication protocol.  The method gnuplot Qt terminal
>     is using is (repeat from longer post):
>
>     qt_socket.connectToServer
>
>
>     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
>     <http://doc.qt.nokia.com/4.7-snapshot/qlocalsocket.html>
>
>     As I say, this is outside my current understanding of Qt.  If there
>     is a member function to get a name from a socket created exterior to
>     another application that uses Qt, perhaps that is enough.  But it
>     could be an easier-said-than-done sort of thing.
>
>
> We're not talking about the same thing. What you to refer above is the
> internal mechanism used by gnuplot to communicate with the Qt terminal.
> After a quick look through gnuplot code, it appears it uses a Qt-based
> separate application to handle Qt plotting and the master (gnuplot)
> communicates with the slave (Qt) through a socket.

Correct.


>  I suppose the data
> format exchanged on that socket is gnuplot-specific.

Yes.


>  This design is
> specifically what we're trying to avoid because of efficiency reasons.

Data transfer efficiency?  Or memory space efficiency?  I've tested the 
gnuplot demos and they are fairly snappy.  None of the terminals 
approach that of X11, but Qt is pretty close.  For very large polygon 
drawing it is slow.  However, the reason it may be slower than X11 is 
that I suspect it is doing more in terms of antialiasing of fonts and lines.

So communications from gnuplot to the Qt terminal doesn't seem critical. 
 But we know the pipe from Octave to gnuplot can be slow for large data 
sets.


> Note also that the gnuplot implementation is based on "fork", so it's
> not portable to native Windows.

Well, I do see in the code that fork() is used when the technique that 
uses qt_socket.connectToServer(server) fails.  So that still leaves open 
the possibility of creating a container and passing it to gnuplot.  But 
I also see in gnuplot configuration there is a AC_FUNC_FORK system test 
when Qt terminal is used.  The author of the terminal might be able to 
modify the code for a solution in the case of just using Qt terminal in 
Windows.  AC_FUNC_FORK is described here:

http://www.delorie.com/gnu/docs/autoconf/autoconf_46.html

I think (but I'm not sure) the fork is used so that the external 
term/slave remains active (i.e., persist) when gnuplot exits.  That's 
only a little loss in the Windows case.  I don't have a Windows system 
to test gnuplot with.

Dan