Provide status messages on splash screen when loading (#1696)

[Wallacoloo]

Based on the discussion about #1696, this updates the splash screen to look like this:

No progress bars or anything, just a discreet status message in the lower-left that updates to reflect the current component being initialized.

[Spekular]

Awesome! :D

[Wallacoloo]

Glad you like it :-)

[tresf]

FYI - @diizy may object here to using signals and slots on a non-GUI class.

[tresf]

This looks really good, thanks!.

Per @diizy there have been some strategic decisions to not add QObject references to non-GUI components, so this might need some redesign before it is accepted.

[M374LX]

Really nice idea.

[Wallacoloo]

I won't argue here with the decision to avoid signals (I don't actually disagree with it), but if there is an objection to using signals then please recommend an alternative.

[Umcaruje]

A typo here, its beat+bassline editor.

[tresf]

*it's

:)

[Wallacoloo]

Thanks for catching that! Should be fixed now.

[Umcaruje]

:)

[tresf]

but if there is an objection to using signals then please recommend an alternative.

This isn't my area of expertise. I don't know the best approach but until we settle on one, we may want to consider decoupling the status messages from the Engine class and simply loose that display information for now.

[Wallacoloo]

That is one option. Another option is to pass an (optional) std::function to Engine::init that serves as a progress callback. This requires C++11 or boost; I don't know what C++ version is currently being targeted. Alternatively, we could use classic C static function pointers for the callback.

Also possible is to split the Engine::init() function into smaller pieces that must be called successively: Engine::initWavetables(), Engine::initPluginFileHandling(), etc. This allows the GuiApplication to insert progress messages at each step. The downside is that it doesn't adapt to future changes in the Engine init system.

Another possibility is to do the initialization in a separate thread from the main GUI and use some sort of messaging system, say condition variables for communication. A benefit to this is that it's much easier to create a responsive UI during initialization using a separate init thread. That is, it more effectively solves the problem of the splash screen not being dismissable by clicking, and potentially allows things like loading animations or for progress bars that update smoothly. I'm not too worried about that, but it's a possibility. Personally, I think this last option is overly complicated.

[Wallacoloo]

I won't argue here with the decision to avoid signals

Well I may have lied there. Is it really a problem to inherit from QObject in the core module? That would make sense to me if there was a goal to remove the Qt dependency from the core, but looking through the rest of the code, and reading some discussions here on github, it seems that the issue is only using QtGui resources in the core, and relying on slots for real-time functionality.

Since initialization messages aren't real-time critical events, I don't see what's wrong with using signals here.

[tresf]

I won't argue here with the decision to avoid signals... Well I may have lied there.

Good. :)

@diizy's input is much more valuable than mine in this instance. Hopefully he has some time to chime in. 👍

[softrabbit]

If there are rules that developers are supposed to follow, shouldn't they be documented somewhere easier to find than in the comments for some issue (that might seem unrelated at first glance)?

Not that I'm questioning the rule, whatever it is. I did a fair bit of googling on this, and didn't find much concrete info either way. But I'm sure @diizy has sources to back up his policies.

One would imagine using signals and slots in function A doesn't affect function B, so if that is the unclean thing being targeted the rule could really be applied with finer granularity than on a class basis. OTOH, inheriting QObject means at least some automagic stuff is happening behind the scenes, and that might taint the whole class. OT3rdH, static functions, like in Engine, might be different as they don't involve an object of the class...

[Wallacoloo]

#1982 describes an alternative implementation of splash screen status messages that avoids using signals or inheriting from QObject.

I should stress that it's an alternative to this PR, as opposed to outright superseding it, because nobody had provided concrete feedback on whether signals should absolutely be avoided in this case and/or what a good alternative would be, and some may prefer the signal version because it is simpler (though personally, I do think 1982 is a better implementation).

[tresf]

If there are rules that developers are supposed to follow, shouldn't they be documented somewhere easier to find than in the comments for some issue (that might seem unrelated at first glance)?

Yes, not only for the RT-stuff but probably for the software in general. If a new developer were to get involved, it would be nice to hand them a good architectural map with some design flow, FAQs.

static functions, like in Engine, might be different as they don't involve an object of the class...

👍

@Wallacoloo this seems to be the preferred approach, merging. Thanks for taking the time to make two PRs.

[Wallacoloo]

@tresf I was literally just typing out a comment about going with your earlier suggestion to just remove the bits from the engine until we get a better message passing interface in LMMS. Are you sure you're comfortable merging this as-is?

[tresf]

@tresf I was literally just typing out a comment about going with your earlier suggestion to just remove the bits from the engine until we get a better message passing interface in LMMS. Are you sure you're comfortable merging this as-is?

Yes. The RT-safety and abolish all signals/slots is an initiative that has merits in DSP-heavy code and AFAIK this code is really just firing up the singleton processing engine. If certain parties want to make abolish all signals and slots a big deal, 25 days is plenty of time to be the 12th juror, so to speak. :)

[Wallacoloo]

@tresf great point. I'm glad this feature is finally seeing the light of day!