Does anyone know how to have a Task Manager that shows only non-minimized windows?

Backstory:

I've been running XFce for a while, and using it's IconBox as my Task Manager. Got quite attached to not having any text, as it meant I could have a lot of windows open at once. Across 15 workspaces. So that's like ... 400 windows open. Credits to Linux for being able to handle that and still let me work efficiently.

Anyways, came back to KDE to try out v4. And I know there's no IconBox, so I figured I'd just live with that. But, what I forgot is that when there is text next to each icon, there's a lot less space for windows. And I can't work efficiently with more than ~150 windows open, which is bugging me.

So, I figure there is a third option: most of the time, I minimize windows I'm not immediately concerned with. If I could just configure the Task Manager to only show non-minimized windows, I'd have plenty of space.

My ideal configuration would be:

1. non-minimized windows' Task Manager at top of screen
2. minimized windows' Task Manager at bottom of screen
3. Alt+Tab cycles through only non-minimized windows
4. Alternate Alt-Tab cycles through both minimized and non-minimized windows
5. a desktop widget which lists all minimized windows as icons, like Win 3.1 did or XFce can

I'm pretty sure #3, #4, and #5 aren't an option. And #2 is an easy checkmark. But #1 is what I'm not sure about.

If you use third-party task managers like smooth tasks or flexible tasks you can have an icon-only taskbar, but plasma developers refused to include this feature in the default taskbar. Assuming one of those are available from your distribution,

But why are you showing all tasks from all workspaces at the same time? Why don't you just set it to only show tasks from the current desktop? That should make things much more manageable. Also, do you really have 400 different applications running? If not, why not use grouping?

As for those options, 5 is already possible. You just need to put a task manager on the destkop. Anything you can do with a task manager in the panel you can also do with one on the desktop. That is one of the advantages of plasma, desktop widgets and panel widgets are the same thing. If you need them to be icons without text then use smooth tasks.

None of the rest are currently possible, although for 1 you can always ask the smooth tasks developer to add the option, explaining your rationale. You can submit 3 and 4 as brainstorm ideas in this forum if you want.

Good point on using SmoothTasks on the desktop. Hadn't thought of that, it works well enough - although I do like to have text - but underneath the icon, like in the file manager.

I'm not showing all windows from all workspaces. Just the active one. But even that can still be quite a lot of windows, and I hate multiple lines of tasks. Not 400 different applications, but 400 different windows. Because grouping is one of the worst design decisions ever (IMO) - I'll use a tabbed window manager if I wanted that.

It's my workstation, so we've got: one window per email, one window per bug-report, one window per file open, etc. etc. etc. I've doubt I've ever filled every since workspace, but I have had 3 fully saturated at the same time, plus a decent saturation on all the others. So probably about 160-170 windows...

Heh, it's probably a rare bug to trigger, but the XFce panel does some funny things when the IconBox is full. It goes over it's boundaries, and if you change to another workspace then come back, all the icons have disappeared until you close enough windows that it fits in it's boundaries again.

I'd like to agree with you that plasma containers are great because you can make a taskbar widget work on the desktop. But I can't agree with that. It sounds great in theory, but every plasmoid ends up having to be written to support all the different container styles - consider the Folder View; it looks totally different on the Desktop than it does on the Taskbar. That ends up creating two lines of UI code to maintain. It becomes a maintenance nightmare, placing the burden of testing every possible scenario on the widget developers. In the end, although the goal was to allow people to express creativity, it ends up limiting creativity - because either you support all the containers with N different branches, or you try for a much more limited design with generic functionality (the more common solution).

