-22

The basis for this idea comes from Mark Shuttleworth's blog: http://www.markshuttleworth.com/archives/333

Basically, the idea is to add an API that applications can use to set icons ("windicators") in the window border. These icons are intended to display some status information and may have click-menus to perform some action (change the status).

Examples would include IM status, file modified, or volume indicator.

Idea approved, although I for one really hope Shuttleworth and the rest over at Canonical changes their mind on this. In my opinion, it's a REALLY bad idea.

doesn't seem like a good idea...
more info: http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/

If this does get into 10.10, and apps actually use it, to maintain compatibility (so that the apps UI aren't disappearing in a void), KDE could do something like this

brainstorm.php#idea83171.

Thankfully they are proposing to use DBUS if this happens, so it seems KDE could respond to the apps requests its own way.

EDIT: and KDE runs on Windows, Haiku OS, MacOS X, and various other OS'es. The titlebar thing could affect portability...

Personally, I've got mixed feelings on this. We probably should support this for compatibility if Mark does get this implemented. There may be some use cases where it could be nice to have this kind of functionality. On the other hand, why put something in the titlebar that you could just as easily put in/beside the menu bar/status bar.

I expect that more people will vote No than Yes, and that's fine. I just wanted to throw this out there and see what people think.

I agree with you Airdrik but at least they are doing it with d-Bus, I've heard originally they planned to use client side decorations which would be even worse.

And I can see a couple of uses that could be useful. Volume for example (with pulse audio each app can have a separate volume level).

Anyway even if it's just to maintain compatibility we should do it.

Seems that Mark and others in Ubuntu team does not understand how bad idea that is.

The systray's point is that you have one place for notifications and very important functions.
And one of the most important features is that you can access to them from any virtual desktop or when having any other application running. And you still can manage to get them hided when not needed.

The point just is, the current system (even with needing somekind polishing) is much better than what is now suggested.

Since this is non-standard, and I can't see the KDE community picking this up (any more than they have the Ayatana notifications), if Canonical are still interested in windicators in KDE then THEY should handle it.

Then again, I don't see why this can't be implemented (by them) as a button that can be shifted around the titlebar. That way, if they DO move the titlebar buttons to the left and DO put windicators on the right, then at least people can decide to remove the windicators and opt for a more traditional button layout with relative ease.

Please, read this good summary of the Canonicals idea of Client Side Decorations (CSD)

http://blog.martin-graesslin.com/blog/2 ... corations/

I read that and totally agree that applications shouldn't draw their own decorations. The implementation I imagine for the windicators would be an api that the window managers present (via d-bus or similar) wherein the windows can ask the window manager to draw an icon in the designated windicator area (similar to how applications can ask the window manager to set the window title)

http://identi.ca/notice/32519686

Madman wrote:http://identi.ca/notice/32519686

It was already clear that CSD was not sure what Mark suggested, but it was the technology what would allow it. Still the custom buttons per application in windeco is not good at all. There are different problems like usability where functions are scattered around the UI in different way and not one similar way in every application.
It would be like you would have own icon set on every application or menubar would have own order in every application. Sometimes you can see a similar save icon as now, but usually it is something else, it could be like a tree or car icon. And save/open/save as.. entries would be scattered around different menus, sometimes in settings, view or edit.

Soon everyone should start noticing that single UI functions is better in most (all, if functions are such) cases. And there are already lots of great window managers what already are flexible. Like KWin what beats Metacity down very easily. You have custom set of button easily editable. And you can have windowses to go no decorations -mode when they go to fullscreen etc.

Example, I have used now over a year a UI what is almost exactly what is just now suggested by Canonical for netbooks and other widescreens. Only because I use powerfull technologies like Plasma and KWin what are designed to allow very powerfull UI's. Question just is if distributors what people use does not make them as default.

We all make mistakes and have problems to make others understand us. Such case was again with Mark, but there is still problems with his ideas what are not doing current situation better.

This is a really bad idea. Status bars are there for a reason. The irony of windicators is that they only show when an application is not minimized. I want to know my IM is connected when its not visible. The notification area does this. In an editor application there is often lots of information to display, the status bar does this well.

There are very few good examples on the blog post. "A trolley indicator to show if items are for purchase". Websites do this themselves, will we know need a W3C specification for e-commerce sites?

The need for vertical space only counts for netbooks. Netbooks make up a very small percentage of computers in use, and I sure don't care about status bars taking up vertical space on my desktop. Displays will only get bigger and saving ~20 pixels by designing this elaborate system is a serious waste of time.

Also I agree with Fri13's posts on this topic.