search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
7.99k stars 994 forks source link

Display progress bars in taskbar/dock #3768

Open Spekular opened 7 years ago

Spekular commented 7 years ago

Proposal

Currently, progress bars are only displayed inside LMMS, and a user must have the window open and visible to see when a task is finished. By displaying progress in the taskbar or dock, users would be able to see task completion with the LMMS window hidden or closed. This allows them to more efficiently use their time, doing something else while LMMS loads a project*, renders, or performs some other long-running operation.

Support for this varies by OS:

Windows

Windows example MPC-HC Displaying playback position when paused (left) and playing (right)

Taskbar icons on windows can have one of five progress states, listed here: TaskbarItemProgressState Enumeration (System.Windows.Shell)

These are set with the TaskbarItemInfo.ProgressState Property (System.Windows.Shell)

And the progress percentage itself is set via TaskbarItemInfo.ProgressValue Property (System.Windows.Shell)

This seems to be supported by qt.

macOS

image Downloads folder with progress bar

I can't seem to find documentation for this, but I did find a BSD licenced thing on GitHub, and a StackOverflow question.

Linux

Linux example

Unity dock shows firefox download progress

This doesn't seem to be possible (yet) in gnome, according to this bug report

However, it is possible with Unity, using the LauncherAPI

Footnote

*If issue #3769 is fixed.

Spekular commented 7 years ago

FWIW:

TaskbarItemInfo.ProgressState Property (System.Windows.Shell)

TaskbarItemInfo.ProgressValue Property (System.Windows.Shell)

tresf commented 7 years ago

The macOS screenshot above was unusually large, I've shrunk it down a bit.

I like this idea. Can you find anything on Gnome3? Unity is being dropped, so it probably won't be worthwhile to write something against Unity specifically, but rather something that Gnome and KDE can benefit from (and hopefully others).

Spekular commented 7 years ago

As far as I can tell it's not available in gnome:

https://bugzilla.gnome.org/show_bug.cgi?id=701402

Offtopic:

I'm assuming you downloaded->cropped/resized->uploaded the macOS image to resize it? The windows example is my own, so I made it suitably small, but the other two I just searched up.

tresf commented 7 years ago

I'm assuming you downloaded->cropped/resized->uploaded the macOS image to resize it?

Yes.

As far as I can tell it's not available in gnome:

Ok, let's use your first post to document this.

We can code the Windows, Mac and Ubuntu stuff and put the stubs in for Gnome. From what I'm reading, KDE may already work with the Ubuntu implementation, so this would be worth testing on other desktops as well.

And as always, help/PRs are appreciated with this initiative.

Spekular commented 7 years ago

Ping to let email users know I've updated the first post.

musikBear commented 7 years ago

imo, not a needed feature 👎

Spekular commented 7 years ago

@musikBear is there any downside to it, though (other than opportunity cost)? I'm sure there are people who would appreciate it, including myself and tresf (afaik).

tresf commented 7 years ago

@musikBear this is a UI/UX feature and for long project exports (and perhaps large projects loading), it's valuable. The purpose of the bug tracker is to document, code and test bugs. Adding a thumbs down to a well thought proposal is OK, but please understand that it isn't very constructive.

musikBear commented 7 years ago

is there any downside to it, though (other than opportunity cost)?

Wouldent it prolong the loading, with yet another process / thread in that process?

Spekular commented 7 years ago

I imagine the increase would be negligible.

tresf commented 7 years ago

Wouldent it prolong the loading, with yet another process / thread in that process?

We already use progress indicators, this is just to display it in a taskbar as well.

gi0e5b06 commented 7 years ago

http://doc.qt.io/qt-5/qsystemtrayicon.html Don't use anything else. (btw for Linux this a standard D-bus service)

tresf commented 6 years ago

http://doc.qt.io/qt-5/qsystemtrayicon.html Don't use anything else.

@gi0e5b06 thanks for the link, but can you please explain how this is related to the dock area? The system tray is a completely separate part of the desktop and also one that we do not leverage (nor have we had a need to leverage).

gi0e5b06 commented 6 years ago

@tresf Displaying progress in the taskbar is neither common nor standard. Most apps use notifications instead (often displayed in the system tray). My point was to suggest not to use anything which is not Qt.

tresf commented 6 years ago

Displaying progress in the taskbar is neither common nor standard.

The code may not (yet) be standard, but the UX is and we're talking about UX improvements. Gnome doesn't recognize it, but hopefully Ubuntu changes that as they switch 17.10 to gnome/wayland. Gnome also doesn't believe in minimize buttons, so they're the ridiculous exception, not the standard to UX. I digress. We can code this and it's not a lot of work.

Examples of standard UX that supports the statement that the launcher/taskbar deserves the progress indicator...

In regards to the APIs that are available...

In summary, I strongly disagree with the System Tray placement. I feel this is non-standard UX for an interactive desktop application and feel LMMS DOES NOT belong in the tray. Please provide a better use-case for your argument. I've provided (3) three standard and common UX examples where the task bar is the right place for progress indicator on lengthy operations.

On a side-note, I'm the author of a program that runs exclusively in the system tray, so I feel I'm a good judge of when the tray should -- as well as when the tray should not -- be used in a user environment. (please accept my apologies for the crosslink/plug)

