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)."
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?" `":" #");}
No, Qt have never artifically inflated their version number. The first number changes with major binary incompatible changes to the library, the second with additional features that keep binary compatibility, and the third with bug-fixes. KDE uses this numbering scheme as well.
Just because you might be used to other projects (such as the Linux kernel) completely changing interfaces within minor version revisions, doesn't mean that is how a properly managed piece of software is versioned.
-- Help Digitise the Public Domain at DP.
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?" `":" #");}
Well I use both, usually GNOME more often as I like the look I can achieve with it and pretty much all my favorite programs are gtk+ based, so it's nice having the same look for everything.
But the reason I think a lot of people like KDE is because of the level of integration everything has. It truly is a Desktop Environment, whereas GNOME at this point has more of a "most of the programs look similar" feel to it. Very little seems to be in place for the programs to talk to eachother and work the same from application to application.
For example, in KDE2 every program that opens files (to the best of my knowledge) uses KIO (I'm guessing that stands for KDE Input Outout) and this makes it so you can open and save files from/to anything KIO supports. For example, you can open a file in a KDE text editing program by giving a http url like http://slashdot.org/ (that should give you the source code for slashdot's main page in HTML) then you could then save that file to some ftp site, just by putting ftp://blah.com/incoming/file.html in the save dialog.
That level of integration is all over KDE2 and it really makes for a great experience. There is tons of other stuff too, like how konqueror embeds components so it can display many types of files. In fact, if I'm not wrong, the koffice office suite is made up of components so I think you can view kword files in konqueror without really launching the kword application, just embeds it into konqueror's window.
Lots of other stuff to explore in KDE. For me though I just like the look and feel of GNOME. And I think all those nifty things in KDE give it a lot more stuff that can break (and from my experience it tends to do just that). Of course I could just have bad luck with it, I dunno.
FiGZ.COM - A waste of perfectly good web space
> 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.
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.
By definition, infrastructure should encapsulate every feature that is common to the applications that use it. The problem with UNIX is that such infrastructure is lacking. This has lead to a situation where in order to be able to compete with ms windows (which does have such infrastructure), applications have to include everything and the kitchen sink. Look at star office, it comes with its own widgets, its own printing subsystem, its own way of embedding components and until the recent beta it even came with its own desktop. Sure it is integrated with Gnome/KDE to some extent but since it also needs to be portable across the two it contains a lot of duplicated functionality.
KDE developers have understood this and are currently working to deliver such an infrastructure. Ignorant critics complain about konquerors ability to be both a browser and a file manager. However, once you understand what infrastructure is supposed to be you recognize that same ability as a good working infrastructure. File managers and browsers have a lot in common and therefore you might as well integrate them so that you don't have to invent the light twice.
The UNIX philosophy is to make something small and only once. Most unix applications only meet the first part of that philosophy and have to duplicate everything and the kitchensink because it is either not present in the infrastructure or not consistent enough to allow for easy integration (this should also be facilitated by the infrastructure).
Jilles
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
What's so great about a CLR???
All it does is allow you to "compile" your source into a more obfuscated form of source that no-one can read but you can ship off to any other computer where it will get compiled for real (usually JIT - which is IMO more like a cached interpreter, but that's just semantics) before being run.
All a CLR allows you to do is obfuscate your source a lot. We don't bother. Just ship the real source and allow someone to compile it themselves.
CLRs are just a klunky workaround for people who feel a need to hide their source for whatever reason.
Why doesn't the gene pool have a life guard?