Slashdot Mirror
KDE 3.0 Alpha1 Available for Developers
Dre writes: "Just a few weeks after the release of the rock-solid KDE 2.2.1, the KDE Project today announced the release of KDE 3.0 Alpha1. Targeted at developers who want to get a head start on porting or writing applications to KDE 3, the release is pretty much a straight port of the KDE 2.2 branch to Qt 3. However, for developers this brings an impressive array of new features to KDE, including new database classes, new data-aware widgets, improved RAD development with a much-enhanced Qt Designer, a new powerful regular expression class (with full Unicode support), improved internationalization support (including the ability to mix different character sets in the same text), bi-directional language support (for languages such as Arabic and Hebrew), multi-monitor (Xinerama and multi-screen) support, better integration of pure Qt applications into KDE, and hardware-accelerated alpha blending. With the Qt port out of the way, the KDE developers can now focus on the planned
KDE improvements. Read the full announcement here, or go straight to the source
(alternative
link)."
There won't be huge changes because this is only a small improvement. The reason it makes such a large version jump is stay with Qt. Otherwise it would be called 2.3.
That said, I expect that there will be far more new features in KDE 3.0 than what's described on that page. Most likely the developers just haven't bothered to tell anyone about all the new features they're going to add yet.
And with KDE's blazing release schedule, 3.1 will be upon us before we know it, with all sorts of goodies :-)
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
icon server, Waldo Bastian bastian@kde.org
KIO/KHTML: pipelined HTTP requests, infrastructure, Waldo Bastian bastian@kde.org
I think the icon server in particular will help with startup times of KDE apps. The pipelined HTTP requests will make loading of webpages faster.
In addition, a lot of the speed problems actually lie with GCC and the GNU linker, which KDE can't help with. The GCC and ld developers have been made aware of the problem, and a lot of work is going on on their end to speed up the dynamic linking of C++ programs. Once these optimizations start making it into stable releases of the linker, KDE will be much more responsive.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
About the icon server: Currently each KDE program that wants an icon (every one) goes and checks each directory where that icon might be found (of which there are a lot, KDE has a very customizable icon system). The icon server would catalog all the icons available on startup and serve them to the programs that need them whenever they ask, preventing a lot of disk reads. I think that's the basic idea.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Better (full) PNG transparency support in the browser
Alpha-blending for all icons everywhere to reduce jagged edges (especially for small icons)
Neat eyecandy effects
What I'm interested in is what happens when Render isn't available? Do all those effects go away cleanly, or do they stay there using slow software emulation?
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Back when it was KDE 1 vs Gnome 1.2, I used Gnome... or bits of it. For ages I used Sawfish on its own, back when it was called Sawmill and wasn't the Gnome default window manager. I always hated GMC, and didn't use the panel much... so my use of Gnome was mostly restricted to the applications, and most of those (Gimp, XChat, ...) were GTK+ rather than Gnome.
Once KDE 2 came out, I found myself using Konqueror more and more, plus Konsole, mostly because of the tabbed MDI interface it has (which is wonderful). From there it was a small step to actually running the whole KDE desktop -- I even got used to the KDE window manager, although it still feels a bit clunky in comparison to Sawfish (I see that KDE 3 will have active desktop borders back again though, which is wonderful).
Of course, I can still run all the same GTK+ applications I used to use, and they work just as well. Kate, Konsole and Konqueror are the killer apps for KDE, plus the way it all feels much more integrated together than Gnome does (although it has the better individual applications).
I've always thought this Gnome vs. KDE thing was about as dumb as vi vs. emacs.
And it'll keep on going just as long as vi vs. emacs...
-- Help Digitise the Public Domain at DP.
What I've used:
:).
KDE 1.0 vs. Nothing: KDE 1.0
KDE 1.1 vs. Nothing: KDE 1.0
KDE 1.2 vs. GNOME 1.0: KDE 1.2
KDE 1.2 vs. GNOME 1.2: GNOME 1.2
KDE 2.0 vs. GNOME 1.2: both (but more GNOME 1.2)
KDE 2.1 vs. GNOME 1.2: KDE 2.1
KDE 2.2 vs. GNOME 1.4: KDE 2.2
KDE 3.0 vs. GNOME 2.0: I probably will use KDE 3.0
Frankly speaking, both DE's are good, but I like KDE better since 2.0. Right now, I prefer KDE a lot more than GNOME. It's more mature, more stable, and has more features that I want and need. The only downside I can think of with KDE was the lack of eye candy and customizability. But, KDE 2.1 and KDE 2.2 really seemed to fill in the gap. KDE 2.2's panel is about as customizable as GNOME 1.4's panel. The theme support is about the same (although there is nothing like the KDE Liquid theme, with transparent menus, shadowed text, and strippled window backgrounds for GNOME). I think that the rest of the "look" aspect is better for KDE. It has builtin antialiasing (gdkxft for GNOME doesn't work for everything). I also like the alpha transparent icons in KDE. I think KDE 3.0 will really shine because of the builtin xrender support in Qt. This should allow stuff like truly transparent terminals and windows
KDE also seems to be faster in some areas (Konq. vs. Nautilus, for example). Most of the rest of speed is about the same (provided kde uses objprelink). Application support is about the same.
I think that the biggest thing going for KDE is probably that it is a lot more intregrated than GNOME is. I think that that's what a "desktop environment" should be, after all.
No, actually almost all cards in XFree 4.1 have xrender support. And so has the closed-src NVIDIA driver for almost 8 months now.
Don't forget the coolest feature of KDE file dialogs: bookmarks.
The GNOME file dialog is a royal pain to use. It's ugly (layout and widgets) and has no useablity features. I find myself frustrated whenever I use it.
Mac OS X has a web sharing feature, but it simply fires up Apache (with some nice reasonable defaults). That's probably the best approach.
This space unintentionally left unblank.
> KDE programs are ./configure --enable-final
> very slow to compile
use
this reduces compile times by more than half, in my experience
> and load.
Use objprelink.
> but the point is that KDE is a hell of a lot slower than GNOME.
From what? Load times? Look at other big applications written in C++ and compiled in g++, like Mozilla and OpenOffice. They tend to load slow too. If you actually look at speed of applications, KDE wins hands down. Konqueror versus Nautilus. Konqueror wins. KOffice versus StarOffice/OO, KOffice wins. Other components tend to be around the same speed.
> So, from my perspective, which is not that of a compiler designer, GNOME is a lot freaking faster than KDE.
Yeah, "ordinary users" don't even compile KDE or GNOME.
The pre-linking relies on the fact that once libraries are loaded, they never move in memory. That could be a false assumption, but the gcc team is going to great ends to make sure it isn't. The issue as demonstrated is that 'helloworld' will be much larger, and much slower to load when it links against the QT libraries (or any large set of libraries). Thus, similar performance is lost when starting KDE applications linked against the QT libraries simply because they are all loading the QT library linkages.
kwin is fully scriptable. It has a full dcop interface. And so does almost every KDE application. And you don't even need to know lisp, since you can intregrate it with __any__ language, as well as shell scripts (through the dcop command). Kwin can also be styled and theme much more than sawfish because of kwin's engine theme support, written in C++. For example, you could embed a khtml widget in the titlebar to display a webpage. Lets see crazy stuff like that with sawfish :). Since kwin's engines are in C++, kwin also happens to consume a lot fewer resources because it does not use a much slower lisp interpreter like sawfish.
if still like sawfish, you can use it with > KDE 2.0. sawfish is fully compatible with the NETWM spec which GNOME 1.4 has recently adopted and KDE has since 2.0. I've used sawfish in the past too, but I gotta say that kwin simply r0x0rs.
I'm the author of kpf.
It's not supposed to be a fully-fledged webserver. As the comment says, it's designed for sharing files (e.g. with people you are chatting to on IRC.) It just happens to speak HTTP, because firstly that makes it easy to grab files (kfmclient copy http://some.server/some.file file:/tmp/, or wget if you fancy) and the HTTP protocol is a lot simpler to implement than e.g. FTP.
Simplicity of implementation was a major factor in choosing a protocol because kpf must be secure. The less code, the easier to audit.
Note also that the 'real' web servers are not easy to monitor and control in realtime. Because kpf runs as a panel applet, you can watch the connections and the traffic, and even kill off connections if you don't like what they're doing.
You would be surprised how much traffic kpf can handle without threads, subprocesses, etc. - and running within the same process as kicker - all without slowing down kicker.
The home page is here if you'd like to take a look at the current version (which is for KDE 2.x)
RikI thought they decided Woody was going to be 3.0.
"The code name for the next major Debian release after
potato is ``woody''. This release will be
numbered ``3.0''."
http://www.debian.org/releases/testing/
You sir, are one of three things: ignorant, a troll, or an idiot. KDE is entirely built on components, and I can swap them in and out and upgrade them and advance functionality without upgrading the whole.
Which brings up an important point - 3.0 should look just like the existing 2.2.1, with no new (user) features. The major number bumped up *because* of the component nature of KDE - the new version is the exact same (on the front end), but is binarily incompatable with 2.x. The back end gives advances that will allow the 3.x line to advance quickly on the front end.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Most of my expertise falls into software development in Java, but recently I have been pushing myself to do more C++ development on Linux. I don't want to rely on proprietary languages. Anyway, the modern C++ is far far different from the C++ of many years ago. Things have changed, and C++ is growing up. Sure its a very complex language, if you try to learn the legacy aspects of it, but if you stick to the core OO constructs in C++, then you have a nice efficient programming language.
I am coming to realize that Java has very little over C++. Garbage Collection is more of a buzz word than an actual worthwhile feature, and it should be noted that high-level memory leaks are still possible in Java. Sure they are memory leaks of a different kind, but unreleased yet unused memory is a big problem in many large Java software systems.
In addition, for even an intermediate software developer, how difficult is it to code your own destructors? I mean, really, at worst you have a few loops in a destructor. Anyway, most JVM garbage collectors are unpredictable and hog performance at the worst of times.
The most important thing that Java has over C++ is a comprehensive set of user-friendly yet powerful APIs. But in return, C++ as templates and STL, allowing for elegant generic software systems.
When it comes down to it, C/C++ are here to stay, until some real yet practical innovation in Functional Programming languages, mobile/concurrent languages, or Declarative Programming languages is made. I am all for newer better higher-level programming languages such as Haskell, Pict, Lolli, and Mozart-Oz, but Python, Ruby, C#, and other newer procedural/OO languages are not the revolution, they are not the future, and at best, they are nothing more than slight iterative improvements on an overused overdone, and over talked about paradigm.
Give me C, give me C++, and if you can, why don't you give me something new for once? I am tired of the same old Ford Tempo with a new paint job and a new name.
KDE should consider using a interpreted language for desktop productivity apps exactly one year after Microsoft does. Try again in 2005.
Have you ever right-clicked on the file name input widget? It says right there: "Completion: (none, manual, menu, automatic, short automatic)"
This goes for EVERY input widget that accepts URLs. Not only for file dialogs. KDE rocks. :-)
Home Page