How to create a child-toolwindow for QOpenGLWindow

SGaist

Can you show how you are handling these two widgets ?

Joe Malik

Hi SGaist,
thanks again for your support with this problem.
Below I'm trying to provide all relevant portions of my code regarding the two widgets while excluding everything else for better clarity.
My second best option probably would be just to combine viewport and controls in one widget and thus avoid the always-on-top requirement entirely. Although I would of course prefer to learn what I was missing here.

class OpenGLWidget : public QOpenGLWidget, protected QOpenGLFunctions
{
	Q_OBJECT
	friend class ControlDialog;
public:
	OpenGLWidget();
	~OpenGLWidget();
protected:
	bool event(QEvent *event) override;
	void keyPressEvent(QKeyEvent *e) override;
	void toggleFullscreen();
private:
	ControlDialog* m_ctrlDlg = nullptr;
};

OpenGLWidget::OpenGLWidget()
	: QOpenGLWidget()
{
	setGeometry(300, 300, 800, 800);

	m_ctrlDlg = new ControlDialog(*this, *m_boids);
	m_ctrlDlg->show();
	m_ctrlDlg->setWindowFlags(m_ctrlDlg->windowFlags() | Qt::WindowStaysOnTopHint);
}

OpenGLWidget::~OpenGLWidget()
{
	delete m_ctrlDlg;
	m_ctrlDlg = nullptr;
}

bool OpenGLWidget::event(QEvent *event)
{
	switch (event->type())
	{
	case QEvent::Close:
		m_postfx->running = false;
		m_ctrlDlg->close();
		break;
	}
	return QOpenGLWidget::event(event);
}

void OpenGLWidget::keyPressEvent(QKeyEvent *e)
{
	switch (e->key())
	{
	case Qt::Key_F:
	case Qt::Key_F11:
		toggleFullscreen();
		break;
	}
}

void OpenGLWidget::toggleFullscreen()
{
	if (windowState() & Qt::WindowFullScreen)
		showNormal();
	else
		showFullScreen(); // TODO: control dialog is in background, bring it back to front
}

// ----------------------------------------------------------------------------

class ControlDialog : public QDialog
{
	Q_OBJECT
public:
	ControlDialog(OpenGLWidget& mainWnd, CLBoids& boids);

protected:
	void keyPressEvent(QKeyEvent *e) override;
	void showEvent(QShowEvent *e) override {} // empty override to suppress re-centering of dialog on Show event

private:
	bool eventFilter(QObject *obj, QEvent *event);
	OpenGLWidget& m_mainWnd;
	QTimer m_hideTimer;
};

ControlDialog::ControlDialog(OpenGLWidget& mainWnd)
	: QDialog(&mainWnd, Qt::WindowStaysOnTopHint)
	, m_mainWnd(mainWnd)
{
	m_ui.setupUi(this);
	
	setWindowFlag(Qt::Tool);
	setWindowFlag(Qt::WindowMaximizeButtonHint, false);
	setWindowFlags(windowFlags() | Qt::WindowStaysOnTopHint);

	qApp->installEventFilter(this);
	m_hideTimer.setInterval(5000);
	m_hideTimer.callOnTimeout([&](){ hide(); });
	m_hideTimer.start();
}

void ControlDialog::keyPressEvent(QKeyEvent* e)
{
	m_mainWnd.keyPressEvent(e); // forward events to main window
}

bool ControlDialog::eventFilter(QObject* obj, QEvent* event)
{
	switch (event->type())
	{
	case QEvent::Close:
		m_mainWnd.close();
		break;
	case QEvent::MouseMove:
	case QEvent::KeyPress:
		m_hideTimer.start(); // resets timeeout
		if( !isVisible() )
			show();
		break;
	}
	return false;
}

SGaist

That looks a bit very convoluted.

Can you explain what that tool window is responsible for in your application ?

Joe Malik

OpenGLWidget serves as main window. It is created from main() and does not contain any child widgets and provides the OpenGL viewport.
The ControlDialog tool window contains a couple of sliders to adjust some parameters and shader uniforms of the animation running in the main window. It is created as child of the OpenGLWidget. The goal of splitting viewport and controls in two windows was to show the UI when required and hide it by timeout when there is no user input so it does not distract the view when running in fullscreen mode.

SGaist

Ok, then let's simplify things a bit.

You should have slots in your OpenGLWidget that allows to adjust whatever values you want.

Then add signals to your ControlDialog that emits the values of the corresponding controls.

Connect these to together and voilà, no need for passing events around and you can easily implement new controls without worrying about handling events.

This also makes both widgets completely independent and thus easier to maintain.

CroCo

@Joe-Malik so you need two separate windows, right? One for OpenGL and second for control options.

Joe Malik

Hi @SGaist,
I can surely agree on the general advantages of message passing and decoupling you outlined. And I also see it as a worthy idea to consider a generalized event based shader parameter passing mechanism.
I really won't claim that my choosen way to handle reciprocal dependency of the two widgets is the best possible design neither for the general nor current case. So far I just judged it as good enough and IMHO all possible approaches on this come with their own pros and cons.
But in the end I don't understand how this questions of software design (which is always a good topic to think and talk about) relates to my initial problem of making the second widget stay on top?

Joe Malik

Hi @CroCo,
thanks a lot for your reply.
Yes, I would like to have two widgets. One for OpenGL and the second for some control widgets with the additional requirement that it should stay always on top of the first one even if it is shown in fullscreen mode.

SGaist

@Joe-Malik said in How to create a child-toolwindow for QOpenGLWindow:

But in the end I don't understand how this questions of software design (which is always a good topic to think and talk about) relates to my initial problem of making the second widget stay on top?

Mostly unrelated because I got sidetracked by the implementation.

What OS are you currently your application on ?

Joe Malik

Hi @SGaist,
thank you very much for staying tuned to this topic.
I'm running on Windows 10 x64 and builing with Qt 5.12.1, VS 2017 v141 and Win SDK 10.0.17763.0.

SGaist

What if you don't give your dialog any parent ?

Joe Malik

Setting no parent for the control dialog makes the behaviour even worse.

If the control dialog is a child of the OpenGLWidget and I switch it to fullscreen the control dialog is shown on top as intended. When I now click somewhere in the viewport the control dialog is sent to the background. When I then click again in the viewport somewhere in the area where the control dialog was located it gets back in the foreground.
If the control dialog has no parent and I switch to fullscreen mode it it is sent to background and stays there until I leave fullscreen mode no matter where I click. It is also not possible to switch to it via Alt+Tab or move it in front of the fullscreen viewport from a second monitor.

In both cases it seems to be the focused state of the OpenGLWidget which keeps the control dialog from getting back to top again.