Progress bar during launch (with text) #1696

Closed
Spekular opened this Issue Jan 26, 2015 · 10 comments

Projects

None yet

4 participants

@Spekular
Contributor

Lots of programs have a loading screen similar to LMMS’s. What lots of those programs also have is an accompanying progress bar, sometimes with text on what the launcher is doing. This is especially useful for programs that take a while to launch. While LMMS launches rather quickly for me now, as it grows, or for users with slower PC’s, it might take a while. By adding a progress bar we let the user know that something is happening, and with accompanying text we tell them what that is. This makes loading a lot more bearable and would also ease troubleshooting/analyzing it, because it’s possible to see what’s taking so long.
Now, for users who launch fast, a progress bar might not be very appealing (they tend to look bad when loading too fast in my experience). This could be optional, but I don’t think that’s the best solution. Instead I propose the progress bar only show up if LMMS isn’t X% loaded after Y seconds. I’m pretty sure this type of “delayed progress bar” is present in other programs as well.
Thoughts?

@Spekular Spekular changed the title from Progress bar during launch to Progress bar during launch (with text) Jan 26, 2015
@Sti2nd
Contributor
Sti2nd commented Jan 26, 2015

How much time LMMS uses to launch takes everything from 1 second to 8 seconds for me... It is a bit strange, and seems a bit random. I think it is a combination of reuse of memory (as it seems LMMS starts really fast when it has just been closed) and my PC's performance/power setting.

I would say yes.

@tresf tresf added the enhancement label Jan 27, 2015
@tresf tresf added this to the 1.3.0 milestone Jan 27, 2015
@tresf
Member
tresf commented Jan 27, 2015

Progress bars are complicated beasts. They have to calculate the components to "load" and then each component must have a specific "weight". I.e. A .WAV that is 100MB might take longer than a .WAV that is 1MB. These calculations and aggregation of data is then monitored by some singleton process and updated. In some cases multithreading kicks in and components can race ahead (I think we are a single-threaded load currently).

So yeah, its a nice to have, but I don't know much value it has. We may instead decide to have a single indeterminate loading dialog that just specifies what is happening which would be much simpler and not a tremendous amount of value lost.

@tresf
Member
tresf commented Jan 27, 2015

P.S. I've done the indeterminate loading bars (built-in and custom), they aren't that bad.

Standard loading bar v. Indeterminate loading bar:

image

@Spekular
Contributor

@tresf only text with what's happening might fit nicer with our loading
screen too. I vote real progress bar or no progress bar, an indeterminate
bar doesn't tell me anything I don't already know.

@Sti2nd
Contributor
Sti2nd commented Jan 27, 2015

text with what's happening might fit nicer with our loading
screen too

If it is simpler that would totally work. What I am looking for is proof that LMMS is actually doing something in those 8 seconds, or if it is my PC limiting resources.

@tresf
Member
tresf commented Jan 27, 2015

I vote real progress bar or no progress bar, an indeterminate bar doesn't tell me anything I don't already know.

Yeah, this is how GIMP does it. I personally like the busy animation too. It's part of every "wait" dialog since the 90s. :)

@unfa
Contributor
unfa commented Jan 28, 2015

I vote for simple changing text with a small animated circle indicating
that the program is alive.
27 sty 2015 07:08 "Spekular" notifications@github.com napisał(a):

@tresf only text with what's happening might fit nicer with our loading
screen too. I vote real progress bar or no progress bar, an indeterminate
bar doesn't tell me anything I don't already know.


Reply to this email directly or view it on GitHub
#1696 (comment).

@tresf
Member
tresf commented Jan 28, 2015

I vote for simple changing text with a small animated circle indicating that the program is alive.

👍

@tresf
Member
tresf commented Apr 27, 2015

Closed via #1915

Edit: Just realized this was for a progress bar too, which #1915 doesn't cover... Feel free to open a second bug report if you deem that necessary.

@tresf tresf closed this Apr 27, 2015
@Spekular
Contributor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment