Slashdot Mirror
KDE 3.0 beta 1 is out
From the development team who tries to break every development speed record (last month they released KDE 2.2.2) comes KDE 3.0 beta 1, with lots of new features, new QT (3.0.1). It is beta 1 so expect crashes. You can find release notes and download locations over . A full feature list of whats planned to be on KDE 3.0 is also available (hmm, quite a big list) and some screenshots are available here. Please read the README files for your favorite distribution before installing the files as those packages are not replacing the KDE 2.2.X binaries (if you have it installed).
I believe that this is the first KDE "release" where KPilotDaemon supports USB-based palm devices (such as Visors). Anyone know if there are meaningful conduits using the archeitecture, though?
Solution to blink tags: wrap them in another blink tag, with a javascript delay loop, so they cancel each other out
I've mirror'd the screenshot page here. Included are also the full size pictures of the screenshots. Enjoy. Mirror Link
I am Jack's HTTP Server
I have been part of the KDE team for a few years now, and slow development is certainly not something which I have experienced.
Development is not always about graphical updates to the interface - and KDE 3.0 encompasses some architectural and some extended functionality.
We are all (KDE and GNOME) evolving fine, and if you are concerned about it, why not help?
--- Jono Bacon - http://www.jonobacon.org/ Writer - Web Developer - Musician
What did you expect? Animated icons? fancy colors? A new task bar?
... .If it aint broke, dont fix it!
There is this old saying
What is wrong with the GUI elements of KDE 2.2? And why should they be changed in 3.0?
Microsoft needs to change the visual appeal with each new version of Windows, because tahts the only thing that catches the user's attention. Its a pity you are comparing the 'eye candy' of every new release with the real work that is done in newer version of Gnome and KDE.
Think about it...
Don't Panic
A few people have been complaining here that KDE 3.0 looks the same as KDE 2.x. I just wanted to clear a few things up:
- First of all, KDE 3.0 is largely an architectural upgrade - we have moved to the new Qt 3.x series, and this needs to be reflected in KDE 3.x. The Qt 3.x series has a lot of bug fixes and additional features such as database connectivity, better handling of data structures and the like - this increased stability is passed on natively to KDE 3.0.
- In terms of interface updates, KDE 3.0 will see some updates but bear in mind that this update was aimed at primarily porting the codebase to Qt 3.x. Any additional interface updates will be added as the need arises - we always like your suggestions and bug reports are always welcome.
- KDE 3.0 is largely about increased functionality - examples include better JavaScript, a more integrated Konqueror, new modules such as the KDE Educational Module, the font installer, kernel compiler etc. These things are really likely to appear in 3.1 and further releases.
- For those of you who are gonna bitch and moan about KDE, GNOME, XFree86, Kernel, Mesa etc...why not just help to correct the things you don't like. You don't need to be a coder to help ny project - *everyone* can help an open source project.
Please be patient folks and keep those bug reports coming in - we value your help.
Jono Bacon
--- Jono Bacon - http://www.jonobacon.org/ Writer - Web Developer - Musician
I'll come straight and say it... it looks like KDE is pulling some considerable distance between GNOME and itself. Look I have a lot of respect for the GNOME people... anyone who donates their time to such a massive complex system such as a user enviroment deserves a round of golf claps. The fact is though is that I used to be a GNOME user. And then one day I accidently* logged into KDE 2.2.X (whatever is with RedHat 7.2) and was blown away by the speed and grace. If linux ends up on the desktop in it's present form (X sucks but thats a different story), then most likely it'll be KDE that everyone thinks is linux. They seem to have the perfect model right now... release quickly and update often. Quite impressive really, considering how much shit goes into a project of that magnitude.
* - About the accident... usually I install both enviroments on my machine so I can use apps from both (I always liked KDE's media player and Kmail).
Basically I just always ignored KDE and then one day was checking out what windows managers was available and forgot that I had highlighted KDE and logged in. The rest is history... haven't gone back since.
can't sleep slashdot will eat me
Another interesting URL, and one that should definitely be included with these type of posts, is the open job list. Many of the jobs require no programming experience or capabilities, so don't let that stop you (though developers are always welcome too :-). If you like KDE, help make it better!
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Apple's interface hasn't changed for 10 years (until OS-X). It was just good, people were used to it. The interface doesn't need to change every year (like Windows seems to suggest). On the contrary.
I think the KDE interface is getting near perfect (as far as look&feel is concerned). Making changes just confuses users and adding ever more bloat (like the WinXP themes) is counterproductive.
As for myself, I have been using bare X11/twm for the past 15 years and have no reason to change that. It does the job (for me, admittedly not for everyone), I'm used to it.
It is sad to see how many people even in the Open Software camp seem to be infected by the Microsoft idea of never ending "upgrade" cycles.
One thing that I really would like to see is a better integration of Gecko in Konqueror. I know it's already possible to switch rendering engine, but it's highly unstable in my experience.
Now here's an example of an area in which many of the largest open source projects (Mozilla, GNOME, KDE) could collaborate, benefit from each other's work and find a common standard - the HTML rendering engine. Imagine the Konqueror, Galeon, Mozilla and Nautilus teams putting their efforts behind Gecko development...it would be one important step towards a more unified Linux desktop. Unified as in common standards and shared components, not unified as in lack of choice.
Hello, my name is Robert Lerner, and I pronounce Lernux as "99% cpu"
> KDE is a good product, don't get me wrong. But why does it have to look just like MSFT's products?
The point is, it doesn't have to, it just can.
Hmmm. Well, releasing screenshots certainly invites the user to view the 3.0 release as primarily visual. You can hardly fault the original post for that. But I would make two other points. First: yes, the GUI is lacking in some areas, and could stand some fixing. For example, whenever Gnome fans throw up a screenshot of Gnome and say "looky looky, we look lots better" -- well, as a KDE fan, I have to admit that Gnome does look better. But that's only the icons. Gnome has a better artist working for them somewhere, and KDE could stand to find a master artist of their own. That could be part of KDE 3. As an aside, I prefer KDE because KDE has better widgets. Ever looked at a row of checkboxes in KDE? It's obvious what's checked. Now try that with Gnome. It's not at all obvious to me. KDE has better scrollbars, too. Oh! And one other thing: KDE's default titlebars make great use of "grip" (the bumps that you can "grab" to move the object around), but the rest of KDE pretty much ignores grip. It shouldn't. When you resize a window, the bottom right corner should have grip bumps. Any area that you "grab" that has room for grib bumps should use it, it's a useful visual cue.
But there is another aspect to your post that could stand to be responded to. If 3.0 is not going to be about eye candy, and is instead about the underpinnings of the product, then what about the big criticisms that get lobbed at KDE? Will 3.0 find ways to seriously optimize its code for speed/performance gains? I just skimmed the to-do list, and didn't see speed getting much of a priority. What about reliability? I see that Qt 3 is supposed to deliver some of this. What about the built-in database that comes with 3.0? Can that be used to bring some of the BeOS file management features to Linux? And let's merge the GUI stuff with the speed issues: ever moved your mouse around the screen while an app was launching? Notice the very cool animated icon "attached" to your mouse arrow -- the icon of the app, to let you know it's launching. Well, aside from how cool that feature is, it's also slow -- you can move the mouse arrow all the way across the screen, and the poor animated launch icon will be halfway behind. I'd like to see that fixed. In fact, I'd like to see it completely integrated with the mouse arrow, transforming the arrow icon for those few seconds, to make it visually more cohesive.
To sum up: speed, reliability, speed, reliablity, icons, speed, reliability. That's what I'd like from KDE 3.
My Greasemonkey scripts for Digg &
Have you submitted bug reports/feature requests for any of these (especially konq crashes)? KDE needs your input to fix these things. Complaining on /. doesn't count :)
."
:)
"Anti-aliased fonts are great, but there are times when aliased fonts are actually preferable. In particular, I used anti-aliased fonts, but in terminals, I *really* want a regular-old courier font. At 1024x768 in my terminals, anti-aliasing makes it difficult to tell the difference between and m and n or a , and
konsole -noxft
It's a life saver, since most AA fonts don't render well in konsole anyway
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
Javascript is the ONE thing that will have really improved between KDE 2.2 and KDE 3.0, if I had to name only one. ;)
;)
Please try KDE 3.0 beta1, retest those Javascript sites, and I can assure you that you'll be surprised.
It's not all bugfree yet, but it's much much better than what was there before. I see those JS popupmenus in many websites, where they wouldn't appear before.
I haven't completely cleaned up the KJS buglist yet - that takes time, even just testing - but we're almost there now
See also the other posts on how to prevent one crash from taking down all your browser windows.
Tabbed browsing: that will come right after 3.0, stay tuned
...or (horror of horrors) compile glibc yourself with Jakub Jelinek's prelinker patches, if you can find them (they seem to have disappeared off the net).
The dynamic linking of libraries is by far the biggest cause of KDE program startup slowness. A big desktop environment has a lot of shared libraries to link to an application at runtime, it's expensive computationally (particularly for C++ libraries), and the way the glibc dynamic linker works right now, it's done every time an application is started or a library is dlopen()'ed (such as when embedding a KPart). It can also cause swap thrashing on machines with limited memory (the entire library must be read into memory to perform the address relocation, only after relocation can the VM drop pages of the library) and obviously, disk contention between this swapping and the application loading can slow things down even further.
What the prelinking patches do (don't get them confused with the objprelink hack which, while useful, is not a long-term or efficient solution) is move the linking time from application startup time to system startup time. A tool runs at system startup, immediately after ldconfig runs, which loads and relocates libraries in its search path, then notes down the relocation addresses. Then, later, when the dynamic linker is asked by an application to load a library, it simply uses the values that were cached earlier. Any libraries that have not been 'prelinked' are simply relocated as normal. The linker also makes sure that non-prelinked libraries are not relocated into the same address space as any prelinked libraries that are not currently loaded.
The next major version of glibc will hopefully include library prelinking by default, but I haven't been following glibc development closely enough to know for sure. Let's keep our fingers crossed. Note that it's not just KDE that will benefit from this, Mozilla will gain a great deal (it, like KDE, is mostly C++ code split into many shared libraries) and even GNOME will benefit a little - doing the dynamic linking on C libraries still costs processor time, although it's much less than with C++ libraries.
The next biggest cause of KDE startup slowness is icon loading - currently every app has to search through the entire set of available icons on startup in order to load the icons that it needs. Not very efficient. Given that KDE has several hundred icons available already and that is likely to increase over time, it needs a solution. Waldo Bastian is apparently working on an icon server for KDE 3.0, which will do that search once, cache the data, and then respond with appropriate icons when an app asks, rather than forcing the apps to do it themselves every time. I'm hoping it also makes it easier and faster to do image compositing (overlays and so forth) with icons.
To sum up: glibc 2.3 together with KDE 3.0 should make a huge improvement to app startup (and KPart embedding) time, and, assuming the KDE guys are tight with their code, may even make KDE 3.0 usable on machines that couldn't effectively run KDE 2.x.