129

The motivation for this idea came from the fact that curently, when applications are minimized, you cannot do anything with them. It should therefore be possible to interact with minimized applications somehow.

The idea is the following:

• Let every KDE application optionally register a plasmoid that "it belongs to". Amarok would for example have a slightly modified "PlayWolf" plasmoid, and KMail would have some kind of custom-made plasmoid connected to it.
  
• When one of the applications are minimized, they go down to the task bar as usual.
  
• However, when you hover the mouse over them, instead of displaying an out-of-date window preview, you should instead see the plasmoid connected to the application, as shown in the really ugly mockup below.
  
• It should then be possible to drag out the task manager entry on to the desktop, and the specified Plasmoid should appear where you drag the taskbar entry to, with a small "restore" button beside it that restores the application. At this point, the application should not appear in the task bar.
  
• You should of coruse be able to drag back the plasmoid to the task bar and the entry should reappear there.
  

The implementation of this idea could simply happen by modifying the Task Manager to detect applications with registered plasmoids and "application plasmoids" that are on the desktop, and by creating a new container plasmoid that can contain another plasmoid plus additional window handle information.

It would be a neat extra if the application itself didn't have to set up a communications system, and that there would be a special communications protocol that the plasmoid and application could use.

See also brainstorm.php?mode=idea&i=64283#anchormain

In that post the idea is more that the plasmoid would appear instead of the task-bar button. This kind of idea seems to be gaining a foothold in users imaginations

The idea you linked to seems to be very similar to what's being implemented in Windows 7. Also, as many have written comments about there, it seems that the spacebar typically isn't big enough to make plasmoids fit into individual application entries. It would also be more of a technical hassle to make the plasmoid stay even if the application connected to it isn't running, or to make the plasmoid interface work when multiple instances of the same application are running.

I personally find my idea to be more sustainable... Just my opinion of course.

This isn't exactly the same as windows 7. Windows 7 is more of a taskbar preview with the possibility for some embedded controls, not really a full mini-application like plasma has.

I think that "some embedded controls" might actually be a better approach, since it might be delivered in a way that was both desktop-agnostic and representation agnostic.

So the app (here amarok) advertises the cotrols that can be used with it: a volume slider, progress slider, skip forwards, backwards etc. These cotrols could be displayed appropriately by the desktop environment whether or not it is KDE and whether or not it uses a taskbar.

I think that "some embedded controls" might actually be a better approach, since it might be delivered in a way that was both desktop-agnostic and representation agnostic.

That'd mean creating a semantic remote widget toolkit, which I doubt would be any easier to specify than a regular remote widget toolkit.
It'd also be hard for application writers to create innovative solutions, since they'd have to go get the spec expanded and then wait until both KDE and Gnome got updated to support it.
In the end there'd be client-side scripting added and we'd just end up at square 1, having a separate little application communicating with the proper application.
In that case you might as well specify a cross-environment API for writing desktop widgets and skip the intermediate step. But that's not likely to happen, since it's a ton of work for little gain. Look at XUL, nobody bothered making an independent implementation of that.

Using plasmoids gets you the most functionality for the least cost, since a lot infrastructure is already in place.

I agree, Plasmoids would be the way to go. That way, every app can come with an optional Plasmoid. Then Kwin can check if an app has a Plasmoid function, make a request to Plasma to check if the Plasmoid is availabla and show it at specific co-ordinates.

Would be a cool add-on for KDE. However, it takes some work I am afraid. E.g., Plasmoids should be able to cover Windows, something they cannot do at the moment if I am not mistaken.

^ a solution to that problem would be that the plasmoid isn't created on the desktop itself, but instead in the same container that window previews now are shown in (it can be adapted, right?)

That would also make the feature potentially "Task Manager" agnostic, so that it could be made to work work in other task management implementations such as STasks or Daisy with little effort.

maninalift wrote:I think that "some embedded controls" might actually be a better approach, since it might be delivered in a way that was both desktop-agnostic and representation agnostic.

