Update: Chris added to another, related, report:

Chris: Looks like Qt::Tool is not the proper window type for this window, regardless of how nicely it works for me! Try replacing Qt::Tool at TransportDialog.cpp:59 with some other flag, or combination of flags, from http://doc.trolltech.com/4.4/qt.html#WindowType-enum and see what serves best. –cc)

Michael: OK, Chris, I'm off to play with that and see what I can do.

Finally, Michael: OK, I played with this for many iterations, trying all kinds of different combinations in an attempt to duplicate the 1.x behavior. Only after reverting it back to Qt::Tool did it finally dawn on me that the extra minimize button I was trying to get rid of was already there. I'm not sure how we can get rid of that, but if it was present as a result of Chris's choice too, there's no further point worrying about it.

So after comparing 1.x against 09.x side by side extensively, most choices all result in the same 1.x-like behavior, and of the usable choices only Qt::Tool has this winking out problem. I settled on 0 as the answer, because if we set this to 0 we get a “what is this” button that is actually useful, and no extra buttons other than the minimize that won't go away. We defined text for these things at some point, but AFAIK they have never been visible before. So what the hell, let's go with 0 and leave the “what is this” button there.

Since the “what is this” thing is a Qt idiom, and we're a Qt app now, it might be worthwhile taking that idea further, actually.

Old discussion follows:

Yves (?): When the transport dialog itself has been moved outside of the main window, to click any of its buttons becomes a challenge.

Chris: can't reproduce this

Yves: Probably related to “focus under the mouse” window behavior

Chris: Your WM is broken! How do you cope with using any modern application with floating tool windows if they disappear when you move the mouse away from the application's main window?

Yves: KWin is broken? I've used this for years.

Michael: OK guys, here is some more detailed discussion, which I have pulled into a new page.

  1. I have the “focus follows mouse” policy in force too, and I've been using this KDE setting for several years
  1. Changing the focus policy to “click to focus” does NOT change the behavior Yves and I observe. It just means you have to go to more work to make the Transport disappear, because you actually have to click outside Rosegarden's main window for it to lose focus

What happens is:

All of this is definitely broken regardless of KWin's focus policy. I'm using KDE 3.5.10, I guess it is. I don't think that should have any bearing on anything, though I haven't tried with other WMs (including the new KDE, which is still too featureless and broken for me to upgrade yet.)

I have no idea how we can fix this, but it's definitely broken compared to RG 1.x

I'm doing a test here, I have “focus follows mouse” restored as usual. I've got RG sitting on top of a maximized Konsole window. I dragged the transport and the zoom slider toolbar outside of RG's main window

When I mouse out of RG's window into Konsole's space, Konsole gets the active window decorations and RG's decorations become inactive, but Konsole doesn't actually raise above RG unless I click inside it. RG's main window stays visible above Konsole, but it is “inactive” now. When it becomes “inactive” any child windows that have any part of themselves outside the main window disappear. This includes floating toolbars.

Now I set up the same test with 1.7.x sitting on top of Konsole.

With 1.7.x, if I actually detach the Zoom toolbar, it behaves the same way as 09.x as just described. The toolbar winks out of existence as soon as the main window loses focus. The TRANSPORT, however, stays right there.

I think the old Transport used to be a KMainWindow or something. I think the base class for the Transport is probably behind all of this weird new focus and winking in and out of existence behavior.