Lmms: [bspwm/tiling wm] cant move lmms splash screen

[suptimal]

looks like this:

[tresf]

Can you elaborate? What do you want to move it for?

[suptimal]

the splash hides another window (of lmms) i cant click cause the splash blocks it:

i have to focus it via keyboard and use xdotool to move it.

[tresf]

Oh... Your WM is missing window borders.... Does QT Linguist have similar issues? Is this normal behavior on this WM?

[suptimal]

my wm support window border (ONY borders no titlebar ;) ) but lmms spawns the splash screen on top of all windows and i cant move resize or close the splash screen (not in bspwm nor in openbox).

[Sti2nd]

i cant move resize or close the splash screen

It isn't movable, resizable or closeable for me either... cause it isn't mean to be, it should close itself.

[tresf]

my wm support window border (ONY borders no titlebar ;) ) but lmms spawns the splash screen on top of all windows and i cant move resize o close the splash screen (not in bspwm nor in openbox).

Yeah, I don't think we ever accounted for this. I suppose we have few possible solutions to this problem...

1. Provide a new --nosplash command line option
2. See if we can set a window hint to the dialog to make it request focus
3. Hide the splash screen once the new dialog is opened.

Either way, I think it is a bug because solution No. 3 suggests we're doing something a bit unorthodox.

@curlymorphic This could be a quick one or it could be opening pandora's box...

What is your thoughts on this? It seems with certain Window Managers on Linux, we show the settings dialog prematurely...

-Tres

[curlymorphic]

Options 1 and 2 seem unorthodox as well to me. I dont think the splash screen should be shown after the app has started.

I have a Test build where I have transposed the lines above, to finish the spash screen before finalizing the main window. This seems to have no adverse effects under ubuntu, but I have not tested it under bspwm.

git clone -b "1882" https://github.com/curlymorphic/lmms.git

[eagles051387]

There is a 4th option here. That if the splash screen is mouse clicked on
that it disappears.

On Thu, Mar 19, 2015 at 8:05 AM, Dave [email protected] wrote:

Options 1 and 2 seem unorthodox as well to me. I dont think the splash
screen should be shown after the app has started.

I have a Test build where I have transposed the lines above, to finish the
spash screen before finalizing the main window. This seems to have no
adverse effects under ubuntu, but I have not tested it under bspwm.

git clone -b "1882" https://github.com/curlymorphic/lmms.git

—
Reply to this email directly or view it on GitHub
https://github.com/LMMS/lmms/issues/1882#issuecomment-83373373.

Jonathan Aquilina

[badosu]

I like @eagles051387 idea, is this doable?

[tresf]

From qt.io:

The user can hide the splash screen by clicking on it with the mouse. Since the splash screen is typically displayed before the event loop has started running, it is necessary to periodically call QApplication::processEvents() to receive the mouse clicks.

[Wallacoloo]

So the problem with hiding the splash screen on click is that during the initialization phase, which occurs while the splash screen is present, we (previously) never called qApp->processEvents() until after initialization was complete and we were ready to destroy the splash anyway (this is because control of the main thread is stuck in the core module instead of the gui module). The result is that Qt could not process the mouse click events until it was too late to be worthwhile.

In adding support for loading progress messages, a side-effect is that qApp->processEvents() is now called more regularly in order to update the progress message. It doesn't happen 60 times a second, but the code in #1915 does recognize a click within 0-0.5 seconds and correctly hides the splash screen.

Still not an ideal fix though.

[Wallacoloo]

1915 just got merged earlier today & should make the splash screen disappear upon clicking it. If you get a chance @blendi-93, could you see if this solves your issue? Note that on the first run, or if you run lmms without installing it, it may be unresponsive for a few seconds while it's generating its wavetables (which is an operation just performed on the first run).

[tresf]

I'm closing this as fixed by #1915. If it resurfaces, we'll track it in #4104, which is a similar bug but written against a more modern software release. Thanks @zonkmachine for linking the two. :)