Australian computer news site Computerworld asks if KDE 4 will be the ultimate business desktop. Speaking to developer Hamish Rodda they look at the changes being made to the KDE libraries including the Akonadi storage manager for PIM data. He also explains why KDE 4 will be important for ISVs to support.

Which article?
The KDE4 article about upcoming software visions or the link?

Ian describes why Linux fails. Linux remains third choice because of this problem. KDE3 or KDE4 does not matter, both are ready and superiour - or will be ready. KDE4 means designer clothes for a wheelchair-bound operating system.

Maybe because there's no way the downloaded file can tell the system that it is executable, huh? Think of it as a security measure -- the solution isn't to make the file executable, but the UI (KDE for us) should ask the user if he likes to make it executable (with appropriate security warning).

Adding some sort of signature checking that vendors could use non-intrusively (ie, noop on unsupported platforms, like a gpg signature embedded in a shell comment) for a bonus. Apparently there is demand for completely out-of-band software distribution and FHS and friends even have provisions for those (/opt, installation under /home), so i don't see why the OS would be responsible for those. Desktop and ISVs can fix all this mess rather easily (contrary to what is claimed in this thread somewhere)... Also, there's LSB which is generally not very useful, but i think it may mandate some compatibility libraries to be present on system, so apt-get install lsb-base (and that should probably be part of default install, too).

I put in a wishlist "to make the file executable...with appropriate security warning)" like 2-3 years ago and *again* this year. Go vote for it please!!! Nautilus did this (last time I used it...years ago) and it was great. I really wish KDE would listen. It's one shining example of where KDE refuses to increase usability.

I don't know. Seriously. This is the biggest hole in Windows, and while some (few) Windows people that come to my house sometimes complain about it, I just explain to them that it is a BIG security hole.
Two ways of installing something that comes from outside, and both of them HARD to do accidentally (harder than hitting OK in a dialog): run it klik-style, but in a more strict sandbox than klik does today, or install a package from a previously-authorized source.
In the "business desktop" scenario, the second one is the Only Right Thing To Do (TM).
The network admins set the .deb/.rpm server inside the network, customize the distro to use that server, and put there the commercial software they authorize -- after auditing its network connections/ scanning for viruses, etc.
Want to install some software? It must be in the synaptic/adept list or else, go complain to the BOFH -- if he is not really from Hell, he will study the software you want to install and in a couple of hours/days/weeks it will be in your list and in everyone (authorized to use the software) else's list on the company... so you can install your software with a couple of clicks.
Been there, done that. HTH.

Well, you can avoid having users changing permissions to executable for your installer by putting it on a tar package. It will keep permissions, and users can easily unpack it easier than changing permissions. With a graphical interface for it (static compile libraries), users won't even need

Getting dependencies right won't be as easy though. However, most distributions already ship a decent amount of common libraries, as well as an intuitive package installer with repository support, so this shouldn't be as much as of a hassle.

What really bothers me -- I don't know if this bother the casual user, but it sure bothers me -- is the directories naming that pretty much every distribution use. There is too much clutter at root and /usr, /var, /mnt are far from intuitive names. Yeah, I don't think this will scary grand ma who should just run her session like if it was a locked virtual machine, but I find that people, even if they are not too computer inclined, like to peak at the system.

Till now much of everithing in KDE is to much blah blah blah and we will do this and that and take a look to SVN, KDE has been on developep for a year and a half and till now there is just so litle to show and that makes me think in 2 options:

1.- Everything is hiden like a secret weapon to be show in the last moment and give us a surprise, that would be nice but at the same time hypocrital since being a open source project would be lame to keep the code just for a few while is developed.

2.- Is like the MS Windows Vista campaing, where there were to much presententions and blah and blah and blah and to litle to show.

I hope its the option 1.

Since the mayority of KDE users and people specting KDE4 are not developers and have no clue about SVN I recoment to start giving something visible and not a bunch of lines of abstract code or SVN links.

I agree that there is little too see (as in 'for the end-user to try out') while things all over the place are being developed. Major frameworks have been introduced to KDE4, such as Oxygen, akonadi, Phonon, Qt4, Solid, threadweaver. Not all of them are completely finished already, but it really is the time where application developers are picking up this new stuff and use it to improve their applications and build new ones. The problem with releasing the software is simply that the end user applications need to be adapted and further developed -- not at least to stabilise this basis, and that has not happened at large yet.

