Nine things KDE should learn from Mac OS X

As i am learning to work in Mac OS X i will pick up your "tips". Hope they will help me in my work.)
Thanks.

And now that I have placed my opinion on the comments, time for me to comment on the article.

Users have an address book entry.
I completely agree with this, and your dissection of it. This is the kind of integration which I think KDE could use more of. I would consider giving an option to not use the address book though. Particularly for generic/kiosk computers, and people who are paranoid.

Single Toolbars
I somewhat agree with this one. Most applications should probably have a single toolbar layout by default. However, I am not an advocate of setting a strict limit on the number of buttons of that toolbar. Also, several applications (particularly Kate, Quanta, Krita (?), & KDevelop) are complicated enough that they justify multiple bars. This has more to do with what the goal of the applications are. For them, I would instead reccomend less. As far as the screenshots go, the one for KDevelop looks slightly exaggerated, I must say. You seem to have many more tabs activated than I do. This may also relate to your font settings.

Maybe it could be solved by adding "views" support to KDevelop?

Applications present simple default views
Once again, depends on the application. For an IDE, there really isn't much you can do to make a simple view. OSX tries it, but I find their interface for this task generally lacking compared to the "IDEAl" way. KDevelop's implementation of IDEA1 could use some tweaking, of course.

Drag And Drop
I agree wholeheartedly that KDE should find ways of integrating drag and drop onto the desktop. Some of the mac-isms you mention I find to be painful (CD to trash is eject?) but the overall idea is definitely worthwhile.

Integration
KDE has already been doing very well on integration. If you submit ideas for integration into bugzilla, I think we can look forward to more of the same.

The Window Manager has planes
Of all ideas, this one I dislike. Mostly because I don't always want to bring all of an application to the front. For instance, say that I am talking with a friend in Kopete... I don't want the buddy list popping up with the application, nor do I want all of the other chat windows to do the same. When I am monitoring a download or transfer in Konq, I don't want all of the other file dialogs or konq windows to pop up either.

It would make an interesting choice, but I think it should be applied on a case-by-case basis, if at all.

Application Folders
The concept, yes. The implementation, heavens no. it would be great to have an interface that functioned similarly to application folders, particularly if it were combined with the background processing applet being worked on at kde-artists. For the justification of this, please visit the autopackage.org usability vision

A Common Viewer
Yeh, Okular.

I've commented many times, even on some bug reports I think, of the wisdom of using decent sized icons with text underneath. It's what KMail and Kontact should be doing especially.

The addressbook as well. God yes! OS X's is well thought out in that area, and I don't know what that resource name address book is either.

1) Good Idea - I like
2-3) Need to ponder this some more.
4) Yup could definately be improved along with Cut and Paste.
5) Security aspects need to be watched carefully but other than that this is already a strong point of KDE that is only going to get stronger... right??? My favourite instance is the way Amarok uses K3B for its burning.
6) Yup agreed... The gimp recently added a hack to so that it behaves in this way. It has outright fixed the Gimps biggest usability problem.
7) I am not sure if the MacOSX way of doing this. I firmly believe that the package management approach has the potential to be easier for the user than this. At the moment all the tools I have used only suit power users. I have to ponder this some more.
Isn't that what konqueror essentually is ????
9) I kind of agree with this one. It would be nice if Kcoolstuff and kde-apps.org could be extended as a sort of online catalogue of apps that a user could choose to install. I know there are cultural issues with the way Linux distro's do things and also with security but it would be extremely cool to be able to browse the avaible KDE apps and install them with one or two clicks.

The amount of toolbars and toplevel menu entries in those applications is partly because of the KPart technology. In Quanta the following menu entries are standard (from KDE or KMDI) or they come from the editor part (Kate here):
File, Edit, View, Bookmarks, Tools, Window, Settings, Help

Our own entries are:
Project, Toolbars, DTD, Tags, Plugins.

I can imagine that we could get rid of Plugins as it could go to the Tools menu, but once you open the Tools menu you will see that there are lots of entries (which come from the editor).
Tags is also something that we might get rid of, at least in Quanta4 it will be configurable to see it or not.

But the problem is the KPart technology. It's not that easy (altough possible) to control what to appear and what not from a loaded KPart. Again for Quanta4 (and KDevelop4) I would like to find a solution to have a cleaner menu and toolbar.

Regarding the toolbars: the biggest toolbar is the Debug toolbar which should not be visible by default, unless you manually configured a debugger in your project.

About the side buttons (left/right/bottom): we need them . But the IDEAl UI is there to help with screen space. If you don't want them to be present always, they will disappear as soon as you click in the editor area.

The tabs for document are also part of the IDEAl mode. As KDevelop has a file list plugin it might be possible to get rid of the tabs if the user wants (in KDE4).

The user toolbars are a central feature (altough you seem to have them with text under icons, which is not the default) and the only thing I can see that might help the user is what I did for Quanta4: move them into a separate toolbar, so it can be undocked. And instead of using tabs it's possible to have a new "real" toolbar for each user toolbar. Well, this will increase the number of toolbars in the application for sure.

All in all, ideas are welcome how to make it saner *without* loosing functionality.

PS: If you don't want sidebars, choose another UI mode.

Are you going to write the support for all those things or somehow convince other people to do it for you? Or do you just expect us to be like "uuuuu, yeah, we should have that!!" and do it ourselves? In reality, you can't possibly expect KDE to learn anything from this, because there's nothing to learn. Things to implement, yes. Things to improve, yes. Things to learn, not so much, at least from my point of view.

I also notice that you haven't bothered or offered to code up examples for any of this stuff either, so at least you're realistic in managing the expectation of any of this getting done.