Third KDE 4 Development Snapshot Released: "Kludge"

The KDE project announces the availability of the third development snapshot of the upcoming KDE 4. This snapshot is meant as a reference for developers who want to play with parts of the new technology KDE 4 will provide, those who want to start porting their applications to the new KDE 4 platform and for those that want to start to develop applications based on KDE 4. This snapshot is not for end users, there is no guarantee that it will be stable, and the interfaces are subject to changes at any time.

This new development version of KDE features the following new technologies:

  • Sonnet which has previously been covered on Linux.com.
  • Solid, KDE 4's unified layer to deal with hardware and network resources.
  • Vastly-improved support for the Windows and Mac OS platforms by cleaning up the source code from dependencies on X11. See kdelibs.com for more information.
  • The recently added filemanager Dolphin which will be the default filemanager for KDE. Konqueror will still be available and share much code with Dolphin.

After "Krash", the first development snapshot, this is another milestone towards KDE 4.0 which will be released later this year. The KDE developers aim at a release in summer 2007. Reaching this target depends on application developers picking up the new technology to use in their applications. While "Krash" marked the milestones initial Qt 4 port, the use of D-Bus as the inter-process-communication system, the merge of Phonon as the multimedia framework and CMake, KDE's new buildsystem defines this latest release.

The next planned change is new integration of Oxygen, the new artwork concept. Work on Plasma is also taking up pace.

Download the 3.80.3 source, or install packages for Kubuntu or openSUSE.

For those who want to keep track of the development process, KDE Dot News regularly covers new and upcoming technologies through the series "Pillars of KDE 4" (informing about upcoming technologies) and "The Road to KDE 4", which covers new functionality that has been integrated in the official development tree.

Questions about KDE 4 are answered on various mailing lists such as kde-devel and kde-buildsystem, as well as on #kde4-devel on irc.freenode.org. Documentation for getting up to speed with KDE 4 development is available from a number of sources.

Dot Categories: 

Comments

by Bernd (not verified)

Beside I suspect unashamed advertising. Yes we do!

by Sutoka (not verified)

Yeah cause gaim and kopete aren't installed on pretty much every linux distribution out there by default, and NEVER work, right (there goes every single 'feature' meebo has)? Talk about shameless advertising... Make like a java applet and fade into obscurity.

(Wow I must have woken up on the wrong side of the bed this morning or something...)

by xyz (not verified)

yes

by Darkelve (not verified)

So... do you promise you won't steal my MSN password? o_O

by Thiago Macieira (not verified)

Of course we do. Have you seen email clients disappear after the invention of webmails?

No, they have not. The reasons are actually quite simple: they are faster to use, more integrated with the desktop and quite often more powerful. (Hey, I feel like I'm describing KDE here)

by devnull (not verified)

So as I'm in Australia, does this mean the release by summer of KDE4 is imminent?

by Thiago Macieira (not verified)

No, for you the release will be December 21st :-)

by Andy (not verified)

With KDE applications I often get bugs like you can see in the attached screenshot file. Oversized dialogues because text fields contain text other than expected.

Cant there be a KDE gui testing environment which prevents this to happen, which tests windows, a smarter windows management code? Is that provided by QT4? I really hope that KDE will put an end to these annoyances.

by Aaron Seigo (not verified)

that dialog essentially needs one line of code:

label->setWordWrap(true);

send in a patch or let the devs know and i'm sure they'll pop it in post-haste.

> gui testing environment

would be nice. huge amount of work. send more workers. elf needs food badly.

by otherAC (not verified)

you could use RC versions of amarok and report your findings to the amarok team.
bugs.kde.org is a good starting point for those reports

by Andy (not verified)

I use mandriva and these are the recent packages. I don't know how to use the KDE build system to compile Amarok myself. As so many different libs are involved I assume it should take some time.

The point is that it's not only amarok, you get it with so many KDE applications from time to time. And it was always a problem with KDE. So the question is: That window had a width that exceeds the screen size. Can't that be "tested"? In the sense of: expected behaviour, unintended occurance.

I am thinking of a talkback KDE version with realtime testing. Whenever the window or dialogue manager realises that the window exceeds screen size, it saves a screenshot and makes a log entry. This directory can then be submitted to a KDE testing server.

Or: Everytime a font character is used that cannot be displayed.

Many bugs you will only find in a realworld environment. When you have a tool as Amarok, why not use real files .

By the way: most often the bug occurs with the context tip screen.