That new stuff is not hidden, though (in that respect, sorry ;-)), but it's not exactly user-visible either -- that's a natural characteristic of the development process. Little to see while new frameworks are being created.

If you want to follow that, however, and get to know more about what's happening, have a look an Dannya's commit-digest and the different blogs syndicated via planetkde.org.

> Since the mayority of KDE users and people specting KDE4 are not developers
> and have no clue about SVN I recoment to start giving something visible and
> not a bunch of lines of abstract code or SVN links.

this is the most amazing piece of advice i've read in a long time. i mean, really, what *are* we thinking writing code in a repository!

oh wait, we're a software project, that's what we do.

our aim is not to create something for you to look at this moment, our goal is to put together a rather complex set of software for eventual release and hopefully enjoy the process.

as for visuals, take a look at the kde games, the work happening in the directory view parts (saw some really stuff that frederikh was working on the other day for listview delegates), in dolphin, etc ..

Funny how these types of posts are filled with typos. Just in case there are any rational readers who don't understand the software process for a major release...

1) work on your specifications for your new libraries
2) begin writing code for those libraries, test it and interact with other developers using it
3) once library code is stable begin application rewrites on it
4) develop until the end of that cycle and begin releasing alpha, beta and release candidates

In other words there isn't anything new to give/show users other than a description and maybe a few screenshots/mockups unless they want to compile and run development code. Claiming this is vapor in the case of KDE is pretty much ignoring three major releases that have delivered exactly what the developers promised. Claiming this has anything to do with Microsoft ignores the realities of the different development models. To see what I mean read this...http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html

Always remember comparisons need rational data, not wild speculations and and unsubstantiated claims. If KDE4 was not stacking up to be what developers said other developers would be making loud noises about it.

You are joking right? How long did it take for Microsoft to create Vista? How many of the "killer" features have they pulled out to get it done? How long did it take them before they had anything to show?

For how long have they been developing KDE4? Not that long really, especially not considering how relatively few they are and how much they are trying to do. KDE4 is a huge change and it will live for many years after it is released.

Keep up the great work KDE developers! Really looking forward to KDE4, but I'm waiting patiently ;)

I second this sentiment. Don't worry about a-holes mouthing off. Those of us who are serious users of KDE are waiting (somewhat :-) patiently for KDE4. The progress is obvious to those who follow closely, and it seems that the "tipping point" is getting near.

you are doing a great job. KDE 3.5.5 is a great piece of software and if 4.0 is better than it, then it is going to be awesome. If you look how long did it take to large organisations to implement applications of a similar size, then you will understand the long timeline.

Interessting thread. But let's correct the statement "Dark Phoenix" just changed. What the adobe-devel (and the users) sayed exatcly was;

"Yes, I have looked at Gnome and KDE lately. That's why I largely write them off as pointless. [...] What's holding Adobe off from Linux: Linux, and it's users. The "OS" is nowhere near ready for large desktop applications"

Funny, that Acroread and flash do exist at all. Anyway, that's another topic even if an interessting one :)

>>What's holding Adobe off from Linux: Linux, and it's users. The "OS" is nowhere near ready for large desktop applications"

I think it's more that their customers are holding adobe off from linux.
porting their large desktop applications to linux will be a large effort wich should be payed back from revenues coming from their linux sales. And apperently there is not a big enough Linux market for adobe to justify such an operation.

That linux is not ready for large desktop applications is bogus: there are enough other players in the market that have created/ported their large desktop applications for/to linux.

B) Linux has a chance as a professional cluster rendering station for graphic specialists. In fact clustering means Linux today. That could help to roll off the graphic market, starting with professionals.

C) The weakness of Linux is not KDE or Gnome or ICEWM. It is to be found exactly where these Desktop Environments do not set standards.

A: Ian should blame SUN for delivering a crappy installation program.
Surely Adobe would be capable in delivering an installation program that would work normally on Linux.

