Tom Chance discusses the developments happening in KDE 4 on Newsforge. He looks at the Appeal group which brings artists and usability experts together with developers at the earliest stages of development, the context linking platform Tenor and the ideas coming together for the KDE 4 desktop Plasma. He also looks at RuDI, a library which would help ISVs integrate with KDE. "All of these innovations, if completed, will make KDE an even better desktop environment. When next year's aKademy rolls around, it will be interesting to see what kind of progress has been made."

tenor is supposed "collects, colates and stores metadata, full text indexes, linkages and contextual relationships between information on the desktop."

while this is surely a very very cool and exciting feature, I would like to raise some potential issues that might occur when adding it.

possible issues that come up in my mind that should be addressed include:
1. nfs friendliness.
2. limited file indexing.

1. most linux installations distribute home directory's over nfs. while this will not be a safe way of distributing home directory's until nfs4 has been released it has become common practice to distribute home directory's this way, and it probably also is the only available for now. (perhaps openafs or coda would work, don't know) I personally can forsee a great problem with network traffic when all those clients go on indexing on a nfs share. In this case it might be nicer to let the server index the files instead, and have the server monitor for changes as well. this would safe a lot of traffic. and the server would also be able to do it much faster.

2. I personally don't think it is a good idea to go and index the entire harddisk. there are many files the user would simple never search for like files in /etc or /usr

the first thing that would probably come to mind to only index the users home directory, but this has a disadvantage. I for example keep many files in /mnt/share. this is a readonly nfs share that contains files that are often used by everyone, but that are not allowed to be changed. (templates for example)

having every user index both his home and /mnt/share would probably be a waste of discspace. because the loss of discspace would increase with every user that is added to the system. now discspace itself might not be that much of a problem. but backuping large amounts of data surely IS an issue.

the most clean way of doing it in my opinion would probably be to:
1. have the server index shares like /mnt/share in a separate file that can be read (but not written) by all users. (in case of a desktop pc the client is also the server)
2. have a second file with all the home dir metadata stored in the users home directory. this file would in the best case also be written by the server to reduce network traffic overhead.

the user would then include both files and have full searching ability in all the files that are usefull to him.

No, "C:" refers to the third used drive and its files. It seems you never had the priviledge to use one of ms grandious products... ;-)
ok, i'll give you a free introduction: C: is /dev/sda for us, D: is /dev/sdb for us and so on. But A: and B: is /dev/fda. You have multiple /'s, one for each drive, e.g. you have to know on which drive and which partition (and which host, when using nfs) the files are, only the path gets you nowhere.
Confused? Well, you got ms business plan: Success by obscurity.

That is not correct. /dev/sda is the first initialized device that used the scsi subsystem, sdb is the other and so on. C: is the first primary partition on the master of the first ide channel. D: can be the second primary partition on the first drive or it could be the first partition on the first ide channel slave drive.

The drive letters C: D: etc are a major pain in the neck because of how it does partition names. The letters are assigned by primary partition first on master then slave across all ide channels and then it is gees by the extended partitions in the same order.

> Systems ignore /home and that is where users
> should put their stuff.

I don't think Tenor should work that way. I've some root folders (e.g. /multimedia) where I keep stuff shared by everyone on the computer.
Of course, I could just move all that crap into /home, but it'd be quite messy.

I guess it'd make more sense to push distros into presenting an user-friendly directory tree.

>I've some root folders (e.g. /multimedia) where I keep stuff shared by
>everyone on the computer. I could just move all that crap into /home,

Or perhaps make a symlink in the home directories? And as a added benefit having ~/multimedia, keep the users in their home directory. Making it less likely they get lost in the "complex" filesystem layout(A real problem according to some).

well, this is an idea, but it will cause double indexing.
since every user is going to store the metadata of /multimedia
(unless metadata gathering is done by a system wide daemon or something like that of course)

This seems to be the logical solution to me, and how I've always run my computer. I have /usr/local/music and /usr/local/movies, and have symlinks from my home directory (and the other users who may need them). So when guest users log in, they can access all the multimedia stuff, and I can have /usr/local/ as a separate partition from /home, which mostly stores personal configuration files and stuff.

This is thousands less complex to an end user when compared to any of the *nix which might have /usr /usr/local, and /opt to store programs they might want to run on the desktop. /etc to store settings for all users (whereas on windows, /docs and settings/all users has it). /bin /tmp /var /lost+found /boot etc etc..

If you are going to say that /home should segregate the users from the system then you are wrong. because users must be able to navigate through /usr, /usr/local, and /opt just to find a program and depending on the system and program combination depends on where it is installed. Until there is ONE place to find programs for users, the unix root directory is too complex.

You also have to realize that being user friendly doesn't only mean service end users who are too idiotic to use a pc. It is to make it easier for local administrators to install drivers, configure the video card options in xfree, etc etc.. Navigating all the spagetti for standard driver and program management is a paint in the ass with the current model. Nothing is labeled intuitively, and it is spread out all over the root directory. That is NOT user friendly. And it isn't administrator friendly. That is the point..

Now, to break the traditions and change it? I don't think it is possible. But the point is that it isn't off the wall to suggest such a thing. It is very appropriate. And anybody who says it is not is a hypocrite (like you)

"At the time Tenor is shipped, file systems should be able to do that work, so Tenor could just use those features directly, instead of using the software backend."

I disagree with you on this one. you see, many metadata is stored in things like mp3tags or headers of files. and a filesystem will never be able let you search through such metadata. the only way to do this is by gathering the data and then index it.

while the filesystem metadata searching facility is a great thing, I guess it will have to coexist with a indexing engine for a very very long time.

There is a lot bunch of distros for every taste and I am all for it. I just feel that desktop-oriented distros should make the directory tree more intuitive.

