octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI Qt figure window


From: Michael Goffioul
Subject: Re: GUI Qt figure window
Date: Tue, 21 Aug 2012 22:01:28 +0100

On Tue, Aug 21, 2012 at 8:04 PM, Daniel J Sebald <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>> 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

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. I suppose the data format exchanged on that socket is gnuplot-specific. This design is specifically what we're trying to avoid because of efficiency reasons. Note also that the gnuplot implementation is based on "fork", so it's not portable to native Windows.

What I'm referring to, XEmbed, is the X-specific protocol to do cross-application widget embedding. This protocol is mainly about handling keyboard focus between the embedder and the embedded applications.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]