KDE 3.4 RC1 Released

twener writes "The KDE project has announced the first release candidate of KDE 3.4 which brings many new features targeted for release at 16th March. Sources (requirements list, build script), an i486 GNU/Linux Live-CD (375MB) and SUSE 9.2 binary packages are available currently. OSdir.com and tuxmachines.org have screenshots of this release. Source Code and a Live CD are available."

Comments

i486?

[idiot900]

Is anyone trying to run KDE on an x86 processor that doesn't support at least the i586 instruction set? Anyone at all?

Re:i486?

[Erik Hensema]

Besides that, the i486 is a very weird architecture. i386 optimized binaries run faster on a i586+ than i486 optimized binaries.

Never, ever optimize for i486, unless you own one. But then don't run KDE on it. You won't be happy.

Constant Change

[HeelToe]

I'll probably get modded down for this, but my forays into KDE use have been separated by 6 months at a time. It seems the KDE team is emulating Microsoft's penchant for changing how major features of the interface work at frequent intervals.

I see lots of people complaining that each time Windows is updated they have to relearn the GUI, but honestly the same is true with KDE.

I'm not primarily a Windows user - I mostly use Mac OS X these days, but because of the amount of change that happens in KDE, I find it more trouble than it's worth and have begun to just stick with XFCE when I'm working on my Linux boxes.

It would be nice to see some consistency between major releases of KDE so that configurable items are still found in the same place when you upgrade, etc.

Re:Constant Change

[Coryoth]

this is how many such things are already done in KDE. margin hints, spacing hints, menu layouts... there are some things that just don't translate to being put in the libraries, however.

I think that's great, but in the end that is just hinting toward looks, not actually doing the job of laying out the GUI (which is possible). The really extreme approach is to actually decide how to represent things in the GUI - a component just says "I have feature X which has use priority Y and ..." and the HIG engine decides whether that features needs its own dialog, or a button on the toolbar, or ... and where (based on relationships to other functions and components) to place the function as a menu item in the main menu. Does the function show up in a context menu? Potentially you can define all of those things too.

Jedidiah.

Re:Constant Change

[Coryoth]

You mean like this from 1985 which had (they claim) a working User Interface Management System? Yes, I agree, it is hard, and is an active field of academic research. There is a lot of research though, that we really ought to be looking at instead of just letting it remain research. I think this starts to fall into that category.

I don't see why you need XUL or XAML either - it would seem to me that, for instance, libglade is something you could build such a system on top of as well. This is something GNOME and KDE could be working toward right now as yet another way to help unify the desktop. Applications could still be GNOME or KDE specific (if they chose to use particular features of the DE) but it would then also be possible to write applications that were desktop agnostic and slotted into either.

Jedidiah.

Live CD's

[IceFox]

This is one area where Live cd's really shine. As a user I am able to download, burn and try out new major pieces of software and help out by reporting bugs v.s. before where most people would just wait for the 1.0 release and then report problems they spotted. Spend ten minute checking out the cool stuff in KDE 3.4 and make sure to report any bugs you find (In the help menu of every kde app there is a report bug action).

Along the lines of bugs, KDE's bug tracking system just reached it 100000 *reported* bug (not open) On the kde news site ther is a story about it include tips on how you can help report bugs/problems that you find in KDE to help make it better.

-Benjamin Meyer

Desktop Unity?

[Doc Ruby]

What happened to implementing the Shared MIME Info spec from FreeDesktop.org? As recently as 1/2005, KDE was "planning to support it for their next major release". GNOME already supports this way to focus on our data, with automatic integration with our apps, without worrying that we picked the right desktop to mediate between our apps and our data. Is the next "major" KDE release "4.0", and we have to wait a few years for MIME integration to catch up with GNOME? Or is the MIME layer already in 3.4, and this is just another action-packed OSS episode airing with hidden, inscrutable features not making it to the release notes?

Re:Desktop Unity?

[Doctor Crumb]

Yes, 4.0 would be the next major release. 3.4 would be a minor release. It just happens to have a lot of cool new features.

Re:Why make it look like Windows?

[schleyfox]

Ever tried enlightenment? it emulates nothing, infact it is rather far ahead of anything else. An amazing amount of eye candy with *box like speeds, w00t its awesome

Re:Funniest quote

[stilborne]

it requires striking a ballance. QA is dead simple if there are no options and few features. but then you have software almost nobody will want to, or even be able to use in the real world. so you add some features, some configuration ... at the cost of QA overhead. but you get useful software.

ballance.

it's similar with the other items you list (bug fixing, integration, etc), though QA is hit harder than them. the "finding the options" problem is more a limitation of how we enforce hierarchical navigation of these things more than having a sane number of options. because even a sane number of options quickly spirals out of range of these mechanisms.

so ... we're engaged in an ongoing search to find that ballance in KDE, and i think we're finally getting some good formulas together. KDE 3.x is used by enough people who really enjoy it that i don't think it's fair to call it "unusable", but it can be improved upon (it always can ;). and so we continue to make new releases.....

in his FOSDEM interview, Matthias Ettrich (the project's founder) was asked what three things he'd like to focus on in KDE 4 and he said: usability, usability, usability. good answer.

of course, usability is about a LOT more than ensuring there are only N options in an app, or that the menus are correctly arranged. those are important steps, but let's not get obsessive over details that are only part of the picture, something i see a lot of people do, sadly.

for instance, i find it interesting that for being such a central piece of UI, the file dialog is rarely considered by usability "enthusiasts". take the KDE file dialog and compare it to other Open Source toolkit file dialogs .... personally, i'd take a file dialog like KDE's even if it meant having to put up with some annoying config dialogs elsewhere. it's items like file dialogs which provide most of the "usability" in a desktop.

but then... i use my systems to get real world work done and so these sorts of things actually matter to me. =)

Re:Funniest quote

[functor]

Sorry, but Havoc Pennington's influence has castrated GNOME. The few things you can change, you need to fire up gconf-editor for (remember NT 4 and the Registry Editor?).

I use KDE, unashamedly because it offers me options and one size most certainly does not fit all when it comes to UIs. Sane defaults, yes, but one man's sanity is another man's annoyance.

Under Havoc Pennington's influence, perfectly sane preferences such as the ability to turn off Nautilus' desktop icons disappeared between GNOME 2.0 and 2.2 off pref dialogs, with the prefs receding to the murky depths of the largely undocumented gconf system. Forgive me if I think he's GNOME's problem, not its savior.