SEP
29
2005

Newsforge: KDE 4 Promises Radical Changes to the Free Desktop

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."

Comments

Fooooooo!!!


By LaserRamonHG at Thu, 2005/09/29 - 5:00am

start coding today !


By chris at Thu, 2005/09/29 - 5:00am

But as it seems, you'll have to wait 1 more year for it...

Or maybe the devs will think about the release schedule and aim a release 6 or 9 month after KDE 3.5...

I hope it gets out of the door before windows vista...


By ac at Sun, 2005/10/02 - 5:00am

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.

(and sorry for my bad english...)


By Mark Hannessen at Thu, 2005/09/29 - 5:00am

> 1. most linux installations distribute home directory's over
> nfs. (...) In this case it might be nicer to let the server
> index the files instead (...)

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.

> 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 (...)

Distros should just put all that crap into a common directory called System or something. Then, you could just add it to the ignore list.


By blacksheep at Thu, 2005/09/29 - 5:00am

"Distros should just put all that crap into a common directory called System or something. Then, you could just add it to the ignore list."

Nonsense, it's the otherway around. Systems ignore /home and that is where users should put their stuff. And guess what, it already works that way for a long time.


By koos at Thu, 2005/09/29 - 5:00am

> Distros should just put all that
> crap into a common directory
> called System or something.
> Then, you could just add it to
> the ignore list.

OMG YEAH LETS BREAK THE STANDARD FILE HIEARCHY because it SUCKS!!!! Lets put all non-user files in a folder called Linux\system32. Great Idea!!! Will solve all problems.


By Anon the Cow at Thu, 2005/09/29 - 5:00am

And your point being?


By blacksheep at Thu, 2005/09/29 - 5:00am

I'm not sure, but I think his point was that your idea is idiotic.


By anon at Thu, 2005/09/29 - 5:00am

What if someone has 64 bit arch? Shouldn't it be /Linux/System64 then? ;)


By pks at Fri, 2005/09/30 - 5:00am

I hope you meant C:\Linux\System64


By cm at Fri, 2005/09/30 - 5:00am

You mean, like C:\Linux\System64, C++:\FreeBSD\System32, Java:\AIX\System64... sounds like hell to me. I'd rather stick to /usr, /opt and /home.


By Andy at Fri, 2005/09/30 - 5:00am

No, I was referring to drive letters, but your obfuscation idea is even better. :)


By cm at Sat, 2005/10/01 - 5:00am

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.


By Lars at Sat, 2005/10/01 - 5:00am

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.


By Kosh at Sun, 2005/10/02 - 5:00am

> 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.


By blacksheep at Thu, 2005/09/29 - 5:00am

>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).


By Morty at Thu, 2005/09/29 - 5:00am

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)


By Mark Hannessen at Fri, 2005/09/30 - 5:00am

> I've some root folders (e.g. /multimedia) where I keep stuff shared by
> everyone on the computer.

Actually, that should be: "/usr/local/multimedia"

And we are going to have to index "/usr/local" except that we need an ignore list.

OTOH, the idea of having each user have a link:

~/Files/User_Multimedia -> /usr/local/multimedia

seems like a good idea.


By James Richard Tyrer at Fri, 2005/09/30 - 5:00am

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.


By KOffice Fan at Sat, 2005/10/01 - 5:00am

User friendly? It is user friendly. Unless you mean user friendly like windows where you get no physical presentation of how the directory structure really is organised.

Hmm ... /home/my_user_account vs C:\Windows\Documents and Settings\my_user_account

No thanks, I like the directory structure just how it is.


By fred at Fri, 2005/09/30 - 5:00am

I don't consider the Windows tree user friendly either, so please don't put word on my mouth.

The MacOSX tree would be an example of what I consider a user friendly tree.


By blacksheep at Fri, 2005/09/30 - 5:00am

Wrong:

C:\Windows\Documents and Settings\my_user_account is not correct. it is actually....

C:\Documents and Settings\my_user_account Which would be equivilent to C:\home\My_user_account. Just a more descriptive name.

Now, you might say that "Documents and Settings" is a waste of time to type out. You may be right. But nobody actually types it out while using their windows box. That is why it is more user friendly.

Now, if it HAD been under C:\Windows then THAT would be a damn shame.. to mix the system files with the user files. But it isn't. In fact, a windows sytem has 4 directories:

C:\Windows (for system files)
C:\Program Files (for programs, not os provided system utils)
C:\Documents and Settings (equivilent to /home)
C:\temp

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.

my proposal:

/home
/usr/program name (for programs)
/system (to contain /var, /etc, /lost+found, /log, etc etc..)
/tmp
/mnt

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)


By anon at Mon, 2005/10/03 - 5:00am

> paint in the ass

I don't even want to imagine how that would feel.

SCNR.


By cm at Tue, 2005/10/04 - 5:00am

"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.


By Mark Hannessen at Fri, 2005/09/30 - 5:00am

> Distros should just put all that crap into a common directory called System or
> something. Then, you could just add it to the ignore list.

The hell they should.

Distros should keep on using the current file system hiarchy, and not piss off every knowledgeable unix user out there.

Do you actually *want* *nix users to abandon the system?

Are you on crack or something?


By Anonymous Coward at Thu, 2005/10/06 - 5:00am

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.


By blacksheep at Thu, 2005/10/06 - 5:00am

> 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.

I think the last thing we need is a *more* inconsistent file system hierarchy across distros. But this would be the result if your suggestion were implemented.

> By the way, there is no "current file system hiarchy".

Sure there is: http://www.pathname.com/fhs/ . Unfortunately interpretation and degree of compliance is not the same with all distros.

> some distros are starting using /media, instead of /mnt

/media is for removable media, /mnt is for temporarily mounted file systems. They're both in the standard, as is /opt.


By cm at Fri, 2005/10/07 - 5:00am

I thought tenor was dead. It was a great idea for KDE4 last year, but have died when faced with reality. I was surprised to see it brought up again in KDE4 expectations.


By carewolf at Thu, 2005/09/29 - 5:00am

Just as bad as spreading false hope is spreading false despair.

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.

Yours, Kay


By Debian User at Fri, 2005/09/30 - 5:00am

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 wish all a nice day and weekend.

[1] http://kat.sf.net


By Mario Fux at Fri, 2005/09/30 - 5:00am

I've been wondering this for a while now...

If you're running, say, Opera (or any non-KDE browser), will Tenor still be able to detect and keep track of where you got the image or whatever that you download?

I mean, if I were on Opera, and I downloaded an image, would Tenor be able to see that I got it from whatever site I got it from, or will it only support Konqueror?

Yes, I'm using Opera. :p But I like only having to open one app for all my mail, RSS, and Browsing needs.


By K3V at Thu, 2005/09/29 - 5:00am

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.


By Dolio at Fri, 2005/09/30 - 5:00am

Well, that would be part the part where RuDI comes in, I guess.

Opera would just subscribe to a RuDI service offering the indexing and KDE, providing the RuDI service, would take care of the rest.


By Arend jr. at Fri, 2005/09/30 - 5:00am

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.


By Benjamin Huot at Sat, 2005/10/01 - 5:00am

What gives you the idea that the proposed features would ask higher system requirements?


By rinse at Sun, 2005/10/02 - 5:00am

Because the RAM requirements for OS X doubled when they added those features. Don't more processes take more memory?


By Benjamin Huot at Sun, 2005/10/02 - 5:00am

Not necessarily. If you manage to reduce the memory requirements of other processes, you will end up with some extra memory that you can use for new features..

Rinse


By rinse at Sun, 2005/10/02 - 5:00am

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.


By Benjamin Huot at Sun, 2005/10/02 - 5:00am

>>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..


By rinse at Sun, 2005/10/02 - 5:00am

Sounds great. Looking forward to KDE 4.0 then.


By Benjamin Huot at Sun, 2005/10/02 - 5:00am

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.


By Antti at Sat, 2005/10/01 - 5:00am

It funny how many people don't like the KDE panel just because it is remotely like windows. If it works, then why should we worry that it is to similar to windows?

Anyway, I think KDE will reorganize the panel a little; making it more powerfull, etc.

Mark


By Mark Watson at Sat, 2005/10/01 - 5:00am

Rudi looks like adding yet-another desktop API for Linux. But hey - if we
can get everyone behind it, that's exactly what we need. Kudos for the great
idea.


By Anonymous Coward at Sun, 2005/10/02 - 5:00am

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 :)


By Iuri Fiedoruk at Sat, 2005/10/01 - 5:00am

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. :) )


By Glen at Mon, 2005/10/03 - 5:00am

Hope KDe 4 will also support tablet PCs. May be they are not succesful now buzt on the long run, tablet PCs tehcnology will be the future.


By fennes at Sat, 2005/10/01 - 5:00am

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.


By Mike Torrent at Mon, 2005/10/03 - 5:00am

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).


By superstoned at Mon, 2005/10/03 - 5:00am

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.


By Benjamin Vander Jagt at Fri, 2007/06/08 - 5:00am

Pages