This is in English because the original article is.

I just read this article comparing KDE's default apps to OS X's. The author has some points, but IMHO not all of them are valid. Let's see.

(To answer some questions sent to me by mail: I've used KDE since 1997, and KDE 3.x since it came out. I've used OS X since January 2005 and exclusively (at home) since January 2006.)

1. Managing user information

Users should get an address book entry, this should be used by default by games' highscore lists, office apps, mail clients and so on.

This is rather a moot point. IMHO. Most of the apps I've seen (KMail and Kontact, for example) already use the information that's in the passwd database. And any larger organization will have a LDAP addressbook anyway. Yes, nice to have, but not really critical.
If this information is used, however, it should be used carefully: Digikam tagging all pictures imported by me as taken by me would be wrong, because I also have pics in my collection that I did not take. Chat and online apps should not insert and broadcast your personal info by default because that would violate your privacy. He's right about KWord & Co, though.

2. Toolbars

Single toolbars for all applications, no side/bottom toolbars.

While the basic point is true, the screenshot comparison is very unfair. First, XCode has a menu bar at the top of the desktop that is not shown. Then, XCode does not include an embedded editor and 98% of the functions that are all available in one main window for KDevelop are only available in seperate windows in XCode. If you keep a file browser, Find dialog, CVS and Subversion integration, output console, compile log, breakpoints, and and and opened all the time in XCode (assuming it has those features) then your desktop will be just as crowded.
Admittedly, the default view could be changed. See next point.

3. Default views

Applications present simple default views. See above.

Agreed. Some work has been done here already.

4. Drag and drop

Unlike the promises that Windows had and the lackluster support in Linux OS X really does have drag and drop support.

After having used OS X for about a year (and forcing myself to use it as my main private system since January 2006, to get to know it better) I find that OS X's "drag and drop support" is only emphasized so much because it lacks everything else.

• Most apps lack sensible context menus.Makes sense, because by default OS X doesn't even support multiple mouse buttons. However, some apps again offer workarounds to this: (Dock, Safari) support "click and hold", some others support "command-click" (Finder), some others use even triple-click and other weird things.

• Most apps support only one way of doing something.In the PC world there is always the mouse way, the keyboard way and - often - the menu/toolbar way. This - of course - crowds menus and toolbars more than if the feature simply wasn't advertized.
• Personally, I hate being forced to move from keyboard to mouse all the time. For example, in KMail I could move around in my Inbox, copy and move messages to different folders, reply to mails, write new mails etc all with the keyboard. In Apple Mail, for moving mails around you have to use the mouse. This totally destroys your workflow.
• In OS X, you need to learn to lift your mouse up and move it around while holding the button down in case your desktop (the real one) isn't big enough to finish the drag&drop action. This is more stressful for your hands and wrists and hardly economical.

In my experience, OS X style drag and drop - especially with only one available mouse button - is easier to grasp for novices, but harder to efficiently work with for experienced users. No wonder most advanced Apple users buy third vendor multi-button mice. Please, Apple, wake up, get out of the 80s, and make a Mighty Mouse that has bluetooth and at least three buttons.

Finally, to eject media, I find it much more intuitive to use the eject button on the drive - which has been possible in Linux for at least a couple years, despite the "mount" paradigm - than to do this in software. However, many Apple drives don't even have an eject button, which makes this point moot. I wonder what you do when the OS refuses to eject the disk for some reason. Reboot?

5. Integration

This is kind of two-sided. I think here both projects can learn from each other.
I can do a lot of complex stuff in OS X that I can't do in KDE (by default), for example create multi-menu DVD structures by drag and drop and import my favorite slide shows from iPhoto.
However, I can't do a lot of simple things which KDE finds totally easy to do, like dragging a URL (or file) from Mail (KMail) into an existing Safari (Konq) window to have this instance of the app open it. I can't drag and drop text snippets into text input fields. I can't have application windows automatically arranged so they overlap least.

For heaven's sake, I can't even zoom an online video to the full browser windows's size (KDE's player can do that, Windows can do that, Quicktime can't). Or forwarding mails as attachments (Mail can't do that, but it's required for just about any "abuse" reporting service!)

Some added thought

