Preview of KDE 3.4

comforteagle writes "In this month's KDE: From the Source George Staikos details what is to be expected from the upcoming 3.4 version of KDE. An Alpha release is due any minute so you might as well know what you're in for if you're a loyal K head. Some changes include major rework within KHTML & Konqueror, Subversion support, and Apple's Rendezvous."

Comments

Article text.....

[B5_geek]

Incase of slashdotting:

KDE 3.3.2 was tagged today, so we should see a new bug fix release of KDE in the first or second week of December. Earlier this past week, the plans for a KDE 3.4 release were also finalized. This will be the last major KDE 3 release before KDE 4. KDE 4 will make use of the Qt 4 library which promises to be quite a revolution for KDE and all Qt applications, but will break binary compatibility with previous releases.

The release schedule for KDE 3.4 plans for an alpha release December 3, a beta release January 7, and a final release March 16 2005. The 3.4 release will bring a large number of features and functionality enhancements over previous KDE 3 releases. Here are some of the features already implemented:
Hardware Support

- Support for special keyboard keys on Dell Inspiron and ASUS laptops.
- A new battery monitor (under development).
- media:/ addition to the KDE I/O subsystem to list devices on the system.
KHTML and Konqueror

Konqueror

- KHTML has undergone major work lately, though much of it will appear in KDE 3.3.2. Merging with Safari fixes continues, alone with new work and fixes by KDE developers. Site compatibility continues to improve, stability is very much improved, and KWallet no longer blocks Konqueror while waiting for a password.
- Support for multiple site logins with KWallet (for all protocols, but not HTML form completions yet) added.
- A notifier was added to visually indicate when user-agent spoofing is active.
- KHTML plug-ins are now configurable, so the user can selectively disable ones that are not used. This does not include Netscape-style plug-ins.
- Netscape plug-in in CPU usage can be manually lowered, and plug-ins are more stable.
- Over the past couple of months, confirmed KHTML and Konqueror bug reports have been on a significant decline as bugs are fixed more rapidly and fewer are reported.
E-Mail and Personal Information Management

- Major improvements in synchronization, including support for synchronizing between two PCs.
- Enhanced support for groupware servers, including Exchange 2000, OpenGroupware, Kolab 1 and 2, SLOX, Groupwise, and eGroupware.

SLOX

- XFace support for associating faces with mail and news articles.
- Blogging and journal support.
- KMail supports KWallet.
- Client-side IMAP search support.
- Improved drag and drop in KMail.
- Improved anti-spam support in KMail.
- Uncountable other e-mail, organizer and address-book enhancements.
Kopete

- Novell Groupwise and Lotus Sametime protocol support added.
- Support for adding URLs to bookmarks.
- Drag and drop of files and contacts.
- The NetMeeting plug-in now allows the use of arbitrary applications to start a chat.
- Support for incoming MSN messages that are handwritten.
- An adium look-alike chat window style.
KPDF

- KPDF includes new numerous new features including:
- New rendering engine.
- Optimizations and enhancements for zoom, search, and thumbnails.
- Better printing (using Postscript directly).
- Support for password protected PDFs.
- Image extraction support.
- Nicer user interface in general.
Libraries

- QCA - A complete cryptography architecture.
- Usage of GCC 3.4 symbol visibility functionality for much improved application startup time.
- Optimizations of various styles and other components.
- Cleanup and reworking of KJSEmbed to make it much more functional.
- Password dialog gives feedback on the relative strength of new passwords.
Desktop / General

- KDM theme support.
- Numerous window manager enhancements, including indicators for remote applications.
- Major Kicker panel reworking, with support for hiding tray icons.
- Empty password support (password-less wallets) in KWallet.

KWallett

- Support for setting the clock with NTP.
- Completely redesigned, more flexible trash system.
Other Cool Things We Might See

All of these feature

Real Window Managers

[SlashdotMirrorer]

I know I'll probably be modded down as flamebait for promoting alternative window managers in a KDE message thread, but I think it might be a good time for the every day user to take a look at how bearded terminal hackers are making things more efficient. Many "LINUX power users" are making their every day work more efficient by using and developing great window managers such as EvilWM, which I am currently typing this post up in.

Maybe a grassroots movement towards simpler window managers is in order. This would be a movement similar to what Bruce Perens trailblazed for GNU/Linux back in the early nineties to fight the onslaught of OS2 and Win 3.1. Now that we have a stable system to build upon after all of these years, we should concentrate on a good user interface. Not necessarily a Desktop User Interface, but a thin, lightweight interface that allows the user to more efficiently do their work without any messy cognitive analogies.

