"Especially your latest blog entry gives me the impression of a populist (as in 'popular to those who have no idea about what you talk') superficial rant by someone who seems to have lost touch with the pace of KDE community's development."

He's made it abundantly clear in the past why he doesn't like the way Konqueror does things, the way KControl is organised and he's made it abundantly clear why users in a live environment have found these things difficult and he's explained it. If KDE to move into business, organisations and increase it's userbase these are things that need to be addressed. Which part of that was not clear?

I'm afraid you've lost touch with the KDE community, because the KDE community isn't going to attract organisations to using it and isn't going to attract new users and developers otherwise.

Matthias works in a *real* work environment - listen.

"You start trying please. You just can't consider it feasible to dumb down one of the most complex technical tool available to people today to be as easy to use as a phone."

No one's saying it is, but it's quite clear that we can do alot better than Konqueror and some of the things in KDE.

"Make me a slave of my computer's unchangeable behavior"

What makes you think that you would be a slave and things would be unchangeable? You got one word right in that sentence - me. That's what *you* think.

"It does not matter that even non-coding people could easily turn KDE into highly customized installations, perfectly adapted to the particularly needed workflow thanks to XMLGUI and Kiosk."

Since you replied to me in one comment about usability studies, have you done one or at least observed users in a live work environment?

"Then you go on with the file manager topic. As apparently everyone does"

There's a reason that *everyone* does, as he's explained.

"And you know what? Konqueror exactly empowers you to do exactly that, with profiles and the ability to link independent XMLGUI files to those profile."

Your arguments really are shown to be crap right there. There's a massive, massive, huge difference between empowering people to do something and actually doing it. Profiles simply do not cut it, because there is too much functionality that is different between file managing, web browsing etc. Empowering people in an application like a file manager or a web browser is a total cop-out, because you know it's wishy-washy crap. Either it's a file manager or it's not or it's a web browser or it's not. That doesn't mean that you don't have common components between each (what Konqueror is really good at), but you focus on one main thing and do it well. That is a central Unix/open source philosophy.

But those profiles have to be created, and even then there is functionality that is simply not common between different use cases. Do you need cookie and security settings in a file manager or vice versa? No, of course you bloody dont.

"Nobody hinders anyone to create highly dedicated profiles limiting Konqueror to just what is needed in a dedicated web browser, just what is needed in a dedicated file manager, just what is needed in a dedicated FTP client, just what is needed in a dedicated Commader clone, just like what is needed in whatever use case one can come up."

But all that is simply not being come up with because you simply cannot separate and add what you need from and to Konqueror. It's too much of an overarching application.

"say the issue is with the code while the actual issue is that everyone even including of the project itself (by the way of defaults) fail to make good use of the configuration possibilities."

Funny, funny, funny. It's all the users' fault! They're not using KDE properly! Please do get your head out of your arse. If people are failing to make good use of the configuration possibilities continuously, then that should at least tell you something is wrong. And just how much *configuring* should an average person do exactly?

If you have to configure something too much then it simply isn't usable.

"Regarding those I consider the call for "hot coding sessions" to be misled and just resulting in unnecessarily redundant coding which could be better used within KDE where the actual shortcommings are."

Errr, those are shortcomings.

"I call for better documentation, for better user, sysadmin and distro creator documentation as well as better dox within KDE code."

Document what exactly? From what you've written you don't document anything other than "Configure it to do what you want.", "You can configure x from here, and also from here as well, oh and also from here.", "You need to go through several levels of dross to configure this, but if you don't want the dross you can configure it" or "You can edit this file here...."

"I call for better documentation, for better user, sysadmin and distro creator documentation as well as better dox within KDE code."

Yer. Absolutely wonderful documentation that would make for a sys admin. You do realise that a sys admin needs pretty clear documentation, don't you? And you don't cop-out with the 'distro creator' stuff because KDE cannot lump things on to the shoulders of distributors. That tac has clearly failed because you end up getting something that isn't integrated, doesn't work well together and ends up not being KDE at all. What Matthias has described is KDE's fault in its own back yard, and no one can solve it apart from KDE.

>If Konqueror gains focus then KDE as a whole gains features, simply because more users will use the dedicated applications.

Totally agree. I think there should be more focus on perfecting the bread&butter functions of Konqueror File Manager (ie. managing files ;). For example, you can't cut, copy, paste, trash and delete in the tree view using the keyboard and you can't rename folders using the mouse:http://bugs.kde.org/show_bug.cgi?id=80584

You also can't paste anything into the Home Folder by right-clicking on its icon because apparently the Home Folder is not a folder, but a link.