Also, I think Apple overdid integration at some point. Consider iTunes and iPhoto. I don't like the fact that they basically reinvent the file manager. This forces you to learn a different interface to manage your files. It also kills the possibility to organize your files the way you want it. For example, I play in a band. I have a folder "Band" in my home folder. This folder contains "Originals", "Gigs", "Repertoire", "New" and so on. "Originals" contains MP3s of the songs we play. Repertoire and New contain one dir for each song, and in this directory, there are scores (PDF, Garageband, Lilypond, etc), lyrics, further MP3s, recordings, pictures and so on. In the "Gigs" folder there are pictures and video/audio recordings of performances, demo tapes of performances etc.

So, basically I have organized my files according to purpose, not file type. The seperation of iTunes / iPhoto / iMovie etc. forces me to seperate my files according to file type. I could theoretically reorganize everything (about 2000 files), then create "intelligent folders" for each and everything in every application (why are these folders not shared?) and then tag the files so they get sorted into the right folders.
Problem with that is: the tagging mechanism is not standardized. I can apply any number of free-form tags to photos. I can't do that with MP3s and PDFs, for example. Plus, these tags would probably get lost when synchronizing with our band's FTP server directory, which is shared by a dozen people. Directory information doesn't.

I'd really like to get feedback about how to do this organization "the Mac way". I'm really interested, since I bought my Mac for the music in the first place. But currently it lacks a non-database based MP3 player and a non-database based picture browser/viewer.

6. Planes

In OS X clicking on one window will bring every window in that application to the top.

This is two sided as well. For most of the time, when I'm working on servers or doing online development, I don't want all shell windows (or all browser windows) to come to the front when I activate one. OTOH, with toolbox windows like used in GIMP and OpenOffice, this would be very handy.

However, needing to change between Alt-Tab and Alt-"<" can get on your nerves when you're searching for the right window, have no virtual desktops available to order your apps, and have so many windows open that the Exposé won't let you tell the difference between a Finder window and iTunes (or any other window).

Another thing. I wish the window manager were a little more intelligent in placing windows. It's just as stupid as the Windows window manager, it places windows quasi-randomly (or where the app requested), not where there is room left. Especially for browser and shell windows this is paramount.

Also, the visible difference between focused and non-focused windows is far too small. This is partly because of the inconsistency in looks in OS X, some apps have a "brushed metal" look, some don't, some are striped like in OS X 10.1+, some aren't, for no particular reason.

Sheets and drawers

Some more added thought: Apple's ideas of extending the main window with sheets and drawers - modal application windows that use the same title bars and are half-transparent, as well as "things" you can pull out of the "side" of a window - are really good ideas for usability in theory. I wish they'd have done a better job of it though. Here are a few ideas for improvement:

• Please, don't forcibly overlap the main window with a "File save" sheet. Everybody looks back onto the document s?he is about to save when thinking of a proper file name for it. You can't do that if you can't move the "File save" window/sheet away from the main window.
• Better yet, don't make "File open/save" dialogs modal at all. There is no reason whatsoever why you should not be permitted to keep changing your document while thinking of a file name and navigating to the right folder.
• Shade the main window so it becomes obvious that it's not usable right now. But keep the contents readable! If a subwindow/sheet must be modal, blink or flash it once if users click on the inactive window behind it.

Thank you.

7. Application Folders

Yes, the idea in theory is good. From a user's perspective, it's not more difficult than double clicking on a RPM file, though. If the application is well prepared, both will install and uninstall with just the same ease.

The big difference is the amount of shared code. In OS X, apps simply ship with everything that they need. Linux apps usually import features from a dozen libraries and thus are far smaller in size*, require a lot less developer effort, however thus depend on these libraries. This is most often the reason why a RPM for Redhat 7.x won't install (properly) on e.g. SuSE 8.x. This can be solved by simply shipping all necessary libraries and doesn't need a change of the packaging format, however. Most commercial apps do that anyway and so don't have that problem in the first place.

(*Example: GIMP 2.2.10. SuSE 10 RPM: 10 MB, Gimp-App DMG: 71 MB)

