Many Processes one GUI
-
QtWebKit is a library, not an external program. I don't know whether QX11Embed* is a solution for lynardo either: It is XWindow specific and thus does not work on windows, Mac (at least not without running an X server) or Symbian.
-
only for the chromium comparsion i saw webkit. Repplace for "webkit based widget built as a external binary, who recive a url as inicialization parameter".
I don't know if the project of lyardo is a browser. May be a comercial system, a finantial manager, etc.
And yes, QX11Embed only work on X11. Mac can run X11 and Cygwin maybe too. If i had a windows i make a test of xembed uder cygwin.
And IPC is also a solution, but lyardo arks for another way.
-
Well an X11 server is not the right thing for me, because I had to use windows.
Chochise: No it isn´t a browser, I want to make a Programm with amy really complicatet mathematic and then to diasplay the result as a graphik.So i tried QThread, but I think then the Programm is not Stable enough, because I´m a person, who is clicking on options button and so on, while programms are "thinking". And to let a process render which has no GUI, then Shared Memory, and display it on screen, would be to big for my RAM.
Well in this way if nobody has more Ideas, I hav to make it like that:
One Class in the mainprocess, handles the others, and sends commands as string to them like "hide" and so on. Then the Process has to Implement and to follow the advices. I really thinkt that that method is to slow, and to complicated, tht there must be another way. But it seems that it isn´t.
Thanks to all for their helpful answers
-
If you are concerned about your "workers" could crash you should go for separate processes, each running as a separate executable application and connect them with some kind of IPC (maybe using the stdin and stdout channels).
If your workers are unlikely to crash (and if you don't need to detach the GUI from the workers) then it's better to use "QThread":http://doc.trolltech.com/4.7/qthread.html, these can communicate with your GUI thread directly using signals and slots. This works in both directions, so if you are changing your settings in the GUI you can tell your workers immediately.
BTW:
What should happen if you wildly click on some options buttons?
Why should that crash your application?
And how would you recover if you had split the GUI and your workers in different applications?
Which of both starts the others (does the GUI start the workers or the other way round)?
You would have to implement some watcher (catching a "QProcess":http://doc.trolltech.com/4.7/qprocess.html's "finished()":http://doc.trolltech.com/4.7/qprocess.html#finished signal and examinating the exitCode) in that case. -
What you can do: create a GUI as one process and a rendering Executable (or calculation exe) as second process. Put all parameters e.g. in an XML file and create a QProcess to start the math app with the xml file as cmd parameter. So the calculation takes part in a seperate process. When it finishes, it stores the result again as XML (or whatever format you like) and the GUI can read the results and display them.
Simple solution with more than one process..... -
Why would using shared memory be any bigger memory overhead than what you propose?
-
Of course you´re right QThread is more useful and practicabler than IPC, I was just really interested in that, so my application now had many Threads and schows a waiting symbol at the Solutions view.
Thanks for your great help, it was really interesting, but I´ve seen not all what you think about is easiely practicable at the moment. But maybe there is a module in Qt in the future.
-
There already is "QtConcurrent":http://doc.qt.nokia.com/4.7/qtconcurrent.html to help with multi threaded programming. It among other things manages a pool of threads, assigning tasks to them when they are idle.
-
You might also want to have a look at the Qt Service Framework:http://doc.qt.nokia.com/qtmobility-1.1.0/service-frameworks.html
In 1.1, it supports Out of Process services, both in QtDBUS or QLocalSocket.