Here's a solution:
Konqueror should be modified to show the Root Folder sidebar by default. When the user first opens Konqueror, their home folder should be selected and expanded. The only folders visible should be /, /home, and /home/username. Everything else should be hidden and expandable if the user clicks on the Show system folders tick. Conversely, there should also be a Hide system folders tick when the system folders are expanded. The appearance of the ticks should be configurable by right clicking and from Konqueror's main configuration.

All the actions that can be performed on a folder in the right-side panel should also be performable on a folder in the sidebar tree-view.

> Heck, if you really love it the way it is, why don't you join its
> development team?

Because I have enough projects to take care of? I can't join teams of every software pieace I use and like ;).

> I have yet to see a single KDE developer who uses Konqueror and not Konsole
> for simple file management tasks like copying files.

I do. Although I have to have normal mouse for that - touchpads etc. don't count. If I have to work with laptop without external mouse, I prefer keyboard as much as possible and therefore use Konsole mostly.

I have yet to find a graphical file manager that works as well as the console. Although there are some things in Konq that I find compelling and useful.

I dare someone to match the simplicity of this command in any graphical environment:

rm *~

or

ls *.bin, or *.jpg, or *.pl

or even

tar -zxf (first couple of letters) [tab][enter]

These are a few of the things I do regularly and quickly.

On the other hand being able to click on a *tar.gz file to browse it's contents is seriously slick, or previews of images, text files, etc. The most frustrating thing is the time it takes to get to the file I want.

There is a vast potential for improving KDE. Getting rid of a few toolbars or tidying up some dialogs ain't gonna cut it though. These are difficult problems, and the audience is tough.

Filter your view using the dirfilter plugin
Select all temp files and delete

Granted it does not beat rm *~ which is a single command, but I want to see someone come up with an easier way to do this in any graphical environment!!!

> ls *.bin, or *.jpg, or *.pl

Same thing here!! Type *.bin in the said directory under Konqueror or use the directory filter plugin. I definitely need to write some blurb about how to use the directory filter plugin as people seem not to use this useful plugin at all. Of course that is a shameless plugin on my part...

> tar -zxf (first couple of letters) [tab][enter]

Split the current view in Konqueror.
Browse into the archive and
Drag and drop the folder into the other view...

I know some of these require multiple steps in GUI, but it is just as simple to do in the GUI as they are on the command line. Now if you had given an example of piping results of one command to another, then... Just today I had to do

find . -name "*.ui" | grep -v -e Base

which is not easy to do in GUI, but then again every tool has its own purpose...

WHY NOT USE THE KONQUEROR ADDRESS AREA TO TYPE IN COMMANDS EXACTLY LIKE KONSOLE.
LIKE LS *.JPG, TAR ZXVF, ZIP, UNZIP ETC ?

that way onsole is embedded in the address bar, and you can do everything in konqueror. those commands can also be configured to open the output in another tab of konqueror instead of present tab for tar etc.

or when one does tar zxvf files.tar.gz * another pane of konqueror shows caption as 'adding files to files.tar.gz'

if we keep the commands common to konsole and konqueror then what ever can be done in konsole can be done in konqueror too.

For those that believe Gnome philosophy is helping them... take a look at their desktop percentage as a whole. Their share of the Linux/BSD desktop market is actually SHRINKING. XFCE is taking market share from them because its easy to out-simplify the simply desktop

Yes, power users want the features and newbies want something as simple as Firefox. This should be easy to do with multiple configurations of Konqueror.

Note that to do this, a design error needs to be fixed. The View Profiles: "filemanagement" & "webbrowsing" are part of the code -- you can NOT change the default Profile for "File" or "Web" even by hand editing a configuration file. This is a bug and it needs to be fixed.

Hmmm... it seems that Pennington, a GTK+/GNOME developer, (mostly) used GNOME examples of (allegedly) bad usability to make his point. Here it seems that Ettrich, a Qt/KDE developer, is using mostly KDE examples of (allegedly) bad usability to make his point.

So, each developer targeted his own desktop to make his point. That seems similar to me. :-)

Criticism of a project by one of its own members should be respected if the criticisms are meant to be constructive and lead to improvements. I understand Ettrich's blog comments to be constructive and to attempt to make KDE better for 4.0.

Whether or not you agree with his criticisms is a completely different matter, of course. That is where the debate over the content of the criticisms is important.

Decent down-to-Earth guy that Matthias Ettrich. He's said some things that needed saying there, and it's nice that he's 'actually seen' users using KDE in an environment to get work. Trust me, once you've done that things take on a different perspective.