However, bigger problems in OSX regarding application installation can't be solved (easily). For example, many apps don't come as an .app file, but as a .pkg file (Package). Then again, many come with an executable installer (e.g. VISE). For PKG based installations, there is no uninstall. Unless you buy external tools and use them before the installation. The app/installer can do anything to your system and there is no log file, neither does it tell you what gets installed where by default. This is especially cricital for system drivers or plugins, which cannot be inside .app files and thus must be installed via a package or an external installer.

Packaging systems like RPM have already solved this problem. They also have solved issues like network-mounted directories, automatically checking an installed application's files for consistency and/or manipulation, automatically solving dependancies to other apps, cleanly uninstalling an application, including any data or configuration files it may have created, and so on.
Packaging systems have also solved the problem of checking, verifying and applying patches, upgrades and also of automating all that for a set of machines. On OS X, every application has their own "online update" routine. This opens up a whole new set of potential security problems since all apps not only can, but actually do "phone home" all the time. With a packaging system, you have one application doing the whole upgrade thing and you're finished.

Strictly speaking it does not matter whether you have an .app or a .rpm, if the rest is sorted out correctly. Clicking on it (the assumed default user action) should do the "right thing" (which, most often, is install it, or directly start it).

8. Common Viewer

Apple includes an application called "Preview". In essence it does something very similar to Konqueror. It can open any file that I give it.

Well... yes, for "document" type formats (ie. PDF / Postscript / DVI / etc). Graphics files need a different kind of viewer with a bit of a different UI. I suppose one could join all that in one application, but IMHO it's not really necessary. But a seperate program for Postscript, PDF, DVI and other such files isn't, either.

I wish OS X's embedded browser viewer could zoom Postscript and PDF files automatically to fit the browser's window width.

9. Core apps

... when you click on Applications there are around only twenty application installed. Combined with twenty more in the Utilities Folder.

Let's see. SuSE, by default, ships with (I think) about 20 applications (visible in the KDE menu). At least, 20 user-centric applications. Let's see what gets installed by default:

• Openoffice 2.0 (Office applications menu)
• PDF, Fax, Postscript viewer
• Image viewer (Gwenview), Image editor (GIMP), image database (Digikam), scanner frontend
• Internet: Messenging (Kopete), Browser (Firefox/Konqueror), Kontact PIM
• Multimedia: Audio player (Amarok), Audio recorder (KRecord), CD burner (K3b), CD Ripper/Encoder (AudioCreator), CD Player, Video Player (Kaffeine)
• Games: about five
• System: about a dozen utilities like wifi management, Remote Desktop connection (and server) and YaST.

IMHO, that's not too much and except for two browsers, one of which doubles as file manager, there are no useless duplicates.

The reason some alternatives exist is that some features are only provided by these. KEdit, for example, has some features regarding right-to-left text and exotic character sets that haven't been ported to Kate yet. Also, for simple text editing it's about five times as fast as Kate. Juk and amaroK have some different target audiences (SuSE installs only amaroK by default) and so are both valid apps. By default, only Kopete is installed, which can do IRC as well as most common IM protocols (and sending SMS!).
The others ... well, you could just as well demand AdiumX, Fire, Proteus, etc. to cease development because iChat exists.

KAppfinder shouldn't be required. Agreed. That said, I have never used it since switching to SuSE. KGet needs to be integrated better, also agreed. Some of the available IOslaves, while technically nifty, also require a bit of work: you mentioned cdaudio-ioslave. I think the idea is good, but the practicality isn't - unless you disable direct opening of any encoded "pseudo-files" from within the ioslave. Otherwise people will try to play the MP3-files which are "on" the disk.

Just a couple words on Finder vs. Konqueror: My main gripe about Finder, was and still is, is that it wastes screen space. A lot. It could present the same information it does present, in a more compact way, and would still be useable the same way. Konqueror - as a file manager - is a lot better in this respect. It also has tenfold more features, even if you never use 90% of them. I do miss some of them in Finder.

I also miss a way of showing a quick slideshow (or browsing pictures manually, with large previews and properly sized full views. Gwenview - SuSE's default picture viewer - does a fine job here, and is very fast. In OS X I haven't yet found a sane non-database-based picture browser that has a decent speed.

Well, so far, so good. Any comments?