The KDE Project today announced the immediate availability of KDE 3.1 beta1, the second development release of KDE 3.1, which follows 6 weeks after the release of KDE 3.1 alpha1, a significant feature upgrade for KDE 3. KDE 3.1, scheduled for final release in October 2002, will provide substantial improvements to the KDE desktop experience.
KDE 3.1 Beta 1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
KDE 3.0 to 3.1 will be a larger step than KDE 2.2 to KDE 3.0
IFAIK KDE 3 was mostly just a port to QT3
I would check it out but the odds of my getting it hacked onto my Mandrake 9.0 B3 system from CVS before the sun comes up are slim. I was going to check out the Keramik theme but I am using automake 1.6.3. and it “requires” 1.5. I could backdate my version of automake to 1.5 but even there is about a 95% chance it will still fail. There is an 8.2 RPM available but I think it failed with something like 34 dependencies.
So, to sort of wander off topic, I think that is the major problem that Desktop Linux currently faces. It has almost no backwards compatibility at all. Most of the other issues are being or have already been ironed out, this one I don’t think will change in the forseeable future.
Just to spark some discussion.
Maybe I’m an alien but I can’t really see what’s the hype about the Keramik theme. I tried it out with KDE 3.1 Alpha and I thought it looked pretty average. A bit messy and no real eye candy (besides of the buttons which look like tasty mint drops).
I liked Liquid at least ten times better (although I’m wondering how much Aqualook a human can take).
I have to agree with you Jim. It is amazing to see how older programs won’t work with updated versions of the libreries and it is really sad. Gnome 1.4 apps won’t work on Gnome 2.0. They have to be ported or have the old libs installed.
Look at Windows, Win16 apps work on Win95, Win95 apps work on Win98, Win98 apps work on WinMe, WinXP etc.
And this is one of the reasons Microsoft made it big: binary compatibility. It is ugly, it makes the code messy, but it is GOOD for the user overall and for the “business”. It is a choice that developers have to make: good for them, or for the user? Ms puts the user first.
OSX 10.2 has major backwards compatibility issues too. I will be writting about it on my review on Monday.
The main reason why there is a bad back-compatibility is that you can install several version of the same application on the same box. If you really do the compiling and know the real trick behind the compiling, then you can past the right –settings to your ./configure.
When ported to the updated version, your application can take the full advantage of the updated version. Under WinXXXX that is not the case. a win16 apps remain a win16 apps. And if it was compiled using VB3/4 then you need those dll just as you need the old libs under linux…
KDE 3.1 is different from 3.0 by its looks (Keramik + Crystal) and some usablity fixes and new features. I’m writing a document/article suggesting a new UI for KDE. Not anytime soon, though, as I’m only as KDM….
Keramik on the other hand may look nice, but that’s before comparing with GNOME 2.0’s default (what was that called again?), Aqua and Luna (WinXP). Why? They all look more *professional*. Crystal is nice, but it is just a nicer version of the previous KDE default theme. The author doesn’t want to change stuff, even the icons have no usablity sense. For example, the KControl Center’s icons doesn’t show that it is no configure the desktop/ machine. No offence, I’m sure there are people that like Liquid or Keramik…
Yes, but with windows you are talking about 16 bit windwos 3.11 code running on 32bit XP 9? years later (which works BTW, and you can run 32 bit code on 3.11 w/ libs installed). With Linux you you are breaking it from randomlib-3.4.6 to randomlib-3.5.0 in as little as 3 or 4 weeks time.
But the cryptic file system has been the same for longer than I have been alive. LSB needs a directory for installed desktop apps. There needs to be some type of separation between installed apps and system utilities. If nearly everything is recompiled for every version of every distro anyway, why not add a /programs directory?
So far I’ve only seen screenshots of Kermik. From what I’ve seen I would think it is very much like an “average” theme, means some find it very cool, and some will just hate it.
The advantage is: It looks unique: It is something of it’s own. This can lead to something like a coporate identiy for KDE, something people will recognize: Let me explain this: Most of the KDE themes (the fefault ones and many from kde-look.org) lokk like pther OSs: WinNT, WinXP, Aqua, QNX , etc. This isn’t bad for me since all these GUIs are more or less good designed an usable, but KDE just recreates them.
KDE should have something of it’s own. It’s like Apples Aqua: They trashed there old GUI and invented something NEW. There are peole, who hat Aqua, but they must admit at least thas it was new and that now everybody connect “aqua’ish” designs with Apple.
This is why Kermaik is good.
I am not sure what to think of the Keramik theme till try to use it for a while, but I do think some the eye candy is overkill.
My desktop preference is mostly minimalist so my opinion likely reflects such, here is a screenshot I took of my box shortly after installing the last Mandrake beta (I have a few more icons now)
http://users.adelphia.net/~geek/b3kde.png
There should probably be some separation for what is considered a good UI for a workstation and what is best for a desktop, but in general I think a DE should do 3 things
1) provide quick/easy access to shortcuts as a method to launch new apps
2) provide an effective, organized method to manage between existing open tasks
3) not be in the way
I also mostly agree with Fitt’s law
“The time to acquire a target is a function of the distance to and size of the target.”
But I do think there is something to be had for “looking cool”, as it’s generally much more inviting to users, which is what I think is Keramik’s strong point.
I will probably use it for 3 or 4 days and then disable it.
Maybe Keramik could create an identity… but most of the non-Linux/KDE/UNIX users I have asked, they say that Keramik doesn’t look professional. I have used Keramik for a full whole day before switching to QNiX, and it is a nightmare to use. Sure, it looks really really nice, and I would use it to show off my system, but it causes a lot of headaches :-p.
But the wonder is that GNOME/ Red Hat manage to something look professional and not too fancy either. Limbo is about the most professional looking desktop distro I have ever seen. I can’t wait to use “Null” (nice codename :-), but I’m sure it would be good.
Having used it for a few days, no, I’m not sure Keramik is the best-looking KDE style around – I think that award still goes to Liquid – but it’s a heck of a lot nicer than the old hicolor style. It’s unique, yes – and I think that’s very cool indeed.
It takes a lot of skill to produce something that’s unique and new, usable, and really good looking, but qwertz (the Keramik author) has pulled it off. Some people may say that the eye-candy is overkill, but this is why KDE has the personalizer that runs on first login with the eye-candy slider. In any case, Mac OS X and WinXP have both shown that massive eye-candy is far more tempting than it is offputting, even to corporate users.
As for the Crystal icons – well, IMO, these are unmatched on any system, although of course this is entirely dependent on your taste. I find them both very usable and extremely attractive. Certainly they are a huge improvement on the original hicolor icon theme. The SVG version of Crystal should be awesome.
Talking of looks, this is one of the reasons I’ve never really been able to like GNOME. The default GNOME look is… all browns, creams and other earth tones, and it seems very difficult to get away from this, as all the icon themes I’ve seen for GNOME seem designed around this colour scheme. The problem is that I can’t stand it. Cream, beige, brown – these are all colours that people use when they don’t want to offend anyone’s colour sense. It’s what most landlords paint the inside of rented accommodation with. It’s what most PC manufacturers use for their cases. It isn’t that the GNOME artwork isn’t any good – some of the artwork is superb, at least the equal of anything anywhere else. It’s just the colours make everything seem drab and unappealing
As far as backwards compatibility is concerned – well, with KDE you get full binary compatibility within a major release (i.e. apps compiled on 2.0 run on 2.2.2 without trouble), and at least with old KDE 1 apps you can just keep the KDE 1 libraries hanging around on your system and KDE 1 apps will still work.
It’s a shame that this doesn’t work with the KDE 2->3 transition (i.e. you can’t just leave the KDE 2 libraries installed and have KDE 2 apps run on KDE 3), mostly because DCOP doesn’t support interface versioning, and yes, this has been acknowledged as a bit of a cock-up by the KDE developers. It doesn’t really seem to make all that much of a difference though – everything I use was ported to KDE 3 within a month, and runs faster and with fewer bugs than it did under KDE 2. Let’s hope this gets fixed in the next couple of years so that nobody can moan about the KDE3->4 upgrade breaking apps.
Sorry for going off topic. As most of you know, MS makes some huge changes with each new release of their Office package. At work I write apps that work with Access databases. I loathe the way MS changes things on me, forcing me to keep up to date with everything. Although it’s possible to convert old databases to the newer formats, I can’t jump ahead and use the new format because not all our clients have the latest and greatest. Also, it’s not 100% backwards compatible, there’s alwayas that one little thing that breaks, and unfortunately for me, that one little thing just happens to be the feature I’m dealing with at the time.
As for backwards compat. in Linux apps, as long as the developers keep it simple and easy enough, an average user would be able to maintain up-to-date software without having to fuss about recompiling. I’m not saying I have an idea how they should do it, just pointing out the obvious just to make this post somewhat on topic.
> IFAIK KDE 3 was mostly just a port to QT3
You’re wrong because you have probably never used it. KDE3 had a much better Javascript implementation, maildir and improved IMAP support in KMail, group scheduling in KOrganizer, improved KDEprint, KDE Edu’s first release, a better file dialog, a regexp editor, improved Kate and much more.
I wouldnt expect KDE 3.x->4 binary compatibility.
1. First of all, it is almost impossible to achieve this as long as gcc breaks binary compatibility with every version
2. KDE would need to set standards among distributions: which compiler/ABI has to be used for the libs, the location of the kde directories and so on
3. The whole system must be designed for backward compatibility, so interfaces must be versioned and so on. This is possible, but a lot of work.
4. Unfortunately gcc’s ABI(s) dont make backward compatibility very easy.
That doesnt mean that backward compatibility is not a desireable goal, but it is too early to expect this. Also note that keeping backward compatibility will hinder progress, because that means that you must “pile” APIs (and maintain all the old crud). When KDE comes to a point when you can say that it is complete and you cant expect many changes, you can think about that. But KDE is not at that point yet, IMHO.
Does anyone here disagree with a /programs directory?
Well, I think that application directories are a good idea but only for desktop applications, not for system files and console application. I would really like appdir support in GNOME and KDE and some applications actually using this.
See this article for a nice description:
http://freshmeat.net/articles/view/247/
Dependency resolving should be a such a big problem as desktop applications usually are on their own. They will mostly require some libraries but how hard would it be to include a simple dependencies file which is then checked and if anything is missing, the system can either try to install those missing packages or show the user a warning/error message. I whish this idea would get more support. While it wouldn’t exactly make life more convenient for users (RPMs and DEBs are already very convenient), but they would make packaging the applications much more easier and unified and this should lead to more packaged applications which in turn would lead to more user convenience as it will happen less likely that there isnt’ an appropriate package for their distribution.
Does anyone here disagree with a /programs directory?
I dont see whats the matter with /usr/bin. Thats where most applications are installed (on a debian system), i like it. System apps are in /sbin/, and i think some are in /usr/sbin/ (if such a thing exists). But it really doesnt matter as long as a user has a good $PATH set up. I know that when im running as room i have more system apps at my disposal, and as a regular user, i dont.
And for spark, have been living in the dark ages? Any good package manager will know and tell you which package depends on which. On certain “fancy” ones, they’ll even go and download them all for you. I think the dependency hell problem is pretty much over (RedHat should encourage the use of its more complex package managers, cause i’m tired of people relating linux with dependency hell).
I dont see whats the matter with /usr/bin.
[jim@xor sbin]$ ls | wc -l
177
[jim@xor sbin]$
177 files in that directory, that looks inviting. I stated before that there is little separation between system utilities and installed applications (netscape, opera, blender etc.)
In /usr/sbin we have grub, addusewr, chroot, crond, rpcinfo, urpmi, supermount, ping, traceroute etc.
I agree on Sparcs point on not using it for system utilities and console applications. /programs does not need to be in $PATH because I don’t see the need to run netscape, opera, and blender (GUI apps) from console If you are using those apps you are in X using a mouse anyway. If you did need to launch them from console, you could map /programs/shortcuts to $PATH and keep links in that directory. As is exists now, many programs install too many files into separate directories all over the disk. Uninstalling them can get tricky when you used many separate methods to install them. Much easier to just delete /programs/netscape IMHO.
I thought you said /usr/sbin, I have 1515 files in /usr/bin
Try to navigate that directory with a GUI file manager.
On proprietary systems like Windows and Mac, backwards-compatibility is a MUST. Microsoft and Apple (more the former than the latter) depend on upgrades {Microsoft => OS, Apple => Hardware}. Therefore, the users must have the ability to migrate their existing applications to the new platforms.
Linux/BSD/etc, on the other hand, does not enforce such behavior. Yes, it’s nice to upgrade to the newest DE, but it isn’t required. And best of all, even if your application isn’t backwards-compatible, it’s likely to be in the near future… AT NO COST TO THE USER. Wanna upgrade? Great, grab the source or rpm… go at it! Is this such a big deal? Come on people… this is FREE SOFTWARE!
-fp
Richard, you should read the article I posted. The comment about a dependencies file was to show that it could easily be made compatible with RPM package managment so users aren’t lost when using such an application directory but missing a needed library.
I think that putting desktop applications in a directory of their own, in a hierarchy of their own is about the most sensible and obvious thing one could do with a distro. Put it in /opt/, name it /Programs/, whatever… I personally hate the tradition of putting every installed package in the /usr/ hierarchy. Sure, it brings up some path issues, but that’s extremely easy to work around… make a /Programs/exec/ directory with symlinks to all the executables, or something I would hope that somebody like RedHat, what with their suddenly aggressive targeting of the desktop would do something like this, soon.
As for Keramic, I’m rather unimpressed; my sentiment echoes that of most everybody to which I’ve shown it (which has been a wide range of users): it’s more or less approximates poor man’s Aqua. I’ll give it a shot, but I rather dislike excessively colorful widgets (and generally despise pixmapped widgets), and hate clutter.
@spark
hi i don’t want to insult you or something but you seem to be some kind of chief commenting like person. you write lines over lines on all kind of gnome mailinglist (i can’t count the shit comming from you every day anymore) and you seem to write tons of stuff here and on other places too. you write and write and write.. do you have a normal life or something ? i mean if you don’t like this and that then sit down your butt and start making something more constructive like writing some applications or write some patches that we like to have instead giving all kind of feedback what you want, what you wish, what you like etc.
we all like things and it takes time but we are also sick about all kind of comments that come from you.
Here is another comment I read on the above link
“I am for any good idea whether or not it rocks the boat. “Just because this is the way we’ve always done it” means nothing to me on its own merit. If there’s a good reason, by all means, say so. If we just like to argue with people who have ideas, we should examine our methods. No progress will be made this way.”
“Dependency resolving should be a such a big problem as desktop applications usually are on their own.”
Of course I meant:
“Dependency resolving should _not_ be such a big problem as desktop applications usually are on their own.”
The mail I sent to you was just returned (user unknown). So what are you? A lame faker? Very brave.
Understand it before you bash it.
http://www.pathname.com/fhs/2.2/
The directory hierarchy is the way it is for a reason. Directories like /usr aren’t necessarily available because they might be remotely mounted. Stuff like /var is there so they can be put on fast disks or RAM drives. Adding a programs directory wouldn’t make much sense, it would just dirty the scheme that was already in place. And differentiating desktop apps and other apps is equally bad. They are all just programs, right? Besides with good package managers, (portage, apt/dpkg) you don’t even have to be aware of how programs are installed. They install and appear in your start menu.
The directory hierarchy is the way it is for a reason.
Still waiting to hear what that reason is…
Directories like /usr aren’t necessarily available because they might be remotely mounted.
Quite a few binaries (i.e. KDE) are installed into /opt/bin/*, there is already a /usr/games, why not /usr/apps/blender/?
FHS for /usr/bin states “Most user commands”, the given examples are perl, python, tclsh, etc, I didn’t see Gimp listed as an example nor is it really a command, it’s a an application.
Stuff like /var is there so they can be put on fast disks or RAM drives.
/var (variable?) is for data caches, crash dumps, temporary files, log files etc, not for applications. Who suggested placing thes apps in var? I never said var was useless or that it does not serve a function. It does have a function, and providing a directory to install applications into is not that function.
Adding a programs directory wouldn’t make much sense
Not having one doesn’t make much sense either.
it would just dirty the scheme that was already in place
We wouldn’t want to dirty the well thought out method of throwing a couple thousand files in random /bin directories now would we?
And differentiating desktop apps and other apps is equally bad. They are all just programs, right?
Do you put ketchup and onions on your ice cream? What does your bedroom look like? Do you own a dresser/clauset, or keep all cloths in a big bin?
Besides with good package managers, (portage, apt/dpkg) you don’t even have to be aware of how programs are installed. They install and appear in your start menu.
And start menu icons would still be created just the same. If I install something with portage/apt/dpkg/make etc. can RPM still uninstall it? It’s kind of a pain uninstalling apps (that often have multiple files) when you have used multiple methods to install software and diffent portions of the app are in different locations on the disk. Wouldn’t it be easier to just delete /programs/blender or even /usr/apps/blender? This would also simplify the install proces as there is no need to keep a database of where the hell everything was installed.
I am sure all these new versions on KDE and Gnome are nice, but for me Nirvana has arrived in the form of Fluxbox. And then you just need to make sure that you have the right libraries installed for whatever app you want.
You’re wrong because you have probably never used it. KDE3 had a much better Javascript implementation, maildir and improved IMAP support in KMail, group scheduling in KOrganizer, improved KDEprint, KDE Edu’s first release, a better file dialog, a regexp editor, improved Kate and much more.
He was comparing KDE 2.2 to KDE 3.0 and KDE 3.0 to KDE 3.1. He didn’t say that there wasn’t any new features. 2.2, comparing with 2.1, has the same amount of increase in features as KDE2.2 to KDE 3.0.
But I think the biggest feature of KDE 3.0 is the increase in speed.
Still waiting to hear what that reason is…
>>>>>>>
Did you even read the FHS standard? There are rationales for everything.
Quite a few binaries (i.e. KDE) are installed into /opt/bin/*, there is already a /usr/games, why not /usr/apps/blender/?
>>>>>>>>>>
/opt is for add-on packages that aren’t really part of the core system. Stuff like desktop apps and KDE should not go here. These programs are regularly used by the user, and should go in /usr. /opt is really useful for things like vmware or Intel C++, which aren’t core programs, or are giant 3rd party programs. Its true that some distros install KDE to /opt, but Debian and Gentoo don’t, and the Debian devels (who generally try to do the RIGHT thing) oppose KDE in /opt. Link here: http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01…
As for /usr/games, its generally not encouraged to use it, and it doesn’t even appear in the FHS.
FHS for /usr/bin states “Most user commands”, the given examples are perl, python, tclsh, etc, I didn’t see Gimp listed as an example nor is it really a command, it’s a an application.
>>>>>>>
There is no distinction between a command and an application. Its pointless to try. How do you define a command vs an application? Take simple GTK mini-programs (like theme changers, magnifiers, etc). For most UNIX users, its most convenient to launch those via the command line. That means the have to be in /usr. But then you end up with some GTK programs in /opt and others in /usr. With modern package management methods (ie. not vanilla RPM) Its really an unecessary layer of complexity.
/var (variable?) is for data caches, crash dumps, temporary files, log files etc, not for applications. Who suggested placing thes apps in var? I never said var was useless or that it does not serve a function. It does have a function, and providing a directory to install applications into is not that function.
>>>>>>
I never said that. I was merely giving examples of why specific directories in the UNIX filesystem exist.
Not having one doesn’t make much sense either.
>>>>>>>
Yes it does. The UNIX mindset is not of big monolithic programs, but rather small, inter-operable commands. Thus, it makes sense to install everything into one directory rather than splitting things up. What do you do with stuff like Konqueror, for example? Under the UNIX way of doing things, you’d put the konqueror binaries in /usr/bin, and the libraries (including components) in /usr/lib. Nice and clean. Under the Windows/MacOS way of doing things, you’d put the whole program (binaries and libraries) into /programs/konqueror. Also nice and clean. But then what do you do when you need to take into account that konqueor can be embedded and parts of the program need to be in global directores? Do you put part of the program (components) in /usr/lib, and the rest in /programs/konqueror? Is that nice and clean anymore?
We wouldn’t want to dirty the well thought out method of throwing a couple thousand files in random /bin directories now would we?
>>>>
A) The bin directories are not random.
/bin is for system programs that must be there before network filesystems are mounted.
/usr/bin is for general user commands.
/usr/local/bin is specifically for commands compiled by the user.
B) Just because there are a lot of files doesn’t make it dirty. The binaries are almost always accessed via package managers, so whether or not its easy for a human to figure out really is a non-issue. And it has the cleanliness advantage of making it easy to share program components.
And differentiating desktop apps and other apps is equally bad. They are all just programs, right?
Do you put ketchup and onions on your ice cream? What does your bedroom look like? Do you own a dresser/clauset, or keep all cloths in a big bin?
>>>>>>>>
My bedroom and my computer are two different things. I have no idea why so many people in this forum thing that the organization of the computer should mirror real life. Look at it this way. In real life, I have my clothes nicely organized in a closet. If I want something, I need to go searching through the various parts of the closet for the particular item I want. Just the limitations of reality. I would prefer to do it the UNIX way, where I just make a single gesture (apt-get install <whatever>) and the item I want just appears there. I can’t have that kind of convenience in real life, but I can in my computer. Why try to spoil that? BTW> Nice pun on /bin.
And start menu icons would still be created just the same. If I install something with portage/apt/dpkg/make etc. can RPM still uninstall it? It’s kind of a pain uninstalling apps (that often have multiple files) when you have used multiple methods to install software and diffent portions of the app are in different locations on the disk. Wouldn’t it be easier to just delete /programs/blender or even /usr/apps/blender? This would also simplify the install proces as there is no need to keep a database of where the hell everything was installed.
>>>>>>>>>>
It might be easier to just delete /usr/apps/konqueror, for example, but what about all the libraries that konqueror provides that other programs (kmail) are dependent on? In modern desktop environments that have extensive sharing of program componenets, the “simple” method of application directories no longer makes sense. Why complicate your life? Why not just allow the computer (ie. apt-get or portage) to do the dirty work for you? apt-get remove <program> is just as easy as rm -rf /programs/<program> but allows the system to do a much better job than you ever could.
You suggest changing the directory hierachy, but i fail to see any good reasons for doing so. It is entirely possibly that i just totally fail to see the problems you see with the current system.
First of all, i cant see why 1500 files in one directory is bad. I mean, you should have pretty little icons for all the programs that are interesting for “normal” users, and various other means of finding useful shell commands. There is simply no reason why a non experienced users would even have to know that /usr/bin exists. Installation is done automatically, uninstallation is done automatically. The program should appear as an icon if it is a gui app, and it should automagically be in your path.
The way i see it, the current system works perfectly both for desktop use, and command line use. Most of the arguments that i have seen in favor of changing it to /something/app_name are rooted in the fact that the person in question is trying to do something he shouldn’t be doing on a unix system. This might sound arrogant, and it probably is, but i sincerly think this is a large part of the problem and why there is such a big culture clash between the “we like unix” camp and the “we don’t care if it is unix, we just want things to be idiot proof, and preferably work the same way as windows” camp. I don’t think these two sides will ever agree.