NickAcPT commented 6 years ago

I think this is a good idea, but not for LMMS. In order to make this proposal into reality, the developers would need to depend on different OS specific code. We, people, need to think ahead. What if some people grouped up to port LMMS to Android/iOS devices? What if they wanted to have one source code that would produce binaries to Windows/Linux/MacOSX/Android/iOS, all in one codebase? That would be hard to maintain. And I'm not talking about now. I'm talking about the future.

I figured I would give my two cents about this. Sorry if my english is broken. 😄
gi0e5b06 commented 6 years ago

@tresf That was a long answer :) I was suggesting to notify the same way as when you copy files. Anyway, what you're looking at is this: https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/coreplugin/progressmanager

tresf commented 6 years ago

What if some people grouped up to port LMMS to Android/iOS devices? What if they wanted to have one source code that would produce binaries to Windows/Linux/MacOSX/Android/iOS, all in one codebase?

We're bikeshedding. Again. The obstacles to Android and iOS are far greater than a stupid progress indicator. Sound-backend alone is already largely platform dependent as is MIDI support (better yet the pile of libraries we compile into our code). Did you know Android is Java and iOS is Objective-C? I digress again. Although we appreciate articulated answer, please stop speculating, it takes away from the otherwise well thought out conversation.

@gi0e5b06 thanks for the code. 👍

I was suggesting to notify the same way as when you copy files.

I'm not sure I read that from your posts, but thanks for the nudge in the right direction.

NickAcPT commented 6 years ago

The obstacles to Android and iOS are far greater than a stupid progress indicator. Sound-backend alone is already largely platform dependent as is MIDI support (better yet the pile of libraries we compile into our code).

Android Marshmallow introduced a MIDI API. I still haven't searched if there is a MIDI API for iOS devices

Did you know Android is Java and iOS is Objective-C?

Yeah, I know that. When I talked about "Android and iOS with the same codebase", I was subconsciously thinking about Xamarin. In this case, the downside of Xamarin, is that you'll need to migrate code to c#. Also, with a small search I got to this question on StackOverflow that talks about using C++ code on Xamarin.

Sorry for bothering you and thank you for your fast reply
eagles051387 commented 6 years ago

Your iOS statement is inaccurate. In the early days iOS was objective c only now you can develop with c/c++ as well for iOS

Sent from my iPhone

On 13 Oct 2017, at 09:05, NickAc notifications@github.com wrote:

The obstacles to Android and iOS are far greater than a stupid progress indicator. Sound-backend alone is already largely platform dependent as is MIDI support (better yet the pile of libraries we compile into our code).

Android Marshmallow introduced a MIDI API. I still haven't searched if there is a MIDI API for iOS devices

Did you know Android is Java and iOS is Objective-C?

Yeah, I know that. When I talked about "Android and iOS with the same codebase", I was subconsciously thinking about Xamarin. In this case, the downside of Xamarin, is that you'll need to migrate code to c#. Also, with a small search I got to this question on StackOverflow that talks about using C++ code on Xamarin.

Sorry for bothering you and thank you for your fast reply

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

softrabbit commented 6 years ago

When I talked about "Android and iOS with the same codebase", I was subconsciously thinking about Xamarin. In this case, the downside of Xamarin, is that you'll need to migrate code to c#. Also, with a small search I got to this question on StackOverflow that talks about using C++ code on Xamarin.

Qt should cover those two mobile OSes, see http://doc.qt.io/qt-5/supported-platforms.html

tresf commented 6 years ago

Qt should cover those two mobile OSes, see http://doc.qt.io/qt-5/supported-platforms.html

👍

Your iOS statement is inaccurate. In the early days iOS was objective c only now you can develop with c/c++ as well for iOS

@eagles051387 Thanks for joining the discussion. :) Thanks for the information, that's useful if we ever port to mobile. Let's not minimize the effort though, please. This run-on conversation started when it was suggest we do NOT use platform specific code for a particular feature due to the impact it would have on other OSs, specifically mobile OSs.

Although we'd garner a bunch of happy users if we ported to Android, the CPU architecture tends to be ARM and we would need to do a lot of legwork, such as porting our dependent libraries over as well. Also, we rely on some disk IO features that would break in a sandbox. The point here is, the progress indicator is 1. Standard. 2. Not a lot of work. I've seen no valid argument to NOT write the feature. One could argue with the amount of time spent arguing it could have been implemented by now. </bikeshed>.

Cherry-picking arguments is great for education, but if someone were to look back at this thread a year from now, it's all just offtopic banter. <3

follower commented 6 years ago

FWIW if Qt Creator's progress manager linked above isn't suitable, then (mis-)use of the following (on Mac OS X) might be another option:

[Edit: Oh, yeah, and Blender is another application which shows progress in the dock icon when rendering.]

ryuukumar commented 3 years ago

Anyone assigned/working on this? Was looking to try and implement this if it is still a wanted feature.

Regarding the porting to mobile platforms mentioned here, I believe a lot of the UI will have to be rewritten anyways, so I suppose one progress bar isn't really a big issue in that respect.

Spekular commented 3 years ago

No one is working on it as far as I'm aware, and yes I still think it's a good idea :)