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?" `":" #");}
I switched from KDE to Gnome. The primary reason was an easy one... the latest GNOME is available (through Ximian) for Debian Stable (aka Potato, aka 2.2)... but the latest KDE is a bit harder to do.
;)) and save on system resources. I can make my whole user interface look exactly like MacOS 8 (which I do). So I use Gnome instead of KDE.
:)
When I tried KDE 2.1 on this box, it seemed kinda sluggish. KDE 2.2 is a lot faster, but it ain't gonna run on Debian 2.2.
A big plus for me as well is the customizability (albeit mostly hidden) of gnome. I can completely remove the desktop icons (and Nautilus itself
If Debian 2.3 (Woody) would come out soon, I'd be glad to try KDE 2.2 on it, and maybe stick with it.
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.
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
So Microsoft throws in IIS, and it's a huge security hole. KDE does it, and it's a 'fine thing to do.'
Vintage computer games and RPG books available. Email me if you're interested.
KDE is a *desktop*, not a productivity suite. Microsoft may be attempting to add everything but the kitchen sink into their desktop, but that's not the way we do things in Unix land.
In my never humble opinion, keep KDE a desktop and infrastructure, and spin off the extra stuff into their own projects (like they did with KOffice).
A Government Is a Body of People, Usually Notably Ungoverned
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.
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.
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)
RikYou 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.
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?
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.
The thing is for normal application development you'll need the normal APIs provided by Java. Take for instance the way of creating a socket. In C++ you'll have to use the C-Unix API. This does not look good and is definately not OO. With Java, you'll just create a new DatagramSocket. But with QT that is changing. QSocket provides a TCP-socket.
I think that QT is providing some of the missing features to C++.
Mikael
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
I should note that I have used C++ since before cfront was released to the public, and I think C++ is a great language a number of specific purposes. Smart people can craft very efficient software and debug it in C++. But for getting a job done quickly, for working in large groups with people with different kinds of backgrounds, and for building reliable software from lots of components that are composed at runtime, Java and languages like it are simply better in my experience. And Microsoft, Apple, and many other companies seem to have drawn the same conclusion.