Change tooltip window flags

[regulus79]

Partially addresses #7145.

This PR changes the window flags of TextFloats (the tooltip things which appear when loading samples/vst/etc) so that they do not stay on top of other windows.

[Rossmaxx]

obs-recording-2024-12-12-16-27.mp4

This is how the tooltips work now on my computer. Ignore the vst bug, it's been there for a while.
But at the start, the tooltip appears hidden. Is it intended?

[Rossmaxx]

I'll approve and merge once I get a clarification

[regulus79]

the tooltip appears hidden. Is it intended?

This is not intended. But I don't know why it is happening. Given that I can see the faint outline of the tooltip window in your video before it appears probably means that the window has been created, but not yet filled? I don't know if that would be an issue with the windowing system or with Qt.

[Rossmaxx]

Thanks for the explanation. Your suspects of windowing system and qt seems valid. I believe such glitches are found here and there with qt applications on x11. Btw are you on x11 or Wayland?

[Rossmaxx]

Since it's improving the situation, LGTM.

[regulus79]

Btw are you on x11 or Wayland?

I am on Wayland. I actually don't use/have any VSTs so I'm unsure if this particular issue occurs for me, but other times where TextFloats appear (like loading a sample) work fine.

[Rossmaxx]

On sample load, i don't even see a text float

[regulus79]

When loading large samples, it appears for a split second.

[michaelgregorius]

To me it does not look like it is really improving the situation. It now just seems to show the message box that asks the user to wait until the action is completed much too late.

It would be better to find out what's causing the current behavior. To me it looks like there's some code that wants to show the message and which start doing so but then something long running is taking over the GUI main thread?

[Rossmaxx]

@regulus79 how much sense would it make to replace this TextFloat with a QToolTip directly?

[michaelgregorius]

@Rossmaxx, a QToolTip is shown interactively when a user hovers with the mouse over a widget whereas TextFloat is intended to be shown "programmatically". They are really different classes of widgets and should not be mixed IMO.

I have checked VestigeInstrument::loadFile and it is as expected. A call to gui::TextFloat::displayMessage is made and it is then immediately followed by potentially long running actions like loading and initializing the plugin on the GUI main thread. Hence it all happens during the processing of a single event and the text float cannot be shown before the long running actions have performed.

Can someone please check if it gets better with the following adjustment in gui::TextFloat::displayMessage (addition of QCoreApplication::processEvents()):

	if( gui::getGUI() != nullptr )
	{
		tf = gui::TextFloat::displayMessage(
				tr( "Loading plugin" ),
				tr( "Please wait while loading the VST plugin..." ),
				PLUGIN_NAME::getIconPixmap( "logo", 24, 24 ), 0 );
		
		QCoreApplication::processEvents();
	}

I don't any plugin that takes as much time as the one used by @Rossmaxx in the video.

[Rossmaxx]

Or nvm, that regression caught in my video might be the one from #7554, fixed by #7624. I do have to test now again to confirm. If it's so, there's nothing to do, I'll try @michaelgregorius' suggestion too, just to be sure.

The plug-ins i use are 4front e piano and dsk grand piano (IIRC, grabbed them from plugins4free)

[michaelgregorius]

I have just created #7626 which reports other problems with TextFloat under Wayland. Perhaps it is best to implement messages in a different way as proposed in the issue.

[regulus79]

@michaelgregorius Although this PR does not fix the other issues with TextFloats, it does at least make it so that they do not stay on top of all other application windows, which I think is an improvement. I do agree that there may be better ways to implement this sort of message box than creating a new window, but would it be beneficial to merge this fix now and rework TextFloats later?

[Rossmaxx]

@michaelgregorius Although this PR does not fix the other issues with TextFloats, it does at least make it so that they do not stay on top of all other application windows, which I think is an improvement. I do agree that there may be better ways to implement this sort of message box than creating a new window, but would it be beneficial to merge this fix now and rework TextFloats later?

This is what I was telling. Though I wasn't descriptive with it.

[regulus79]

Can someone please check if it gets better with the following adjustment in gui::TextFloat::displayMessage (addition of QCoreApplication::processEvents()):

I tested this, and it does appear to fix the TextFloat being black at the start. I have now added QCoreApplication::processEvents() to the end of TextFloat::displayMessage. If other people could test this that would be great.

Edit: I'm not actually sure it fully fixed the issue; now it feels like the TextFloats appear later than they usually do. It's hard to tell.

[michaelgregorius]

IMO this is the wrong place to fix the problem. Instead the problem(s) should be fixed in the places where long running operations are performed in the GUI main thread, e.g. in the VST loading code, etc.

The TextFloat as is works perfectly okay and you would see similar problems with other widgets if they are about to be shown before something that blocks the GUI main thread.