Re:Real Window Managers

[zenmojodaddy]

Good call. The problem I have with both KDE and GNOME is that some packages offered as part of the desktop are so dependent on various other components that they're unusable on their own. I don't use GNOME at all but have had to install the full shebang when I install Slackware, because working out the various dependencies for a few packages is just too much work.

If Microsoft integrates a browser with a file manager, or hints at integrating a media player or anything else in the OS, everyone cries foul, so why is that considered good practice in the major *nix environments?

I'd much rather see a truly modular system, so the the user is free to pick and choose a window manager, a file manager, a browser, a messenger etc. and have them all play nice together, regardless of whether they are part of KDE or GNOME or standalone projects.

For the record: Slackware, Fluxbox and ROX-Filer all the way, baby.

Re:Real Window Managers

[a_karbon_devel_005]

Bleh.

1) KDE != WM. Repeat after me: "KDE IS NOT A WINDOW MANAGER." It's a desktop environment and it does way, WAY more than a simple WM. God it's 2004 people, HAVE YOU NOT LEARNED THIS YET?

2) The IMMENSE proliferation of small, lightweight WMs has ALWAYS been active in the Linux community. EvilWM, IceWM, TWM, BlackBox, FluxBox, Waimea, Kahaki, etc. etc. etc. There is really NO NEED for any more WMs to "get back to basics" THEY'RE ALREADY OUT THERE. Most of them are damned good as they are. Real users want MORE features at this point, these kind of posts are just counter productive. It's 2004. People want to USE the 2.4Ghz 64 bit Athlon they just bought (for cheap). Mom doesn't want fluxbox, she wants her computer to put up a little CDROM icon when she inserts one into her computer. Congrats KDE team on making an efficient, fun, functional DE.

Re:Real Window Managers

[SyntheticTruth]

"If Microsoft integrates a browser with a file manager, or hints at integrating a media player or anything else in the OS, everyone cries foul, so why is that considered good practice in the major *nix environments?"

But KDE *does not* tie the browser to the OS, it ties the browser to the *desktop* and there is a *HUGE* difference in that. I can't think of any part of Konqueror that directly makes calls to kernel functions (though admittingly I have not dove deep into the code.)

MSIE is a beast that is *tied* to the kernel, uses kernel internals, and thus, is bad. I have yet to see *any* *nix desktop/window manager that does such a thing.

Re:Real Window Managers

[Hatta]

The problem I have with both KDE (which I use) and GNOME is that they both require that ancient bloatware package known as "The X Window System."

X is not bloated. It's the toolkits. Try running a lightweight window manager (fluxbox, icewm, etc). It's damn snappy. X can run on the most minimal machines and even PDAs.

How often do you need to run an X app across the wire?

Every day. X needs better network transparancy, not less. Keep in mind that for local delivery, X uses unix domain sockets which impose no observable overhead.

How many times do you need to support multiple displays and screens

Again, every day. And again, if you don't use them, it doesn't hurt you any.

