Improve the cancel function of loading projects.

[zonkmachine]

When testing to load, play and close lmms I have had an on/off problem with projects not loading completely. As it turns out I had forgotten that there is a cancel button when loading and pressed play too fast which instead triggered the cancel action. I think this button should be pressed specifically and not be tied to any key but perhaps ESC . Or we could have some message function confirming the cancel. A text float or whatnot.
Maybe it's best to also clean out the project on a cancel?

[Umcaruje]

I agree that when we cancel the project, it should get cleaned out.

[BiRD4]

I think ESC and ENTER are both fine to use. I also agree that there should be a message to confirm the cancel, but I think this should keep the project from continuing to load until the user has confirmed the cancel. However, I think it might be nice to have the option to either clean out the project or keep only what has already been loaded.

[zonkmachine]

Bump @PhysSong You're working on other issues around project loading already (#3611, #3670) so maybe you could have a look at this?

[PhysSong]

@zonkmachine I think it won't be hard. I'll have a look.
I'll suggest something or make some PRs if I can.

[zonkmachine]

Here is an issue reported in the LMMS forum that could be related:
https://lmms.io/forum/viewtopic.php?f=7&t=8505
I'm not 100% sure it is related though but I've tried and cancel big projects and have gotten some positively odd results that wasn't obviously broken if you didn't know that a cancel had taken place. I'm labelling this as a bug instead.

[PhysSong]

Someone can cancel project loading accidentally add save the project without noticing that isn't loaded completely. Then some unloaded track will be lost.
Such accidents would be prevented. At least, we should notify user of the cancellation.

[musikBear]

Imo pressing cancel mean that the user made a mistake in the project selection, or simply does not want to use lmms now at all.
Cancel should just as @Umcaruje says clean away the project from screen, and then perhaps ask the user if he also want to quit lmms completely.
The situation that @PhysSong depict, and that maby even is the reason for forum8505, should never happen. Eg, partial loading should be prevented!

[PhysSong]

@musikBear I agree. Partial loading brings many problems.
Sometimes it makes sense, but usually not.

[PhysSong]

@zonkmachine Do you know how other programs handle cancellation of project loading? If yes, which method would be better?

[tresf]

A canceled project load should open to an empty project. The way apps do this varies a bit because most apps don't show a live progress but rather show a splash screen for the duration, so for other applications (Gimp, MSWord, etc) it's less obvious that the process was interrupted mid-load.

We should eventually do the same -- there's no benefit in animating the project loading process and it likely adds additional CPU overhead and slows down the initial load process in general (separate enhancement).

[PhysSong]

The way apps do this varies a bit because most apps don't show a live progress but rather show a splash screen for the duration

Yes. However, there are some apps which display loading progress(ex. FL Studio).

there's no benefit in animating the project loading process and it likely adds additional CPU overhead and slows down the initial load process in general

Maybe yes, but my opinion is NO. Showing loading progress must slow down loading. However, I think there would be no much difference in loading speed.
@tresf What is your opinion? Could you do some tests about it?

[tresf]

@tresf What is your opinion? Could you do some tests about it?

It's irrelevant to this bug specifically. Performance for the application is in dire need of improvement in general (e.g. UI events happening on same priority level as DSP events) but the scope of this bug report is to just make cancel work sanely, so I'd rather shelve the UX stuff for a separate thread if that's OK.

[zonkmachine]

I just had a bad load again. Bumping to 1.2. Testing a fix for this right now.