KDE 3.3 Release to Coincide with KDE Community World Summit

What an exciting KDE summer! Release dude Coolo is planning the KDE 3.3 release for just 3 days before "aKademy" starts: The release plan was published on Saturday for discussion! Developers should make sure to get the stuff listed they plan to have ready for 3.3 in the planned-features document as soon as possible. KDE 3.3 Alpha is prepared around May 23rd and June 1st will see the first freeze (excluding outstanding listed features and i18n strings) kicking in.

Dot Categories: 

Comments

by Lou (not verified)

XML error on the planned features pages!

by Andras Mantia (not verified)

Sorry for that, I corrected in the same minute I noticed...

by TXLogic (not verified)

I'm still seeing:

XML error: not well-formed (invalid token) at line 1293

by Nicolas Goutte (not verified)

Indeed, the document had still a XML syntax error.

I have just fixed it.

Have a nice day!

by Prast (not verified)

I cant seem to save one of my MSN chat log, it is in XML form, only one person, the rest seems no problem) The error message said.. "Invalid Characters in Line 4...." What does that mean and how do I fix it? Help...

Thank you
Prast

by AC (not verified)

Does anyone have more details on the Quality Feedback Agent? Will it be similar to mozilla's talkback?

by Daniel Frein (not verified)

I hope that there will be a working pdf viewer in kde-3.3. With kghostview I can't print about 80% of my pdfs (bug 61922 "null setpagesize", open since 2003-07-31). And kpdf is unusuable in most cases (some graphics are upside-down, troubles with included fonts, hyperlinks are drawn as huge black boxes, very slow,...). I haven't noticed any improvements in the last half year. Not everyone works with pdfs every day, but if you do, you still need acroread...

Daniel

by chris (not verified)

looks like they need people for kpdf. please apply :-)

btw. very nice , congratulations for that fast release cycle.

after 3.3 is there a major rewrite for qt 4.0 ?

chris.

by Thomas (not verified)

I can recall when kghostview was not working for me too because of the pagesize-bug, but I thought this bug was history...
Problems with kghostview may also originate in ghostview itself. I'm using gs 7.05.6 over here and have no problems with viewing pdfs in kghostview at all.
(Though I can confirm that kpdf is unusable at its current state)

If you have a lot of encrypted pdfs ghostview may also fail. Do you notice any differences when opening the pdf with gv?

by Daniel Frein (not verified)

I always thougt that this bug was directly related to kghostview. But you're right, it is located somewhere in gs. The postscript files created by kghostview, gv and pdf2ps are identical. I'm using gs-gpl 8.01 and gs-common 0.3.5 (debian sid).

Daniel

by Asokan (not verified)

Among the kviewshell components kdvi has of late gained
major performance boost. Can't these improvements be
made to other components as well ?

by Nobody (not verified)

Or better yet move everything to/as gv-backend (fork for kde) and then make all apps like kpdf/kghostview/kdvi use it (until merged in to a single frontend for kde-4.0)? ;-)

by MandrakeUser (not verified)

Dear Friends, I love KDE, it is my only DE. I think the internal architecture
(in part thank to Qt) is just outstanding. This is clear when you see how well the component model works (things like DCOP and all)

The 2 fronts where I think KDE can get stronger are Usability and Consolidation.

USABILITY: It would be great to prioritize the Usability project,really. Some things can be much more user friendly:

1) Config menues: add consistently (through the apps) an "advanced options" button, and just leave a few relevant options for the "regular user". As an example, take the config dialog in Konqueror, there are so many options that it is overwhelming. It takes me quite a bit of time to navigate through them and I am a nerd ;-)

2) File associations: they really are hard to set up if you don't know exactly what to do. There is no waay to fall back to "defaults" for instance. This is another functionality that should always be available I think: a "Defaults" button.