by otherAC (not verified)

>>Many bugs you will only find in a realworld environment. When you have a tool as Amarok, why not use real files .

Thats why i suggest to use prereleases of the software and report the bugs you find while testing it in a realworld environment.

For example font testing would be quite hard in a testing environment because KDE does not ship any fonts, so it can't create a situation that every character in every language will be displayed with the right fonts that can display them.

by Andy (not verified)

A test suite can create extraordinary conditions and simulate certain activities.

E.g. you have a collection of 5000 fonts on your server and try them out with a test program and a script. Regressions are then also available.

Or you have a tool that fetched any pdf from the internet and then tries to feed it to okular. Failed pdfs get saved and examined.

Or let khtml do random webbrowsing until it fails.

Or you have talkback versions where e.g. all console error messages het logged.

In general no window should ever get more than 100% width of screensize. But that is something which can be tested.

by Morty (not verified)

Generally testing and generating test are very time consuming and require lots of work. And in the end you are still limited by what the developer of the test thinks of, and what he decides is required to test. Its likely the developer of the application does not consider all extraordinary conditions, and often it's the same developer writing the test making it very unlikeley the test will cover it. That's why it's important to report such bugs back to the developers, it's the only way they can learn of the problem.

Designing test that are both efficient and have high coverage are difficult and require skill. And in the end it's always a tradeof between the reasonable amount of time spent testing and what's being tested. Designing tests is a valued skill in the enterprise, you can make a decent living as a full time test engineer.

Testing random stuff is not particularly usefull, it's time consuming, it's very hard to tell what you have tested and it's not deterministic. You most likely test some things 100s of times, where other stuff never gets tested. And it lacks repeatability, making reproducing and thus fixing the bugs harder.

by Andy (not verified)

What is the problem? Real world = Real random broken content. So the pdf thing works like this: You fetch a random file from the net, open it. If the test program crashes you have a file that crashes the application.

----

Then there are some occasions where usually a popup dialogue is displayed, e.g. because a certain protocol does not support the functionality. A talkback version enables you to report the incident as a bug because that is what it is.

by Morty (not verified)

In this case the problem boils down to coverage and time, and that what makes this approach not usable.

Simply put, with your pdf example, the odds are good that the first 10.000 random files you download will not crash the application. One reason for this is that most pdfs only uses a small part of the pdf specification, and that part being the general case which by nature the best supported. You have now spent lots of time basicly testing the same thing over and over again.

But even worse from a testing perspective, you still have no clue what you have not tested. And very little indication of which part of the application you have tested, without dissecting the the 10.00 files to see what part of the spec they represent(And most likely that's already covered by a few of your reference pdfs).

by g. (not verified)

On an unrelated note, Herreweghe's Bach sucks, you should really try some J.E. Gardiner ;)

by ENFORCER (not verified)

Will there be any UI-Effects like in E17 or Opera. Or at least it should be possible. Polyester is cool, but I think some hacks were used:
http://aseigo.blogspot.com/2006/09/qtimeline-timers-and-what-to-avoid-in...

by superstoned (not verified)

Qt4 will make many GUI effects easy to create and fast to run, so I guess we'll see some neath stuff...

by ac and the rest (not verified)

Does that include theming effects like getting a marble looking kde, like in kde2?

by whatever noticed (not verified)

"A kludge (or, alternatively, kluge) is a clumsy or inelegant solution to a problem or difficulty. In engineering, a kludge is a workaround, typically using unrelated parts cobbled together. Especially in computer programs, a kludge is often used to fix an unanticipated problem in an earlier kludge; this is essentially a kind of cruft. Those illustrating the tenor of the term often say that it takes a skilled craftsman intimate with the task, the material at hand, and the operating environment to construct a workaround clunky enough to be called a kludge."

From the wikipedia.

Did kde choose this word to indicate why they added Dolphin to kde4?

by Jeroen van Diss... (not verified)

Apparently the startkde script needs /usr/bin/qdbus, which is not provided by the libqt4-core-kdecopy package, which kde4base-dev depends upon :(

Whenever I start KDE4 from /usr/lib/kde4/bin I get the message "Could not start D-Bus. Check your installation."

by Mathew (not verified)

I have exactly same problem. Have you used Xephyr? For me Xephyr just launches new empty window with no way of running any command in it.

by patpi (not verified)

I thought porting to QT4 will increasy speed? It didn't happen? why? I hope it will be fixed before stable relese

btw. other improvements are realy great