Sub-windows (Qdialogs) have "application" icons in DEBIAN task bar when re-opening them on program start-up



  • My program re-opens any opened sub-windows (QDialog) that was opened when the program was stopped. Under DEBIAN I get a funny behavior that is every sub-windows re-opened on program start-up has an "application" icon in the task bar of the desktop like it was a proper application. If I closed these sub-windows and then re-open them there is only one application icon and no more "application" icon for the sub-windows. This only haapens at start-up and the code that does that is :

    void MainWindow::showEvent( QShowEvent* event ) {
    QMainWindow::showEvent( event );
    if( settings.value(TheFirstQDialog_VISIBLE).toBool() )
    {
    dlgTheFirstQDialog()->init();
    dlgTheFirstQDialog()->setModal(false);
    dlgTheFirstQDialog()->show();
    }
    if( settings.value(TheSecongQDialog_VISIBLE).toBool() )
    {
    dlgTheSecongQDialog()->init();
    dlgTheSecongQDialog()->setModal(false);
    dlgTheSecongQDialog()->show();
    }
    }


  • Lifetime Qt Champion

    Hi,

    What does init do ?



  • @PALYGAP

    Are you sure you're setting the dialogs' parents to the main window when you create them? This could be happening if their parent is None.



  • @SGaist : The init fonctions reads some QSettings and restores the geometry of the each QDialog then initiates and set properties of Widgets belonging to the QDialog.

    @elveates : Yes, AFAIK. Here is the code :
    TheFirstQDialog::TheFirstQDialog(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::TheFirstQDialog),
    m_setup(false),
    m_initMode(false)
    {
    ui->setupUi(this);
    ..............................
    init();
    }


  • Lifetime Qt Champion

    What if you call init after show ?


  • Qt Champions 2016

    @PALYGAP
    Can you provide your MainWindow constructor as well (I think this is what @elveatles had in mind)?



  • @SGaist : Tried putting init() after show() but no change in behaviour.

    @kshegunov : Here is the MainWindow constructor

    MidyAX::MainWindow ( QWidget * parent, Qt::WindowFlags flags )
    : QMainWindow(parent, flags),
    // Quite a few variables init
    m_dlgTheFirstQDialog(0),
    m_dlgTheSecongQDialog(0),
    ......
    {
    ui.setupUi(this);
    ....
    }


  • Qt Champions 2016

    @PALYGAP

    So, as @elveatles suggested, create your dialogs with parent:

    m_dlgTheFirstQDialog(0),
    m_dlgTheSecongQDialog(0),
    

    These two don't have a parent and are free flowing.



  • OK, didn't thought it had to be done there, but it makes sense why should it be any different. When I was opening the dialog throuoght the proper "init" : TheFirstQDialog::TheFirstQDialog(QWidget *parent) : QDialog(parent).

    Thanks a lot.



  • Actually the problem is not solved, the instructions :
    m_dlgTheFirstQDialog(0),
    m_dlgTheSecongQDialog(0),
    in the constructor of the main windows are just pointers to the QDialogs.

    The real call to the child QDialog creators are here :

    TheFirstQDialog* MainWindow::dlgTheFirstQDialog()
    {
    if (m_dlgTheFirstQDialog == 0) {
    m_dlgTheFirstQDialog= new TheFirstQDialog(this);
    }
    return m_dlgTheFirstQDialog;
    }
    TheSecongQDialog* MainWindow::dlgTheSecongQDialog()
    {
    if (m_dlgTheSecongQDialog == 0) {
    m_dlgTheSecongQDialog = new TheSecongQDialog(this);
    }
    return m_dlgTheSecongQDialog;
    }

    this is the pointer to the MainWindow and I checked in the degugger it is set to the right value in the Qdialog constructor :
    TheFirstQDialog::TheFirstQDialog(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::TheFirstQDialog),
    m_setup(false),
    m_initMode(false)
    {
    .....
    }


  • Qt Champions 2016

    @PALYGAP
    That's curious. Can you prepare a minimal example that reproduces this, I could run it on my machine (I'm using Debian)?



  • Ok I'll try to do that this Week.



  • I have installed an new DEBIAN (Linux debian64SMP 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) x86_64 GNU) with GNOME 3.14..1 in a new VirtualBox. I installed Qt5.8.0 and Qt Creator 4.2.1 and recompiled my applications. There are still as many application icon in the "task bar" as there are dialogs. The thing that has improved is that main dialog (main window) that I could not activate (or Alt-tab) to before if another dialog was open is now accessible.

    Still don't understand why there is an icon in the "task bar" for each dialog of the application.


  • Moderators

    @PALYGAP Well, I guess it is how window manager handles it (the one used by Gnome in your case), it is not Qt related.
    If you were not able to access main window when a dialog was shown then I guess you used a modal dialog (calling exec() on it instead of show) - this is expected behaviour. Use show() if you want to be able to switch between dialogs/main window.



  • @jsulm it could be. The thing is for the dialog (representing MIDI Controllers) I use QDialog::show(). I only use exec() for some error message QDialog or config dialog. So I can have the QMainWindow and several QDialog displayed with show() at the same time. They will all have one icon in the "task bar". The "not able to access main window when a dialog was shown" behavior was not wanted and none of the QDialogs (MIDI controller) were shown with modal exec(). Maybe it was just a bug of the previous GNOME environment that I was using. :)


Log in to reply
 

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