CONSOLIDATION: Some areas are nicely coordinated (Office, recently PIM, etc). But things like multimedia need some consolidation. There are several audio apps, some of them overlap, some of them are hardly useful, I think that some integration and consolidation is needed. There should be one killer Photo program (digikam for me ;-), one killer media player, etc. I end up using Noatun for some things, real player for some others, KMplayer for others ... it's all good but integration would be better :-)

Just my 2cts thinking of the future. And yes, I love KDE, and I find it better than any other GUI I ever used, including windows :-) (never tried MacOS)

by JeroenV (not verified)

1) Config menues: add consistently (through the apps) an "advanced options" button, and just leave a few relevant options for the "regular user". As an example, take the config dialog in Konqueror, there are so many options that it is overwhelming. It takes me quite a bit of time to navigate through them and I am a nerd ;-)

Many configurable options aren't a real problem IMO, as long as the options that matter are in the first few screens. AND the options are linked to that program only.

E.g., what I would like to see is a distinction between the Konqueror File Manager configuration and the Konqueror Webbrowser configuration. The Control Center allready has this distinction, it would be better IMO if the app itself had this too.

by Ian Whiting (not verified)

If KDE is going to be taken seriously by the majority of business users then things do need to be simplified for the average user, and that does mean hideing advanced options that only IT professionals use. This could mean that there are specific tools for configuring advanced options (other than a text editor on the configuration files).

by Datschge (not verified)

