Many Processes one GUI

  • Hi there!

    I want my application, to be in one GUI, but also to be splitted in some executables. How to do that?

    As I thought, that I can give some advice from the Main Part to the others, as well as positioning them or so on, over IPC. But I think, that there must be another way.

    Well if you don´t understand what I mean, look at Chrome, for each tab there is one Process, but it is only one GUI.

    Thanks for all answers

  • Thank you it helps me a lot

  • You're welcome

  • But the solution that Crome uses is really multiple processes not multiple threads. If you use threads, crashing in one of them could crash the whole app. That is something, that Crome solved by using multiple processes....

  • Moderators

    Cochise: Nope, QThread is a thread. QThreads allow for parallel execution of code within the same address space. This implies that once one thread crashes all the others are brought down as well... this is very different from e.g. Chrome where a tab crashing does not stop the UI.

    Lynardo will actually need QProcess(es) if he is after the robustness and not just the parallel execution of codepathes.

    Lyandro: Chrome has one process for the UI and several rendering processes (one for each tab). The tab contents is most likely shared between UI and rendering process using shared memory. There probably is some more comfortable Inter Pprocess Communication (IPC) mechanism between the two for small bandwidth stuff (like "open url x" or "I am done rendering"). This is just guesses based on what I read about chrome, so I might be off target here:-)

  • well. we can use a external program (webkit?) for render the pages and embed in main interface (in central widget?) with or

  • Moderators

    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.

  • X11 on Mac is ugly. One should avoid it whenever possible. I guess the same applies for Windows. I'd really go with some kind of IPC or RPC.

  • 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":, 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.

    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":'s "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.....

  • Moderators

    Why would using shared memory be any bigger memory overhead than what you propose?

  • wouldn't it, but easier :-)
    But I would normally also use QThread and do it i process....
    Why doing IPC if it is not really recommended...?

  • 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.

  • Moderators

    There already is "QtConcurrent": 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:
    In 1.1, it supports Out of Process services, both in QtDBUS or QLocalSocket.

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.