| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 2 | |
Hello, I'm writing an application, which has allready it's own main event loop (calling different libraries etc). If I want to use QT now just as a widget library, how do i have to setup the QT library, for being capable to be called from my own main own loop? The only thing I've figured out so far is the possibility of calling eventLoop.processEvents(). Actually this is quite equal to the code in app.exec(), if one doesn't care about threading and some *special* stuff. Of course it would be possible to put my other events into the QT EventLoop, but what if the QT EventLoop hasn't sufficiant flexibility? So my question, 1. is there a clean and supported way to call the eventLoop.processEvents() function call from my own main event loop 2. if not, what is a clean oop way, of hooking my own main event loop into QT kind regards, Anton Wöllert -- [ signature omitted ]
Anton Wöllert wrote: >Hello, > >I'm writing an application, which has allready it's own main event loop >(calling different libraries etc). If I want to use QT now just as a >widget library, how do i have to setup the QT library, for being capable >to be called from my own main own loop? I wouldn't recommend doing that. I recommend using the Qt event loop instead. >The only thing I've figured out so far is the possibility of calling >eventLoop.processEvents(). Actually this is quite equal to the code in >app.exec(), if one doesn't care about threading and some *special* > stuff. Of course it would be possible to put my other events into the > QT EventLoop, but what if the QT EventLoop hasn't sufficiant > flexibility? Then you talk the mailing list or to Trolltech Support and we'll figure out if what you're asking for isn't supported or, if it is, how to do it. >So my question, >1. is there a clean and supported way to call the >eventLoop.processEvents() function call from my own main event loop You tell us. Just call it. Obviously, you need to figure out on your own *when* to do it. Qt will not tell you its list of file descriptors to be watched or its next timer timeout. >2. if not, what is a clean oop way, of hooking my own main event loop >into QT Yes. Using QTimers for timeouts, QSocketNotifier for file-descriptor watches and QEvents for message-passing. Those are the lowest-level event-loop hooks. Or using higher-end functionality where available. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira schrieb: > Anton Wöllert wrote: > >> So my question, >> 1. is there a clean and supported way to call the >> eventLoop.processEvents() function call from my own main event loop >> > > You tell us. Just call it. Obviously, you need to figure out on your own > *when* to do it. Qt will not tell you its list of file descriptors to be > watched or its next timer timeout. > > >> 2. if not, what is a clean oop way, of hooking my own main event loop >> into QT >> > > Yes. Using QTimers for timeouts, QSocketNotifier for file-descriptor > watches and QEvents for message-passing. Those are the lowest-level > event-loop hooks. > > Or using higher-end functionality where available. > Well that's sad. Because imagine there are two libraries depending on their *own* event handling like QT does, then there will be no possibility to plug them together, right? kind regards, Anton Wöllert -- [ signature omitted ]
Just try to call QApplication::instance(), if it return NULL pointer then start your own QApplication, and there you go! You've got Qt event loop. Should work but not sure about it... On Nov 10, 2007, at 6:11 PM, Anton Wöllert wrote: > Thiago Macieira schrieb: >> Anton Wöllert wrote: >> >>> So my question, >>> 1. is there a clean and supported way to call the >>> eventLoop.processEvents() function call from my own main event loop >>> >> >> You tell us. Just call it. Obviously, you need to figure out on >> your own *when* to do it. Qt will not tell you its list of file >> descriptors to be watched or its next timer timeout. >> >> >>> 2. if not, what is a clean oop way, of hooking my own main event >>> loop >>> into QT >>> >> >> Yes. Using QTimers for timeouts, QSocketNotifier for file- >> descriptor watches and QEvents for message-passing. Those are the >> lowest-level event-loop hooks. >> >> Or using higher-end functionality where available. >> > Well that's sad. > Because imagine there are two libraries depending on their *own* > event handling like QT does, then there will be no possibility to > plug them together, right? > > kind regards, > Anton Wöllert > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx > with "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > -- [ signature omitted ]
Don't write directly to me, write to mailing list. QApplication::instance() returns current instance of QApplication (in case, there is another plugin creating QApplication). If it is NULL, then there is no QApplication. You create new QApplication and call it's exec() method to start Qt event loop. On Nov 10, 2007, at 7:19 PM, Anton Wöllert wrote: > Kamil Klimek wrote: >> Just try to call QApplication::instance(), if it return NULL >> pointer then start your own QApplication, and there you go! You've >> got Qt event loop. Should work but not sure about it... > > Hi, could you be please a bit more precise. I can't follow you. > QApplication::instance() returns a pointer to private data of a > QApplication object, right? > So what should I do with this pointer then? > > > kind regards, > Anton Wöllert -- [ signature omitted ]
Anton Wöllert wrote: >Because imagine there are two libraries depending on their *own* event >handling like QT does, then there will be no possibility to plug them >together, right? Each in its own thread might work. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Nov 10, 2007 12:11 PM, Anton Wöllert <aw.devel@xxxxxxxxx> wrote:
> >> 2. if not, what is a clean oop way, of hooking my own main event loop
> >> into QT
> >>
> >
> > Yes. Using QTimers for timeouts, QSocketNotifier for file-descriptor
> > watches and QEvents for message-passing. Those are the lowest-level
> > event-loop hooks.
> >
> > Or using higher-end functionality where available.
> >
> Well that's sad.
> Because imagine there are two libraries depending on their *own* event
> handling like QT does, then there will be no possibility to plug them
> together, right?
>
I have hooked two libraries together (Qt and a Jabber networking library),
each of which had its own event loops. I was lucky in that the Jabber
library was just sitting and waiting for data on a network socket, and it
had a way to get the file handle for that socket. Qt has a way to have a
file descriptor watched as part of its own event loop (see QSocketNotifier),
so whenever there was data on the socket, the Qt event loop would wake up
and notify my code, and my code would tell the Jabber library to process the
data.
If you want to plug two event loops together, you have two options:
1) Sit in a loop that looks like
while (true) {
eventLoop1.processOnlyAvailableEvents();
eventLoop2.processOnlyAvailableEvents();
}
But this is a busy-wait loop, and will use 100% of the available CPU.
2) The event loops probably call select() or poll() (these are the functions
on UNIX, I don't know what the Windows equivalent is) and wait for file
descriptors of some type to become available. If you can get these file
descriptors you can have a master event loop that waits on all of the file
descriptors. If one of your libraries is Qt, than Qt provides
QSocketNotifier to make this easy.
In general, you should have an irrefutable need for not using Qt's event
loop before trying to work it in to another event loop. If your reason is,
"it might not be flexible enough", I would find out what you might need to
do, and then find out how to do it with Qt.
Tom
Anton Wöllert wrote: > Well that's sad. > Because imagine there are two libraries depending on their *own* event > handling like QT does, then there will be no possibility to plug them > together, right? I think you should be looking at the QAbstractEventDispatcher class: http://doc.trolltech.com/4.3/qabstracteventdispatcher.html Although the documentation incorrectly mentions a Motif Extension that is actually a Qt Solution, you might find it useful to look at the QEventDispatcher implementations in Qt itself. Good luck! David -- [ signature omitted ]