If business users take IT seriously enough to employ a decent IT staff they are already today able to take advantage of KDE's high configurability which allows administrators to easily adapt KDE to specific use cases by fine tuning and locking down parts or all of KDE's user interface. The keywords are KXMLGUI and KIOSK. (And that all is completely independent of whatever KDE itself decides to do for simplifying the defaults for average users, something which shouldn't be of any concern to any serious IT staff anyway.)

by Tom Chance (not verified)

If you're interested in talking about these issues more, you might consider getting into one of these two projects:

KDE Quality Teams
Do as much or as little as you want talking about both issues, either just in one module (e.g. talk with users and developers more about consolidation in kdemultimedia) or generally.
http://quality.kde.org

KDE Usability
It's quite high-traffic, but if you subscribe with digest mode on (as I have it) you get one or two e-mails a day, and can talk with other usability people and developers directly.
http://usability.kde.org

by Manfred Tremmel (not verified)

To the Point Media-Player: Do you have tested Kaffeine? SuSE uses Kaffein as default player since 9.0, TurboLinux sells it as DVD Player. It plays nearly everything (based on libxine) and is great integrated in KDE/Konqueror (parts plugin) and other browsers (browser plugin) and the gui is much more powerfull then the lightweight KMplayer.

by rb (not verified)

I'm most interested in the ruby bindings. Won't it be released "officially" in the 3.3 packages?

Raph

by David (not verified)

From what I've seen all of the bindings have come on leaps and bounds. I'd be surprised if Ruby wasn't in the 3.3 bindings release.

by Richard Dale (not verified)

QtRuby and Korundum weren't built by default for KDE 3.2, but they will be for KDE 3.3.

The basic bindings for Qt/KDE are complete, and the rbuic tool works with KDE widgets. KDevelop has some ruby support; with ruby class browsing/syntax highlighting, and Marek Janukowicz has recently added a QtRuby template.

Here's a list of a few further things to do (anyone like to help out?):

- More code samples, particularly KDE ones
- Qt Designer plugin
- Kate ruby plugin
- KDevelop Korundum project template
- More documentation
- Set up Korundum site on rubyforge with a release
- Online tutorials
- KDevelop Korundum project template, debugger front end etc
- Extract KDE C++ doc comments from kde headers and convert to RDOC format
- RubberDoc documentation browser (Alex Kellett)
- Release Announcement (eg 'KDE Ruby bindings now official!')

I'm sure a killer RAD environment isn't that far off..

-- Richard

by Christian Loose (not verified)

Will the ruby bindings (Korundum) contain only stuff from kdelibs or will it also contain non-core libraries like libkcal? Or asked differently, how hard would it be to generate those bindings and ship them with an app?

Christian

by Richard Dale (not verified)

Korundum only contains stuff from kdelibs (and Qt). It is driven by the file kdebindings/smoke/kde/kde_header_list, and so you might just need to add the libkcal headers to that in order to add them to Korundum (and link libsmokekde against libkcal). That would allow you to try kcal ruby programming. But does it have any of its own namespaces? If so, they would need to be added the QtRuby runtime which would be extra work, although not much.

The current version of the SMOKE library is a bit monolithic, and so you either have to add classes to the Korundum extension or not at all. It isn't possible to have a kcal specific extension that could be used in conjuction with Korundum. This is because in SMOKE v1 each method is identified with a short integer. In SMOKE v2 the methods will be indentified with a URI which should make it more flexible.

by Boudewijn Rempt (not verified)

I did a little experiment with the Java bindings yesterday, and I was quite impressed. It's actually possible to create a Qt app in Java, and compile that to native code with gcj. See my writeup at: http:/www.valdyas.org/fading/index.cgi/hacking/gcj.html?seemore=y.

by Richard Dale (not verified)

Just had a look - good work! Thanks for spreading the news that there are viable Free Software alternatives to Sun's jdk. I agree that gcj and the java bindings are a really good combination too - I think gcj is a really underrated project.

Note that you can use the interpreter 'gij' that comes with gcj too. I've found that works really well with Qt or KDE java programs; they run fast because they spend most of their time in the kde or qt libs which are native code.

You can compile qtjava.jar to a library called 'lib-org-kde-qt.so' and gcj or gij will use that in preference to qtjava.jar. But I've found the libraries are a bit large relative to the speed up and perhaps it's more trouble than their worth.

by Boudewijn Rempt (not verified)

Yes, I first used gij to verify it all worked, and then slowly worked up towards an optimized binary... Is there a special reason for the naming of the shared library? I just named it qtjava.so...

by Richard Dale (not verified)

You need to name the compiled qtjava.jar 'lib-org-kde-qt.so' so that gcj/gij can search for it when resolving 'import org.kde.qt.*' in your program. It just extends the idea of .jar files to include compiled .so libs. If the directory containing 'lib-org-kde-qt.so' is on your LD_LIBRARY_PATH, it is exactly equivalent to qtjava.jar being on your CLASSPATH.

If you name it qtjava.so you can only use the lib by naming it in a gcj compile command, and not as a qtjava.jar replacement as above.

by Zoltan Bartko (not verified)

Do I understand that well? Does it mean that I could actually develop my app faster in java with gij and when I would be satisifed with the result, just let it through gcj? Or is there something else to know about this?

Zoltan

by Richard Dale (not verified)

Yes, you can use both gij and gcj, but I've found nearly all QtJava and kde koala java apps run quite fast enough using gij. I think you'd only need to compile to native code with gcj if your app is graphics intensive. On the other hand, with Swing nearly all the code is java, and so it makes much more difference whether or not you have a jit compared with just ordinary slow interpreted code.

by Boudewijn Rempt (not verified)

Yes, that's what I set out to discover. I have a vague intuition that applications somehow find easier acceptance if they're native code, instead of any kind of bytecode. Richard is right, though, for the actual performance there's not much difference, perhaps because qtjava uses JNI, and Mark Wielaard tells me that for every JNI call, gij is called to generate some bytecode, which is then executed. Things could be faster, he tells me, but I think it's plenty fast enough. Although I noticed that putting a simple QMainWindow on screen is a lot faster with qtjava compiled to native code using -O2, than it is without optimization or in bytecode.

Also, I've checked Richard's other remark -- about the name of the shared library compiled from a jar -- and I was told that the difference is not that when the shared library has a name that doesn't reflect the package is contains, the java jar is used, but that when it's named qtjava.so (for instance), the ordinary dynamic linker is used, but when it's named org-kde-etc.so, the bootstrap classload is used; but in both cases it's native code.

Anyway, my next target is to find out how to create a library using java, compile it natively, and call that from C++. I think java is especially suited to appliation cores that handle data structures.

by Roberto Alsina (not verified)

I´m impressed :-)

