Qt World Summit: Submit your Presentation

Start / Kill Qt-GUI - [resolved]

  • There is requirement of writing a Qt application on a MIPS based platform.

    But there are lots of constraints. The constraints included freeing up of few resources (QGFX Plugin, GPU Memory etc) when there is signal and re-using it later. But the application cannot be killed as its handling lots of other requests and running other things.

    Basically the GUI needs to be killed and free all the resources; later when when required restart again

    One of the way which has been tried is :

    main() -> create a New-Thread

    In the New-Thread,

    m_wnd = new myMainWindow();

    When ever there is a kill command, it comes out of the event loop, and wait for the signal from other threads. Once other threads does the required changes, it will get the signal and will create a new window and goes into the event loop.

    In the main(), there are also few other threads created, which control other devices etc and signal the start and stop for the Qt-GUI.

    The above seems to work but I am not sure if this is the right design. Does it create any problem?

    Can any one suggest any better way?

  • The UI has to be in the main thread, so your approach will not work.

    You are free to delete/create top level widgets like the main window at anytime, so why don't you just delete the UI when no longer needed? By default QApplication will quit when the last window closes, but that can be changed via the "quitOnLastWindowClosed property":http://qt-project.org/doc/qt-4.8/qapplication.html#quitOnLastWindowClosed-prop .

  • Wouldn't it make much more sense to create two applications instead? One application could be your core that actually does the work and responds to outside events, while the GUI could be a separate application that simply connects to this core and that can be killed at time you want.

  • Thanks @Tobias, I think i am looking for some thing like this.
    Basically I want to create and destroy the GUI only .

    @Andre - Yes that would have been my choice also. But there are lots of constraints and also, i am not having the liberty to change the existing modules :(.

    EDIT: @Tobias: I was able to get it working with what you have suggested :)

Log in to reply