19

It\'s possible to write a plasmoid that interfaces with a certain application, but regardless of whether the application is running or not, it\'s always going to sit there.

I propose that applications be able to register plasmoids that plasma is supposed to use in place of taskbar entries for this application. The base class of such plasmoids would provide the functions of a taskbar button, but custom subclasses could in addition display all kinds of additional stuff, like progressbars.

The difference from regular plasmoids is that taskbaroids would be dynamically created by the taskbar when a window opens and closed when the app terminates.

Yes, yes, yes!!! I'm already looking forward to what cool ideas people come up with for their own taskbaroids.

How would this be different from the new system tray protocol?

The system tray is for inactive applications and is semantically bound to showing a status, which becomes apparent through the fact that KDE needs to add that notification item. Like already noted in other ideas, it would be more natural to group running jobs and activities with the taskbar items.

Thanks for raising this kind of idea again. (See also brainstorm.php#idea61967... not so well expressed but my second post has some similar ideas)
There is a little overlap with kustodian http://www.kdedevelopers.org/node/4038... app buttons will sit there, running or not.

But really I like the idea of having grater access to status and functions of minimised applications. And replacing the existing dumb task-bar button system with an interactive mini-interface / plasmoid seems the most obvious way to achieve this to me. It also extends one of brainstorm's most popular ideas (brainstorm.php?mode=idea&i=43570#anchormain)

How would this be different from the new system tray protocol?

AFAIK, the new system tray protocol defines a very limited set of functionality.
The point of writing an actual plasmoid in this situation is not having to specify a whole remote widget interface, that'd allow an app to put widgets on another process' (plasma's) surface. That'd be a lot more work.

There are still problems that need addressing of course, like space allocation.
For a single row taskbar, the height would be fixed and width allocation could be requested by a taskbaroid.
For a single column taskbar, the width would be fixed and height allocation could be requested.
But a rows and columns taskbar would either need to fix both dimensions, giving little flexibility for taskbaroids, or arbitrate between multiple taskbaroids sharing the same column or row.

Taskbaroids being able to request more space is even more important, if we take grouping into account. When a single taskbaroid is managing a stack of windows (of a single application), it might need to display more information.