KDE at LinuxTag 2005: Summary and Technologies

As LinuxTag 2005 is over, many KDE contributors went home to implement ideas
that were discussed during the event. In case you got lost among all of the
announcements, here's an easy-to-click-through list of new features.
Before reading, you might want to have a look at the pictures, and there are
now more added daily to the community photo list.

Let's start the list with the announcement of probably the biggest impact,
the cooperation between
KDE and Wikipedia
. From community news sites like Pro-Linux
to Slashdot and technical mailing lists such as
debian-edu discussions sparked and
led to first improvements
in the source code.

A related topic is the introduction of web services into KDE. Some development code already exists
for the Desktop Exchange Service (DXS), a web service transport
to be included into KNewStuff, and Kung, a KDE frontend for dynamic web service navigation. Find out more
at the web services section on KStuff.org.

During the booth service a lot of new potential contributors presented themselves to the project,
especially in areas where there is a need of such, like the
German translation team. As the demopoints were equipped
with SUSE Linux 9.3 and Kubuntu, and we distributed about 500 Kubuntu CDs, many old and new users of
KDE 3.4 told us of ideas of improvement, some of which are already implemented, while others will be soon,
as is the case with KDE 4 multimedia.

The involved KDE contributors would like to say a big thank you to:

  • Iiyama, who lent us 4 large displays
  • Transtec who helped us organising the hardware
  • credativ who helped out a lot, including transportation
  • Canonical for sponsoring the Kubuntu CDs
  • LinuxTag e.V. for making the event possible
  • joey, the diligent guy who managed all free booths
  • and finally KDE e.V. for backing the organisation.
Dot Categories: 

Comments

by gerd (not verified)

What software does the dot use and is it open source?

by Anonymous (not verified)

Easy to answer because it's written on dot.kde.org: "KDE Dot News is based on Squishdot which runs on Zope using Python technology."

by gerd (not verified)

Okay, squishdot, will have a look.

There are two wonderful sites, Prolinux and KDE-Dot.

by macavity (not verified)

I'm very glad that you made the design decisions for KDEMM that you did. This really looks like no-nonsense development to me.

Pros:
It's advanced enough to be actually usefull.
It's not just the knotify-must-have-hack it initially sounded to be.
It's lightweight enough to be fast (depending on backend that is).
It looks much more cross-platform freindly.

Cons:
Cons?!?... We don't need no stinkin' cons! ;-)

Thanks in advance! I just as excited about KDE4 as I was about KDE2.. Which says a whole lot! :-)

~Macavity

by Robert (not verified)

Cons: It's an abstraction library around... an abstraction library.

by Vir (not verified)

And that is negative because...?

Actually for many media frameworks it would make sense to provide a layered API themselves, because the "low level" API that media frameworks provide give most developers more freedom and possibilities than they need. Another API layer above that can make usage of the media framework a lot easier without a noticable performance loss.

But of course that all depends on what you want to develop. And that's why KDEMM doesn't target pro-audio application developers.

by Scott Wheeler (not verified)

Actually that's what most libraries are. It's not like most software is designed such that you have exactly one level above the hardware.

Let's look at the drawing portions of Qt:

Hardware -> Kernel Driver Collection -> Device Abstractions -> Xlib -> Qt (oversimplified with a few levels missing)

I'm not advocating needless levels of abstraction, but you need to consider who your API is for and create an API that fits your target audience. We never debated if we'd have a "KDE abstraction" for KDE 4 -- the debate was simply if that would be a binding to a specific backend or if it would be a more generic wrapper.

by martin ben (not verified)

Well, the whole translation framework came to a standstill, no real innovation, no real infrastructure that scales. Recruiting new translators had obviously low priority. So it is very nice to see the Germans acting here to get more people on board.

by Corbin (not verified)

I'm looking at the KDE Multimedia Roadmap (server seems really bogged down right now), and noticed it was made in KPresenter. I never realized how nice the pages it made were (when exported to HTML)! Much better than that abomination that PowerPoint outputs!

by macavity (not verified)

Uhm.. the main picture is just a jpeg. I don't even think you kan make something that good looking in straight html (that is: without using tons of smaller bitmaps or svgs)

But yes, it struck me to how nice looking it all was :-)

>server seems really bogged down right now

The point of KDEMM is not to be the all-singing-all-dancing-multimedia library, rather to be simple but effective for everyday small and medium tasks. Stuff that goes beyond this should either use the common libs in the kde-multimedia package, or do it them selves (like amarok). The latter wont be nearly as cumbersome when aRts doesnt lock up the device for apps who wish to talk directly to ALSA/OSS/SunSound (or what its name is)

~Macavity

by macavity (not verified)

dooh.. wasnt quite awake there X-/

by Vir (not verified)

> server seems really bogged down right now

Yes, that's an old 200MHz Laptop with 64MB of RAM on a DSL line with 128kBit uplink. I wasn't prepared for that much publicity. :-)
I'm looking into it and might need to replace that memory hog of apache2 with something lighter. But I actually don't really understand why it is that slow because the load average is around 0.1.

BTW, those slide images were originally PNGs (6MB). I changed that to low compression JPEGs (2MB) and moved them to my Uni's webspace (else my server probably wouldn't even be reachable for you anymore).