(I created something similar to this a while ago, and really shot myself in the foot, so I'm hoping Seigo et. al. have a better experience.)

I note SmoothTasks doesn't have an easy ability to distinguish between minimized windows if you are showing both. Bit of a nuisance, makes it difficult to distinguish one window from another when from the same application, which forces that evil grouping on me again.

I don't really want to suggest these as brainstorm ideas. It's all rather specialized desires, just because I'm trying to evolve my desktop experience - which AFAIK was the goal of Plasma, but I digress. If these were options available to end-users, it would just scare them. They might end up putting themselves in a scenario where they are unable to access any of their minimized applications!

Simply, I just though the idea that having open or "up" windows be listed on top of the screen, while closed or "down" windows listed on the bottom if the screen might work really well for my intuition. Make work even more efficient...

orbitrus wrote:I'd like to agree with you that plasma containers are great because you can make a taskbar widget work on the desktop. But I can't agree with that. It sounds great in theory, but every plasmoid ends up having to be written to support all the different container styles - consider the Folder View; it looks totally different on the Desktop than it does on the Taskbar. That ends up creating two lines of UI code to maintain. It becomes a maintenance nightmare, placing the burden of testing every possible scenario on the widget developers. In the end, although the goal was to allow people to express creativity, it ends up limiting creativity - because either you support all the containers with N different branches, or you try for a much more limited design with generic functionality (the more common solution).

First, folderview is the exception in this case. Almost all widgets behave identically in the panel and the desktop, only in some cases in the panel they take the form of icons that then pop-up the normal interface when clicked. So it is very little extra effort to get panel support unless you want to do something fancy like folderview does. This is the case, for instance, with the application launcher, calculator, character selector, kate session applet, and many others. The

Second, although I am not sure about folderview, even if the UI is different a lot of the underlying code would be shared, so it is not the same as having two entirely separate widgets.

TheBlackCat wrote:First, folderview is the exception in this case. Almost all widgets behave identically in the panel and the desktop, only in some cases in the panel they take the form of icons that then pop-up the normal interface when clicked. So it is very little extra effort to get panel support unless you want to do something fancy like folderview does. This is the case, for instance, with the application launcher, calculator, character selector, kate session applet, and many others.

That's a quarter of my point. The widget developers are forced to create a generic system. In the instance of calculator et al, the focus is in the container desktop - and the other system becomes the stepchild. It works well in the Panel + Desktop container metaphor, but as further metaphors are developed, and further containers are developped, they'll either have to support all of them, or do the "popup" approach on all of them. And odds are, the popup approach just won't work very well in a lot of designs.

The equivalent mentality, from the KDE 2 + 3 world, would have been to add a panel applet that can create a "popup desktop plasma container", and they could add whatever desktop plasmoids they wanted to in there. IMO, this is better - it lets the developer create a plasmoids where they can say "it's for the desktop". And it lets the user place a popup for the plasmoid on their panel. But it doesn't force the developer to include an alternative design for the panel, or have to support any other plasma container types. If they want to, they can... but they don't have to support it.

TheBlackCat wrote:Second, although I am not sure about folderview, even if the UI is different a lot of the underlying code would be shared, so it is not the same as having two entirely separate widgets.

You're right - UI code can be shared among the different views. And it's easier to refactor when you share code between the different views in the same binary. But there's nothing wrong with using libraries to share code. It's just a bit more work.

----------

Anyways, I've gone off-topic. I don't want to turn this into a debate over the merits of Plasma; suffice to say that, having done this before, and having gone done this road, I'm not convinced it's as good of an idea as the Plasma team thinks it is. But I always used to love KDE - well, Amarok, KHTML, KOffice, and KMail at least - and I'm hoping my misgivings are wrong. And, if I'm right, at least GNOME is going nowhere fast.

@Mods: That's a joke regarding GNOME's ABI stability, not a DE flame.

orbitrus wrote:That's a quarter of my point. The widget developers are forced to create a generic system. In the instance of calculator et al, the focus is in the container desktop - and the other system becomes the stepchild.

You say that it as though it were a bad thing, but to me it refutes your whole argument. Developers can focus all their attention on the containment that interests them, but as a bonus the widget can be used in other containments for free. It may not be as good as it would be if it were designed specifically for that containment, but even at worst it is no worse than having no applet at all for that containment, and most likely it will be at least marginally better than not having any such applet.

So to put it another way, if developers only want to develop for a particular containment, they can do so. Even at worst the widget will be useless in other containments, in which case neither the developer nor the users are any worse off than they would be if the widget was forced to be used in a particular containment. However, it is likely that a widget designed specifically for one containment will at least have some slight usefulness in at least one other containment, in which case we are better off even though the developer did not even think about other containments.

orbitrus wrote:It works well in the Panel + Desktop container metaphor, but as further metaphors are developed, and further containers are developped, they'll either have to support all of them, or do the "popup" approach on all of them. And odds are, the popup approach just won't work very well in a lot of designs.

First, it works well in the desktop, panel, grouping panel, grouping desktop, netbook, mobile, screensaver, and likely in the kparts as well. So despite the fact that almost all of those containments were not even imagined when the widget was designed, it works very well in all of them. It works so well, in fact, that the calculator is probably the widget most used in videos demonstrating of the mobile interface. If this cross-containment capability was not available, separate widgets would be needed for each of these containments.

Second, the question is not whether it will work well in a given situation, the question is whether it will work better than no applet at all. We really have two situations:

First, no developer cares about making that widget for that containment. In plasma, this means people have to make do with what was developed for another containment. In other situations, this means people would not have a widget at all for that containment.

Second, someone does care about having the widget in that containment. In plasma, they would have a lot of the work already done for them, they would just need to tweak some stuff. In other situations, they would need to write a whole knew widget from scratch.

orbitrus wrote:The equivalent mentality, from the KDE 2 + 3 world, would have been to add a panel applet that can create a "popup desktop plasma container", and they could add whatever desktop plasmoids they wanted to in there.

That is possible in plasma as well, we just need someone to make such a containment. In fact it may already exist.

orbitrus wrote:IMO, this is better - it lets the developer create a plasmoids where they can say "it's for the desktop". And it lets the user place a popup for the plasmoid on their panel. But it doesn't force the developer to include an alternative design for the panel, or have to support any other plasma container types.

No one is forced to do that with plasma, either. No one has to include an alternative design for the panel, in fact there are lots of widgets that do not. Quickaccess, quicklaunch, most clocks, most task managers, and the system tray are all examples of widgets that are the same on the desktop and panel. Many scripted widgets don't, either.

orbitrus wrote:If they want to, they can... but they don't have to support it.

No, they can't. They would have to develop one widget for the desktop, and a completely separate widget for the panel. They would not be able to have two form-factors built into the same widget.

There is also something that plasma can do that this cannot: if you make the panel really big, many widgets will convert to their desktop form-factor. This, once again, is not a requirement, but it is something that is only possible if the panel and desktop widgets are the same thing (and it apparently is very easy to do).

orbitrus wrote:But there's nothing wrong with using libraries to share code. It's just a bit more work.

And a LOT harder to distribute. How could we distribute libraries through Get Hot New Stuff? It would need to integrate an entire package manager, which would not be feasible. It would make scripted widgets essentially impossible. One of the great advantages of plasma is that the widgets are self-contained, making it very easy to distribute them.

Hmm, interesting... I concede to your points.

While I still feel that specialized tools designed for a single environment are preferable when concerned with user interfaces, you have done an excellent job showing how the generic abilities of plasma do, in fact, reduce down to a specialized tool, should the developer choose to ignore alternative containments. This, of course, is the hallmark of any good generalization, and, as such, I must re-evaluate my opinions regarding plasma.

In addition, distribution was a portion of the system design I had not considered. In a ecosystem not as diverse as *nix et al, this would be a trivial matter... but, yet, in our chosen environment it is quite daunting. And ease of installation is an important part of the user experience. So, quite right - separate libraries would indeed be challenging to distribute.

Thank you for the corrections. I must examine where I had failed in my own attempts, and see what other paths I could have taken would have been more fruitful.

TheBlackCat wrote:None of the rest are currently possible, although for 1 you can always ask the smooth tasks developer to add the option, explaining your rationale.

Unfortunately, it wouldn't be that simple. SmoothTasks outsources what windows to show/hide to GroupManager from the TaskManager library. So it would have to be added to both. And AFAIK, SmoothTasks has some more pressing changes to TaskManager they'd like to see done.

Although this change is quite trivial ... just copy/paste lines 256:259 of groupmanager.cpp, and add a getter/setter for ShowOnlyNonMinized. From that point the changes to SmoothTasks are equally trivial - just ui connections from General.ui and applet.cpp.

I'll have to attach a patch to this thread once I verify the above actually works (always an important thing), in case anyone else is curious about trying a similar setup.

Yep, it works!

Got a nice little setup now, with my minimized windows as an iconbox on the bottom of my screen, and my open windows as a normal task manager on the top of my screen. I'll have to try this for a while and see if it's more efficient...

Anyways, I promised patches. Here they are:
http://pastebin.com/DtqhJXL9

I'm running Debian/Testing, which doesn't have KDE 4.5 yet, so keep in mind that the four patches in the above paste are against KDE 4.4.5 and the 2010-02-27 release of Smooth Tasks.

• groupmanager.cpp and groupmanager.h are from kdebase-workspace
• applet.cpp and general.ui are from smooth-tasks