Newsforge: KDE 4 Promises Radical Changes to the Free Desktop
Thursday, 29 September 2005 | Jriddell
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:
I can't wait KDE4! - LaserRamonHG - 2005-09-29
Fooooooo!!!
Re: I can't wait KDE4! - chris - 2005-09-29
start coding today !
Re: I can't wait KDE4! - ac - 2005-10-02
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...
tenor - Mark Hannessen - 2005-09-29
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...)
Re: tenor - blacksheep - 2005-09-29
> 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.
Re: tenor - koos - 2005-09-29
"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.
Re: tenor - Anon the Cow - 2005-09-29
> 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.
Re: tenor - blacksheep - 2005-09-29
And your point being?
Re: tenor - anon - 2005-09-29
I'm not sure, but I think his point was that your idea is idiotic.
Re: tenor - pks - 2005-09-30
What if someone has 64 bit arch? Shouldn't it be /Linux/System64 then? ;)
Re: tenor - cm - 2005-09-30
I hope you meant C:\Linux\System64
Re: tenor - Andy - 2005-09-30
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.
Re: tenor - cm - 2005-10-01
No, I was referring to drive letters, but your obfuscation idea is even better. :)
Re: tenor - Lars - 2005-10-01
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.
Re: tenor - Kosh - 2005-10-02
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.
Re: tenor - blacksheep - 2005-09-29
> 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.
Re: tenor - Morty - 2005-09-29
>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).
Re: tenor - Mark Hannessen - 2005-09-30
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)
Re: tenor - James Richard Tyrer - 2005-09-30
> 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.
Re: tenor - KOffice Fan - 2005-10-01
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.
Re: tenor - fred - 2005-09-30
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.
Re: tenor - blacksheep - 2005-09-30
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.
Re: tenor - anon - 2005-10-03
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)
Re: tenor - cm - 2005-10-04
> paint in the ass I don't even want to imagine how that would feel. SCNR.
Re: tenor - Mark Hannessen - 2005-09-30
"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.
Re: tenor - Anonymous Coward - 2005-10-06
> 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?
Re: tenor - blacksheep - 2005-10-06
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.
Re: tenor - cm - 2005-10-07
> 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.
Re: tenor - Carewolf - 2005-09-29
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.
Re: tenor - Debian User - 2005-09-30
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
Re: tenor - Mario Fux - 2005-09-30
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
Question about Tenor... - K3V - 2005-09-29
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.
Re: Question about Tenor... - Dolio - 2005-09-30
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.
Re: Question about Tenor... - Arend jr. - 2005-09-30
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.
Just like Mac OS 10.4 - Benjamin Huot - 2005-10-01
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.
Re: Just like Mac OS 10.4 - rinse - 2005-10-02
What gives you the idea that the proposed features would ask higher system requirements?
Re: Just like Mac OS 10.4 - Benjamin Huot - 2005-10-02
Because the RAM requirements for OS X doubled when they added those features. Don't more processes take more memory?
Re: Just like Mac OS 10.4 - rinse - 2005-10-02
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
Re: Just like Mac OS 10.4 - Benjamin Huot - 2005-10-02
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.
Re: Just like Mac OS 10.4 - rinse - 2005-10-02
>>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..
Re: Just like Mac OS 10.4 - Benjamin Huot - 2005-10-02
Sounds great. Looking forward to KDE 4.0 then.
Getting better GUI - Antti - 2005-10-01
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.
Re: Getting better GUI - Mark Watson - 2005-10-01
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
Re: Getting better GUI - Anonymous Coward - 2005-10-02
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.
I hope RuDi gets in - Iuri Fiedoruk - 2005-10-01
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 :)
Re: I hope RuDi gets in - Glen - 2005-10-03
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. :) )
Oh ho - fennes - 2005-10-01
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.
My sole wish: Simplify KDE's Progface - Mike Torrent - 2005-10-03
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.
Re: My sole wish: Simplify KDE's Progface - superstoned - 2005-10-03
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).
Re: My sole wish: Simplify KDE's Progface - Benjamin Vander Jagt - 2007-06-08
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.
Some great ideas - Nicolas - 2005-10-09
On a page on gnome wiki I found some great ideas for the next version of gnome that could be implemented in kde too. The page (http://live.gnome.org/ThreePointZero) is more focused on new functionaly in the desktop than the GUI. I found this really interesting: "Application Structure: Applications in it current form scatter all over the system when being installed. Stuff gets in /bin, /sbin, /usr/share and wherever. When looking at an application as a single object, apps should be in a single file (much like an rpm, except that the files won't be distributed across the system). Applications can indicate what they are capable of in a capabilities.xml or something like that so that the system can index which apps can do what. This will also make it very simple to deactivate a app without deinstalling it. When apps are a single (archive) file, they can very easily be distributed, installed (simply put it in the apps dir using the "Application Manager"), deactivated (click on "deactivate" in the "Application Manager") of removed (you get the idea). Another good point on this is that this makes security much easier, you can simply allow or disallow rights to apps based on their codebase since all bins of an app are in or under 1 dir/archife. Image how easy it would be to limit bandwith to apps, to allow/deny internet access, to allow/deny users to use the app." Today installing or removing an application is a headache. This will simplify things. I think Mac has a similar approach on his desktop.