(OK, this is slashdot, so I know some of you do -- I have myself, but it's very rare).

What's next then? X is slow because of virtual desktops? Makes about as much sense as your other objections.

Re:Real Window Managers

[cortana]

An app that didn't make any calls to the kernel wouldn't be able to do much...

To see what system calls Konqueror makes, run 'strace -f konqueror'. This won't catch them all, of course, becuase KDE relies on other processes to do a lot of its work. You can start an X server with xterm as the only client, and do 'strace -f startkde' to see the lot.

Of course, one can always apt-get remove konqueror if one doesn't want it installed, the rest of KDE will not stop working. Try that with Internet Explorer. :)

WRT to MSIE using 'kernel internals': is there actually any documented evidence of when/where/why it does this? Internet Explorer probably uses the "Native API" *less* than a typical Unix process would use system calls; where Mozilla would open(2) a file, IE would call the OpenFile Win32 API, which would be handled by the Win32 server (csrss.exe, IIRC).

Re:Real Window Managers

[Coryoth]

The problem I have with both KDE (which I use) and GNOME is that they both require that ancient bloatware package known as "The X Window System."

What, exactly, is wrong with the X Window System? It's not bloat - X gets used on handheld and embedded devices. It's not that the network transparency slows it down - when connecting to a local server X uses shared memory on the machine and doesn't go through any network calls. Speed? Now we're talking implementation issues, but X has been getting better on that front since it finally moved on from XFree86 as the default implementation on Linux. More importantly, in raw rendering speed, X is actually faster than windows. Percieved lack of speed is more due to some lingering X rendering issues (which Keith Packard is fixing), and the toolkits that run on top.

Sure X isn't ideal - nothing is, but it is a hell of a lot better than most stuff out there, and it certainly has many advantages over Win32 GDI.

How often do you need to run an X app across the wire?

Every damn day! Just because you don't use this feature doesn't mean it isn't (a) immensely valuable, (b) used regularly by everyone else. It is not at all uncommon for me to have a desktop full of apps, where each app is actually running on a different machine. X lets me do that, and have a perfetly seamless desktop as if all the apps were running locally. That is a huge advantage.

I'd love to see a thin, fast, cross-platform replacement for X.

X is surprisingly thin - more so than Windows, which has Win32 GDI tied in to everything else. X runs on embedded devices - how slim do you want? X is fast - run some raw render benchmarks for yourself. X is cross platform. I've run X servers on Windows, on Mac, on Linux, on Solaris, on AIX, and on BSD. They all connect to each other happily with no complaints. Show me Win32 GDI doing anything similar.

Jedidiah.

the Devil is in the Details

[DarkSarin]

which is what this article lacks. Don't get me wrong--there is some cool information there, but I want to see screenies of the entire desktop--has that changed much or not?

I would also like more information about the core KDE, not just the peripheral stuff like Konq & KHTML.

All that said, the idea of a new version of KDE is fairly kool, but frankly, as an XFCE user (and occasionally Gnome), I find the KDE desktop & icons to be just a shade on the kludgy side. They don't look as clean or professional in my mind.

But that's just one geek's opinion.

Konqueror + Gecko?

[ScriptMonkey]

Does anyone know if this will include Konquerer with the ability to use the Gecko rendering engine?

Re:Konqueror + Gecko?

[Daengbo]

Using kdebindings you can easily tell konqueror to use gecko instead of khtml

Re:Slashdotted

[Chuck Bucket]

Here's a mirror.

CB

More complete feature plan

[kigrwik]

A more complete feature plan can be found here

Though it's not always up-to-date (some devs prefer pushing their code first, and *then* update the page).

HTH,
Kig.

Re:Rendezvous?

[Sc00ter]

No. Zero Conf is an opensource project that has been around since before Rendezvous.

Rendezvous is apple's version of ZeroConf.

More info on ZeroConf

More inof on Rendezvous

Re:Does it have a proper exchange handler

[Daengbo]

OK, this was a troll, but from here:

Kontact

• Add alternative tab-based viewmode. Daniel Molkentin
• SnapIn/SnapOut actions for changing between an app running stand-alone or embedded in Kontact at run-time.
• Make Kontact (KOrganizer/KMail) work with Exchange 2000. Daniel Molkentin

So I guess that's a "yes."

Re:autorefresh

[nick korma]

are you sure your monitor is not next to a large fan?

Re:IMAP filtering in KMail

[Daengbo]

From here

KMail

• Asynchronous encryption Ingo Kloecker , Marc Mutz
• Namespace support for IMAP Carsten Burghardt
• Using komposer Zack Rusin
• Full text indexing Don Sanders
• Leave on server for x days for POP Don Sanders
• Asynchronous filtering Don Sanders
• Multi/part related mails Don Sanders
• Get rid of mimelib (a.k.a. KMime). Marc Mutz
• Redesign filters to use Sieve internally. Allow editing of Sieve scripts on IMAP servers to get rid of the bug reports a la "KMail doesn't support IMAP folders for filtering" Marc Mutz
• Make the visible headers configurable, allow for "show all and hide specified headers" as well as "show specified headers". Already available as a patch. Klas Kalass
• Rewrite the composer window to drop KEdit and support richtext engines. (old ktexteditor patch available here). See also the new code in libkdepim/komposer Zack Rusin
• Improved configuration of header and attachment views Aaron J. Seigo
• Asynchronization of crypto operations. Ingo Kloecker
• Automatic HTML to plaintext conversion when replying to HTML mails. Don Sanders
• Make use of KWallet. Ingo Kloecker

So...yes?

Obligatory Futurama quote

[RPoet]

I don't say that one has to like KDE, but "I don't like the icons" is not a very godd reason...

Calculon: An Oscar, you say? That would get me out of this festering rat's nest called "television" once and for all. Let me see the script. [Zoidberg hands it to him and he speed-reads it.] No, no I don't like the font.

Re:Rendezvous?

[podperson]

Just to clarify the preceding correction:

Rendezvous and Zeroconf are the same thing, the latter being the Open Source release of the Rendezvous technology.

The ZeroConf page is maintained by Stuart Cheshire, who is the engineer at Apple responsible for Rendezvous.