There is already a separate idea about that.

If I was being antagonistic and narrow in my vision I'd just say

"...hey I really like the mini-players (windows media player and iTunes) that sit in the windows task-bar and act as the task-bar button while allowing me to control the app without restoring it. Can I get that with KDE?" (And of course there are 2 plasmoids for amarok... but they don't appear to be very widely used yet.)

But because we want to look beyond we also ask:
"how can the idea (of a mini-player) be extended to other applications and what else could it be used for?" So for example the "mini-player" can be used as:
- a launcher or as an "open new" button
- a progress (or other status information) indicator
- a "show and switch to open documents / windows / tabs" function
- a browse history / playlist navigator

Are there other compelling use cases that people have in mind?

So given the above comment, this could actually be application-independent:

KGet and KTorrent could show progress (with controls to pause, stop or resume downloads);
Konqueror could show small, top-right previews of open tabs, each with a forward, back and close button;
Dragon, Juk, KsCD, Amarok etc. could show pause/play, stop, back, forward, volume and progress stuff (and in the case of Dragon, a preview of the video as it's playing as well);
K3B could show progress of ripping/burning CDs;
Kopete could show the last messages from all the contacts that have open windows;
KMail can show a preview of the open message, as well as who it's from, with forward and back buttons to go to the next/previous messages and a button to delete the message (and possibly a way to navigate to the next and previous folders);
KOrganizer can show not-completed to-does and upcoming events;
KOffice apps could show a small preview of the document (without the rest of the chrome of the window) and possibly open, save and close buttons (obviously, this isn't MY idea... maybe more appropriate interactions here);
Kate/KWrite would look similar to KOffice applications - a preview with open, save and close buttons;
etc. etc.


This could give KDE (yet another) one-up above all other desktops, including Windows - where all applications have similar interactions available in their taskbar entries which, while not replacing the full application, can make interacting with them from the taskbar more powerful then the current right-click menu. Of course, that's a LOT of work, but...

Yes! That's on the money for me. There are many simple tasks that currently require you to switch to an application and really shouldn't. The approach expecially has merit for small displays so the idea might fit well with the growing netbook focus.

It is a bit of work but not much compared with reimplementing KDE

+ Add 'stay visible' button in a corner

This way these plasmoids won't hide on mouse leave and will give a great benefit, when monitoring progress of another app, (or even watching a movie in dragon player (if you feet it comfortable ))

Hmm, what do you guys think about showing the plasmoid instead of the window preview even while the window is "un-minimized"? It might be good for quick access, but sometimes you just want to see the window preview. Leaving it as an option, perhaps?

Also, how about setting up a standard protocol that applications can use to communicate with their plasmoids? "Streaming" video from the dragon player application to the Plasmoid can be quite complicated, so it might be nice if there'd be a library for this, or some standard shared memory location.

@ Lukas: Do you think that this should replace the "drag minimized taskbar entry to create a plasmoid-on-desktop" feature I mentioned in my first post, or should both be possible?

What about of using XEmbed or some think. I know, it is not themable, but why not?

Window manager will register special windows with atoms wm_conntrols_mini and wm_controls_big. Application can get handle(XID) of them and put there own controls. Of course, this window should have fixed minimal and maximum size in specification, but can be different in different theme/WM's, so program must check this value. If we(program) don't have space in this window, we shouldn't use it.

Features:
- All X Window System application can use it
- WM decides where put this windows
- WM can don't create this windows, so application can puts this controls on main app window or in separate window
- We can but window with atom wm_controls_mini onto taskbar app element and wm_controls_big onto preview of window. We can also put wm_controls_mini onto window title and wm_controls_big to specify drawer on window title.
- It don't need dbus, but only X Window System with atoms support

What doesn't works:
- Themes
- Transparency
- Apps couldn't resize windows with specify flags

How client should behave. Like xscreen-saver screen savers. We get our window XID and go to parent element since we don't localize window with specify flag as first-level child. So all application window should have two created by WM windows to put big and small controls.