B: Linux is at the moment the key platform for a lot of animation films on the market: shrek, finding nemo...
for whatever reason, the complex grafical rendering applications they use have no problem running on kde (mostley on kde 2 by the way..0
So why should running adobes applications be a problem?

C: Large applications don't care about standards. They mostley come with their own specialised toolkit/framework/etc.
The parts of the desktop that they need to use are already standarised.

Funny thing is, Photoshop isn't the type of application that needs a whole lot of desktop integration. The state of the desktop is irrelevant to the application. The user could be running a broken FVWM for all the application should care.

You trolls sure seem to be 'interested' in Linux and KDE for you to be spending so much time trolling this blog!

More and more, corporations such as Adobe are becoming irrelevent. Their overpriced bloatware is like printing money (for them) but notice that the only way they can continue to grow is my eating other companies (Macromedia) and forming a monopoly? That indicates a declining industry.

I am 'interested' in Linux and KDE because I'm RUNNING Linux and KDE. I was angered and outraged by some of these comments (especially the computer club one; that about sums up how corporate programmers feel about open source programmers in general)...

Sorry for posting this here, but I'm sort of desperate ;) I'm trying to compile trunk but get stuck now and then. My aim is to start using KDE4 already. (Yes I know what kind of minefield and battlezone I'm moving in to;) ), My sole purpose of trying to move to KDE4 this early is to live on the bleeding edge. I'm just that kind of guy ;) But! There are some trouble on the way. So far I've been to lazy to check out every single application by it self. I'm going for the whole kdegraphics, kdeedeu, kdesdk etc. But many of these fails compiling due to "kdeXXX/build does not appear to contain CMakeLists.txt" Is this the way it is supposed to be? Does this mean I've have to check out every single little KDE app by its' self? Or is this a bug? (Where do we report KDE4 bugs anyway? If we do/bugreporting is wanted at this early stage).

Let me also use this opportunity to than all KDE developers for their excellent work, their sacrifice of valuable free time and their general commitment for a better (computer) world.

> Where do we report KDE4 bugs anyway?
IMHO it depends on what you mean with KDE4-bugs. Since that term includes pretty everything, without any specialization like e.g. "where to report that KWrite from trunk crashes each time I open a file named a.txt since revision xyz till head compiled 10 minutes ago?" I would say;
Just try to fix them, offer more details or recompile again since it's very likly that the problem got fixed already cause things are faster then Lucky Luke this days what imho makes it very difficult to handle bugreports against single checkout-revisions cause just nobody has the time to check reports to just note that they got already fixed 5 minutes after your last checkout or to just note that the only single person who was able to reproduce the bug jumped to another revision where she/he can't reproduce it any longer too.
I guess things like realtime-communication e.g. within the IRC-channels (hint: try Kopete or maybe even Konversation, that's damn great software) is a good helper here to keep in synch with a such fast moving development-process :)

Yes, this is off topic. Don't post "how do I build this?" questions here. First of all your passion to be on the bleeding edge is great, but you also need to know what you're getting yourself into. While KDE is usually very stable throughout the development process a major release is subastantially different. You WILL have things broken and days you can't build some programs as well as conflicts requiring substantial parts to be rebuilt or rolled back until development is synced. I would not recommend your course of action prior to alpha or beta releases, which are not happening any time soon.

If you are determined to run KDE4 then get on the kde-dev mailing list. You will need to know when things are broken, how to fix things and where to feed back to developers. Bug reporting? At this point you may find something helpful, but most problems developers know about and are working on. That's not to say finding a bug isn't helpful. It is to say an active bug process here would really bog development down. Enjoy!

afaik unittests are a great way to start and e.g. kdelibs comes with a lot of them. Beside that, we also try to improve the new wiki located at http://developernew.kde.org and for sure any help there is very welcome. Beside kdelibs there are also a few others projects within KDE where help is very welcome. But here it depends on which part you like to work on. Well, or just join the #kde or #kde-devel IRC-rooms and ask who needs help :)

Let me also use this opportunity to than all KDE developers for their excellent work, their sacrifice of valuable free time and their general commitment for a better (computer) world.

Well, might I kindly ask you to sacrifice just a bit more of your own valuable free time to produce a vmware image (or better, periodic vmware images) of your favorite linux distribution running kde4 so the rest of us can benefit from all the KDE developers' work and from your time and obviously hard effort in solving these build issues?

A bit confused wheter you ar being sarcastic or not?!? But OK, giving the benefit of doubt :) I have no clue about WMWARE :( But I solved the trivial task of getting things to compile. When ever I have the time I suash a bug or two in Bugzilla. (Nope, no coding. Only removing duplicates and bugs no longer valid). So yes, my efforts are really humble and bearly visible even if you look for them. But I belive in that many people doing litle things, will together achive great things :)

"kdeXXX/build does not appear to contain CMakeLists.txt"
Yes, the build/ dirs don't contain cmake files.
Did you run cmake manually or use some script ?
You have to enter the builddir and then run cmake there, pointing to the source dir, e.g.
$ cd ~/src/kdegraphics/build
$ cmake ~/src/kdegraphics/
...
$ make

Sorry, as a non-developer I do not want to critisize the development process of the PIM-suite Kontact but I simply want to know if there is progress in these applications for KDE4 beside Akonadi especially in connection of syncing with mobile phones or PDAs.

I certainly do not share ok's pessimism. I frequently read the commit digest and Planet KDE, and I have to say that I'm impressed with the effort for KDE 4 and that the developers are doing great. I have the greatest respect for the KDE 4 dev's.

Sure, maybe I had expected more by now, especially news about Plasma. But the effort required for KDE 4 seems much, so it will take some time. Just accept that the dev's need some time, and they have a job and a life as well. I can wait for another year or even longer, I'm sure KDE 4 will be worth it. Personally I'm playing computer games most of the day and I can't do much more than "hello world" in C++ and I didn't bother to learn it, I'm not productive at all. The KDE dev's are incredibly productive, I think they're awesome.

KDE 4 will make full use of OpenSync for synchronizing mobile phones, PDAs and more. We already have replaced most of the old KDE-specific syncing solutions by OpenSync and its KDE frontend KitchenSync. There is a mostly stable version existing for the KDE 3.5 line which is being picked up by distributions like openSUSE 10.2 right now.

For KDE 4 KitchenSync and OpenSync will be the standard way of syncing your data with mobile devices. As OpenSync is designed to be a standard cross-desktop and cross-platform tool, this means that there will be plenty of plugins for syncing with a very broad variety of devices and problems can be addressed at a central place.

So the answer is: Yes, there is tremendous progress in the area of syncing and KDE 4 will make use of, support and integrate the best free software solutions for that which are available.

I'm disappointed at all the negative comments on this page! KDE is a GREAT desktop environment. It looks slick, it runs fast, and it's loaded with features.

I have read about many of the new underlying frameworks - DBUS, Solid, Plasma, OpenSync, etc. - and it's clear to me that the dev teams have excellent ideas and are working together to make a really cool product. Will KDE4 be so revolutionary that if will change the very way we think about computers? Probably not. Nothing that revolutionary has happened since Xerox developed the WIMP (window, icon, menu, pointing device) interface. But will it be vaporware? No way. Just take a look on kde-look.org, and you'll see that smart people have all sorts of cool ideas for the new desktop interface, how Konqueror should look, and so on.

While I agree with your comment, I find KDE ugly when it comes to fonts. Why should one have to have Microsoft fonts in order to have a decent looking desktop? KDE, with its power and configuration capabilities should have fonts that look clear, crisp and "web-ready" by default. This has never been the case in my opinion.

What distribution are you using and which version of KDE are you using?

1) In most distributions the fontserver is deliberately altered (e.g. SUSE) so that algorithms that are claimed to be patented by Apple / Microsoft don't get used to improve font quality. This results in poorer quality for the fonts displayed. Solution: Either look for optimized rpm's or deb's offered in unofficial repositories or compile the package yourself.

2) Another thing that might decrease font quality is this: fonts usually get manually optimized by the font designer for certain absolute font sizes. Usually for GUI text those optimized font sizes got picked by the KDE team. However those optimizations only refer to 96 dpi. If the monitor resolution differs a lot from that value non-optimized font sizes might get used which result in poorer quality.

Solution: In KDE 3.5.5 enable "Force DPI for Fonts: 96 DPI" in the font dialog of KDE's Control Center.