Sure, I have seen the videos [http://primates.ximian.com/~pete/GUADEC/wms-guadec-2005.sxi], however the solution to that problem is a data-driven development process were design decisions can be taken based on feedback from actual usability testing. There are people doing that [http://www.openusability.org] and they actually help KDE to become better. That's hard work. Blog entries like this are entertaining but do little to fix any problem. KDE has had a mailinglist list for a long time were usability was supposed to be discussed and that was filled with armchair usability experts just like Matthias, it has done very little to make KDE better.

I totally sympathise Waldo, but it just seems to be very difficult to convince some developers of the need to see users out in a live environment or to convince them to listen a bit to users who have. They may seem like armchair usability people, and some are, but a lot aren't. You might say that the people who write the code decide, and you'd be right. But to write code to make usability better in KDE you need to have existing developers on your side, and a lot just don't seem to be.

Konqueror is a classic example. Many developers seem to be very, very confused about the difference between a kitchen-sink, swiss army knife Konqueror and the code re-use that Konqueror has between itself and different applications. That's what's needed - reuse of different components, not an all-in-one everything application.

It's nothing very difficult. They are things he's described there that you can solve within about a week, including talking time, if everyone pulls in the right direction.

Doing so on a grander scale. It is important to be aware that there are different kind of users, different kind of use cases for computers, and different user behavior and expectations in different regions and countries. KDE has always been listening to a couple kinds of users which are techno savy and/or motivated enough to report their issues directly to developers, to mailinglists or to bugzilla. Those users however doesn't give you the whole picture, nor does listening to users in your particular environment do so. This is the differentiation I do between (good) usability studies and (armchair usability observatios through) watching a small amount of users. Please note the talk about the study Waldo linked in his post, it takes most of this all into consideration.

It's suicide to listen to those mythical dumb users who aren't motivated enough to even know what KDE is or how to provide feedback, when you have REAL users and a REAL community right here and right now giving you feedback.

Alienating REAL users in the hopes of capturing a larger market share from the sheeples is just plain foolish for a project like KDE.

"You are dodging Waldo's point that it's usability studies what matter."

Err, that's what I said. You're totally dodging the issues in that post.

"Listening to a couple of users is not the same."

Did you read what I wrote? I didn't say listen, I said watch, and preferably listen as well. I doubt very much whether you've even listened to a couple of users with all the crap you've posted, and that's the point.

I think you're secretly hoping to ask for massive usability studies that will be difficult to undertake for most so they'll get bogged down, and then it can all go away. It won't. You can't just pluck usability studies out of the air.

Certainly, usability studies is the way to go, but there are a lot of things that can just be just implemented because it is common sense from a usability perspective. The first elementary step is just to remove, remove and remove. I think much of this falls in under that category.

The usability discussions in KDE goes nowhere, but the problem with them not primarily that there are "armchair" usability experts. That would have corrected itself if the discussions had any consequences for development. I think that you fail to realize that the real problem is of a political nature - it is the fact that the decisions are made by engineers with a different agenda than ordinary users. For just this reason comments like this probably what is needed the most - an opinion from someone that really has the power to influence. In a discussion that calls for change, it is common that the defender of status quo attempts to dissmiss the discussion, rather that face up to the problem posed. That is what you have chosen to do now, even if it rather implausibly means questioning Matthias' professional crediblity in usability issues.

As you can see, I whole-heartedly agree. The compromises made to Konqueror in trying to be a generic file-viewer (an acceptable extension of the web-browser idea in my opinion) and a file-manager have made it more awkward to use.

I also like the way you referred to Microsoft, I think they really hit on something with their "task-driven" interface (yes, even evil Micro$oft gets it right once in a while). I remember going over some stuff with my Dad. I asked him did he know how to copy a file (expecting him to reply Edit->Copy) and he pointed to the obvious "Copy File" item in the "File and Folder Actions" section of the side-pane.

KDE really has all the infrastructure to make this work. You could have an side-pane, with

[File/Folder] Actions
===================
Open
Open with program (pops up a dialog with all appropriate programs)
Rename
[finsh off with Actions taken from the actions submenu in the context menu]

Common Places
================
*My Home
*My Group (home://)
*My Devices (system:// or drives://)
*Audio CD Files (audiocd://) (be intelligent, and don't show if no audio CD?)

Of course, this all relies on being able to select a file. Personally, I think single click select, double-click open is the only way to go there, although there is an argument, in the file-manager only, to let the middle-click button open items (even folders) in their application / a new window. In the file-viewer (konqueror) it would make more sense to have it open items in a new tab of course.

One other thing I saw that looked good, and taken from the ideas for the NeXT file-manager via Thunar (http://thunar.xfce.org/wiki/ui:suggestion-20050320) is a series of bread-crumbs to work your way back. However instead of buttons have what appears to be a text-edit (though really a HTML pane) with each folder a hyperlink and a > icon between each item. For people who like to type in paths retain the clear button by the text-edit: the use-case then is a user hits the clear button, the bread-crumbs disappear, they type in a path, hit enter, and the path is changed to the bread-crumb hyperlinks as the location appears.

With regard to copy and paste, I think big copy and paste buttons on the toolbar should do the job.

I am a power user who happens to _like_ the integration of a web browser and file manager. The one thing I cannot stand about Windows/GNOME is that you can type a URL into the file manager, which at least on Windows is supposed to be one with the browser, and the application acts totally different than if you had started it in web browser mode.

I was also thoroughly pissed when I installed the new version of KDE and found that Konqueror was configured to used that obnoxious listbox-like Ark part for viewing archives, instead of a standard/modern icon view. I want to have a consistent interface when moving files around, whether inside or outside an archive.

The thing I like about Konqueror is the KParts. I like, for instance, that I can view a PDF file in the *same window* as a regular web page. That solves some of the window management issues discussed, for less windows to manage means less inefficiency & frustration, no?

I think Matthias is missing the trees for the forest. He sees the big picture of Konqueror being unusuable, but he forgets the simple ways in which it could be made more usable. On the topic of displaying sizes and permissions for pseudo-filesystems, so what? This could be solved with a simple patch that causes that information not to be displayed unless the ioslave provides it. This is how it should have worked to begin with. Or how about a sidepane that one can say is interactive and still maintain a straight face? And yet we are talking of forking Konqueror into two separate applications for such trivial causes? It seems the real problem is that Konqueror has not yet become a mature file manager, not that it is one with the web browser.

I understand that the new users see browsing and file management as two separate applications. This has not been solved with view profiles, however, simply because the current view profile implementation is highly defective. For instance, click on Settings->Load View Profile->Simple Browser. How much "simpler" is the simple browser? Not at all. Nothing happened, did it? The simpler XMLGUI file that is supposed to load, doesn't. How was this overlooked in the last two KDE releases? I am not trying to beat up on Konqueror, but we need to at least have features working before we can draw conclusions about their usability - no need to attack a straw man. The swiss army knife analogy was apt for this precise reason. If profiles for one worked the way they were supposed to, then it would be more like a single-blade knife that suddenly morphed into a screwdriver as needed.

>I was also thoroughly pissed when I installed the new version of KDE and found that Konqueror was configured to used that obnoxious listbox-like Ark part for viewing archives, instead of a standard/modern icon view. I want to have a consistent interface when moving files around, whether inside or outside an archive.<

Couldn't agree with you more!

Another pet peeve is when Konqueror opens up images or text files in EXTERNAL viewers. Totally lame and not integrated. It can't be rocket science to open text and images directly in the browser.

> Another pet peeve is when Konqueror opens up images or text files in EXTERNAL viewers. Totally lame and not integrated. It can't be rocket science to open text and images directly in the browser. <

Yes, I also alluded to this in my first post. I think the best way to handle this is to have a _global_ option of whether to open files in an embedded viewer or an external application, not for each individual mimetype.

What we need is real work on Konqueror as opposed to just KHTML. There are five-year-old Konqueror reports on bugzilla that still have not been addressed. For instance, http://bugs.kde.org/show_bug.cgi?id=3212 . I posted a patch that fixed this one, but it was completely ignored as are most.

There is a global setting for text type files for this, I don't have a recent KDE available at the moment. If you open open the properties for a text type file, and open the edit mimetype dialog. Under embedding tab in the left click action, you can set it to follow a acction for generic text files. I think this is set as default for most text filetypes, making it more or less default and you can at least set it "globally" for those. Not exactly what you want tho.

Personally I don't think a global setting for this are a good solution, as it a one-size-fits-all approach which does not really fit with the differences in workpattern concerning various filetypes. Having an easier way to rapidly set this would be a better solution. A simple list of all the different mimetypes where you could choose to embed or not embed, making it possible to customize this feature in a minute or two. Since you can never get defaults to satisfy most power users, it's better to make it easier for them. But not excluding having good default, and perhaps the defaults for embedding need a review.

What really bugs me with embedded previews are the lack of automatic zooming of pictures, the default for preview of a picture like a jpeg are 1:1 scaled. Rather useless when clicking on large pictures. The default should be fit to window, making the whole picture visible. I guess you can configure it, but it's about sane dafaults as I think most users will expect this.