More people should write like this, what they do, and what they find cool about KDE.

I try to do it but I´m not doing much ;-)

by dizzl (not verified)

I think shorter release cycles like this (6-9 months max) are very good to keep the developer and user communities active. Keep up the good work!

by Richard Moore (not verified)

They're good for the user community, and bad for 3rd party developers. A balance between the two is needed, and the right one is hard to find. Sadly, nothing worth while is ever simple.

by Annno v. Heimburg (not verified)

It's not that bad if binary bakwards compatibility is ensured, i.e. the app I wrote for 3.0 will still run under 3.3, no recompile. New releases every 6 months wouldn't bother 3rd-party-developers then. However, major releases (3.x->4.x) should not occur more frequently - 2 to 3 years in-between seems good. So then, we'ld have to get used to version numbers such as 3.6

by Tom Chance (not verified)

Except that, as I understand it, KDE 3.3 will be the interim release before 4.0, giving KDE developers and users a chance to pack in lots of new application features and underlying refinements, while the developers plan for more extensive changes, e.g. moving from DCOP to DBUS.

Though binary compatability may break, it should still be relatively easy to "port" code across to the new architecture, however, since it's a fair assumption that the technologies will remain backwards compatible (e.g. apps using DCOP will still work).

by Richard Moore (not verified)

Yes and no. The API will be compatible, but apps that don't use the new features may look a bit dated in comparison to things that use the shiny new features. It's not a major problem, but it can irritate people.

by Erich Vinson (not verified)

I am hoping for the new kde-pim release sooner than later. The promised features like Groupware integration, HTML mail editing, etc. will push KDE over the top.

I am also SO looking forward to the bugfixes like the kate bugs, the klipper freezing kicker, etc.

BTW I like the shorter release cycle. Keep up the good work!

by David (not verified)

"I am hoping for the new kde-pim release sooner than later. The promised features like Groupware integration, HTML mail editing, etc. will push KDE over the top."

Yer. The groupware stuff looks incredibly good.

by Kolbjørn Barmen (not verified)

Ah yes, HTML mail editing, so that all KMail user's mails end up in my spam folder too. Lovely :)

by Anonymous (not verified)

All? It will not be the default.

by zammi (not verified)

I like to see future releases of KDE include patches to give both Qt & Gtk apps same look & feel. Sometime I feel odd to see different many look & feel within same desktop env.

by Nobody (not verified)

Or other way around with ?

by MM (not verified)

"Make kdebase compile (and run) without dependencies on X11"

As far as I know, ksmserver needs X for session management functionality of KDE, and ksmserver is included in kdebase, I think.

Same for DCOP, which I assume is part of kdebase and also depends on X.

While I can imagine a KDE without session management, I can't in case of DCOP. Will DCOPs dependence on X be removed (by what=, or is DCOP replaced with DBUS in KDE 3.3? And how will the session management thing be handeled?

Or am I completely wrong with my assumptions?

by Thomas (not verified)

Isn't it merely based on libICE? Sure, libICE is an X11 lib. Don't know if it's possible, but can libICE be replaced by something similar? Well, just guessing... maybe I'm talking nonsense

by Roberto Alsina (not verified)

No need. libICE doesn´t require X at all. It just comes with it, but you can use it in CLI apps or whatever just fine.

I knew about libICE but wasn't aware that though it is part of X, it does not depend on it. Thanks to both of you.

by Norberto Bensa (not verified)

> NEW IN KDE: Import Noia Icontheme....

Oh C'mon!!! That's like 14MB more to kdeartwork tarball!

by Alex (not verified)

Noia is really an original and beautiful icnonset. I do not mind the increase at all.

by Norberto Bensa (not verified)

You would if you were on dial-up

by geert (not verified)

Will the open sourcing of the evolution EXchange connector impact on this?

Is this usefull vor kontakt?