ToolWidgets disappear when window inactive

[Moppel]

Hi,

I noticed a strange effect: When applying the 'QT::Tool' flag to a widget, the widget will disappear when the main (parent) widget gets inactive.
Well, this is the behaviour on Linux and Mac OSX. I had the chance to test this on windows today and there the subwidget will stay visible even if the parent is inactive resp. only partly visible. I can even cover the parent completely and still the floating subwidget stays visible.
This is how I expected it to work.

To elaborate a bit:
Go to the qt422/demos/mainwindow folder and run the mainwindow example.
Now make one of the subwidgets floating. Just move it outside the mainwindow and click on the desktop or another program window. The floating window will be gone, even if it isn't covered by any other window.
Now move the floating widget inside the mainwindow but don't let it dock (You have to move it above the central widget (the one with the text inside)).
Let the program become inactive (click on the desktop) and the floating subwidget is gone.
That can't be right, can it? I tested it with KDE and on the Mac desktop. I don't really think it's a desktop manager issue. It just doesn't feels right.

What do you think? Is it the desired behaviour or isn't it. If the majority thinks it's not, I will have to file a bug report.

Moppel

Would be interested if someone could verify that on a qt 43 snapshot build.

[wysota]

That can't be right, can it?
Why not?

I tested it with KDE and on the Mac desktop. I don't really think it's a desktop manager issue. It just doesn't feels right.
It's not an "issue", it's a "feature".


What do you think? Is it the desired behaviour or isn't it. If the majority thinks it's not, I will have to file a bug report.
I think it is a desired behaviour. Qt tries to follow the rules of the platform it runs on and sometimes the rules are different for different platforms - that's why you experience different results - they just follow the platform convention. That's my opinion :)

[Chicken Blood Machine]

I think it is a desired behaviour. Qt tries to follow the rules of the platform it runs on and sometimes the rules are different for different platforms - that's why you experience different results - they just follow the platform convention. That's my opinion :)

I'd have to agree with that. It's certainly the correct behavior for the mac.

[Moppel]

It's not an "issue", it's a "feature".

I don't mean "issue" as if in problem.




I think it is a desired behaviour. Qt tries to follow the rules of the platform it runs on.

I know it does. And for my opinion it does it perfectly well!
Have you tried the example?

I've been using KDE for I don't know how many years now and can't think of an example application which does it that way. Actually can't really think of an application using those tools at all. The ones I can think of (gimp, inskape or xmms) are gtk applications. Anyway, just tested it on Inksape and there the floating "toolboxes" like "fill and stroke" or "grid arrange" behave differently. Having said that, those toolboxes are shown as sort of normal windows with a full sized titlebar.

Using Mac OSX for not more than about two months I can't really say what is 'normal' there. It just felt a bit odd. Trying to look for an example app I stumbled over the sticky notes. I would find it odd if they disappeared when not having sticky notes active. But than, that's not comparable. I can't really come up with a good example. Finder's windows are no toolboxes either.
Any example welcome even if it proves me wrong.

Right, just found a KDE example against my case.:rolleyes:
Just teared off the Kate's "Main Toolbar". Whilst I'm writing here, Kate is inactive and the teared off toolbar the is gone. O.k. for a toolbar but I didn't see those QDockWidgets so much as a tearable Toolbar.

Anyway, I have to think of another way to achieve what I wanted to achieve. I'm just porting an application to Qt4 I wrote for KDE 3
http://www.kde-apps.org/content/show.php?content=35246.
It's more a rewrite since I want it to be much more modular. The visual plugins should be floating windows.
I wan't all of them to be closed once the mainwindow is close. Actually the only thing I need of the mainwindow is the menubar. That works brilliantly on the mac. But where would I place it on the other systems? ;) (I have thought of making it a taskbar thingy. But I don't know if that is justified. Taskbars are usually rather cluttered anyway.)
If I use normal widgets, with 0 as parent, I have them "floating" but the application isn't closed if I close the main window.
Also in that case I get the normal frame. (O.k. I could use a style or make them frameless. In the latter I would have to draw my own titlebar to make them moveable and resizable. The Qt::Tool windowflag seemed just to do everything I wanted. Maybe I try to look how the trolls did it.)

I'm open for suggestions.
I hope to be able to release some pre alpha code on the weekend. Maybe that helps to understand my problem.

Cheers,

Moppel

[wysota]

Right, just found a KDE example against my case.:rolleyes:
Just teared off the Kate's "Main Toolbar". Whilst I'm writing here, Kate is inactive and the teared off toolbar the is gone. O.k. for a toolbar but I didn't see those QDockWidgets so much as a tearable Toolbar.
Toolbars are implemented as dock widgets in Qt3.

Examples of using dock windows in KDE? KDevelop, Gwenview...



I wan't all of them to be closed once the mainwindow is close. Actually the only thing I need of the mainwindow is the menubar. That works brilliantly on the mac. But where would I place it on the other systems? ;) (I have thought of making it a taskbar thingy. But I don't know if that is justified. Taskbars are usually rather cluttered anyway.)
If I use normal widgets, with 0 as parent, I have them "floating" but the application isn't closed if I close the main window.

Reimplement the closeEvent() for the main window and close all the child windows there.

[Moppel]

Examples of using dock windows in KDE? KDevelop, Gwenview...
Just had a look at both of them. It's a few months since I used KDevelop last. (Running KDE 3.5.5): Judging from the style, both seem to use normal widgets as dockable widgets. And they don't disappear. Whilst writing here in the browser window I've got a flaoting image and a floating Diff output in the background.


Reimplement the closeEvent()
Thanks! That's the trick.

Just to answer my other question from below: Compilation of qt 4.3 snapshot on the mac has just finished. Of course it's still the same.

[wysota]

Judging from the style, both seem to use normal widgets as dockable widgets.
They seem to use QDockWidgets embedded into a QWidget (I mean their subclasses), nevertheless you wanted to know about applications using dock widgets, so I gave you examples, no matter how KDockWidget is (or was in earlier KDE versions) implemented...



Of course it's still the same.

Of course :) As I said - it's not an issue, it's a feature - it is meant to be that way.

Regards,
W.

[Chicken Blood Machine]

Using Mac OSX for not more than about two months I can't really say what is 'normal' there. It just felt a bit odd. Trying to look for an example app I stumbled over the sticky notes. I would find it odd if they disappeared when not having sticky notes active. But than, that's not comparable. I can't really come up with a good example. Finder's windows are no toolboxes either.
Any example welcome even if it proves me wrong.


Sticky notes is not really a good example, every note is a separate document window (a main window if you will). Here are some good examples:

Pages
Keynote
Motion, Soundtrack Pro, DVD Studio Pro
MS Office apps