By the way, there is no "current file system hiarchy". In fact, some distros are starting using /media, instead of /mnt and there are lots and lots of little things like distros putting KDE under /usr, others under /usr/local, or even under /opt. "Current file system hiarchy" doesn't exist.

We will see Tenor, have a look at Kat in order to guess what it will be capable of, and it will not be shiny and all perfect, but an interesting thing with happy and not so happy users, the later stopping to use it.

That's how it's going to be. :-)

I personally as a KDE apps only user, want to see KDE 4.1 with the first apps picking it up for real.

BTW: What you're discussing here is not really Tenor (or better: the interesting part of Tenor, the Context Linkage Engine), it's about Kat [1]
(indexing, full text searching, etc.). But anyway, ATM it looks like Kat and Tenor will work together.

I suspect in order to do that, Opera would have to be designed to make use of Tenor. I don't think it will automatically be able to pull information from every application. Does Opera have a plugin architecture of some sort? I suppose it'd be conceivable to write some sort of a plugin that interacts with Tenor. Otherwise, I wouldn't get my hopes up.

Sounds like they are copying Apple. They have really come a long way, seriously; I mean that as a compliment. Not the direction I was looking to see - one of the reasons I switched to Linux. My question is how much will this up the system requirements to run KDE? One of the big advantages of Linux and BSDs is lower system requirements as compared to Vista. They may not be so far apart if these features are implemented.

Pretty amazing programming to go down in system requirements for the same functions. KDE programmers must be either much better than most other programmers or not having an interest in hardware sales really helps program efficiency.

>>Pretty amazing programming to go down in system requirements for the same functions.

Why, that is called optimizing :)

>>KDE programmers must be either much better than most other programmers
Or they have better tools :o)

>> or not having an interest in hardware sales really helps program efficiency.
among other reasons.

But you probably know that you can implement 1 function in very many ways, from very slick and small, to very bloated. No-one creates functions with very small footprints the first time, but while optimizing things in a later state, one could end up using less memory footprint for the same function by implementing it in a better way..

Well I don't know what Kde developers are doing, but I hope they are doing something wonderful. I hope that Kicker will be totally rethought like somebody promised in his blog. I guess it was somebody of those plasma developers.

Windows panel look should be changed somehow, apple panel looks little weird. something between or whole new approach(like BeOS) would be awesome. Menu standards from free-desktop.org could be integrated thought I hope that something better will be invented as gnome menus are not going to be anygood in new kde.

You know, we are in 2005, I think it's already time we can build programs that are toolkit independent.
Imagine you writting a app in any language, linking it to RuDi that just make it look and feel like the current desktop.

I've always dreamed about some kind of interface wrapper using XML to describe the interface and the connections between widgets and functions/methods. I know it's not trivial, but I have faith on open source developers skills :)

Actually, i wrote one of those interface wrappers in Java because i got sick of adding listeners and crap to every friggin component and then having to add the bounds checking and so forth, and as you said, it was not trivial.

I think it would be cool to get a toolkit independant language to describe the lyaout and behaviour of widgets/components, so that any toolkit can use it. ( of course this has probably been done. :) )

Please, just eliminate all the clutter in Konqueror and other programs. Toolbars are meant for MOST FREQUENTLY USED FUNCTIONS BY GENERAL USERS, note I said GENERAL, not computer whizzes which hack on KDE. Trim those context menus. Elimante all those options which are only used by 1% of people from the visible places, even well made and organized options confuse if in large numbers. Take some hints from GNOME. Get a HIG that everyone can understand and that covers everything, KDE's HIG is almost too old to be useful and certainly too shallow to make KDE more consistent. And please, get KDE some better marketing and fundraising efforts.

we don't need KDE4 for this, much of this will already be done in KDE 3.5. KDE4 is about big changes to the underlying framework, not about some small interface changes (not saying those won't happen, just they are not the focus of KDE4).

I strongly disagree. It's popular myth that the extra options, functions, and configurability of KDE reduces usability. In a 2003 usability report (Sorry, the page with the article is no longer available. The dead link can still be found on Wikipedia's page on KDE.) comparing KDE to Windows XP, users were quickly able to identify functions and perform comparative tasks. Usability was found to be about the same.

I remember the old Galeon web browser in GNOME and its "cracked up" interface with a million functions and features. It was a major attraction to many of my customers and was a reason so many of them chose GNOME. Developers all agreed that users don't want the mess, and they stripped it down until it was less useful than the Mozilla engine it was based on. Unfortunately, my customers all agreed that they liked the features and functions, and most of them refused to upgrade from Red Hat 8.0 for years. Many of them came back to my shop asking for SuSE 10.0, choosing the KDE desktop and Konqueror browser.

Even grandma's and grandpa's are plenty smart enough to identify the buttons and navigate around. I consider myself quite the computer expert, but even I often find myself simply not using features that have moved inside of submenus.

Don't insult users and developers by saying some of the features are "used by 1%." "General users" includes computer whizzes, grandma and grandpa, Mr. Businessman, Gamer-Kid, and all other groups. Just as there is no such thing as an average person, there is no such thing as a General User. In the computer service business, I often see technicians who feel like they need to save computer-illiterate users from themselves. The truth as I have seen it is that so many of my customers, even those who can't figure out digital cable or satellite receivers, are really quite good at figuring out what they want a computer to do -if- the options are there for them. People aren't computer illiterate; software is simply refusing to communicate with people.

And telling KDE to take some hints from GNOME is also insulting. KDE and GNOME cooperate and interact quite well, offering hints, code, standards, and media to eachother. As for KDE's marketing and fundraising, I understand that your comment is almost two years old, but even considering that, KDE's community saturation has been phenomenal, especially considering its young age. KDE has been well managed. I don't know what made you think that KDE needed help in that area.