KDE 3.0 beta 1 is out 292
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).
Feature List URL (Score:3, Informative)
Re:Feature List URL (Score:2)
Re:Feature List URL (Score:4, Informative)
Finally, USB sync...sorta (Score:4, Informative)
Re:Finally, USB sync...sorta (Score:1, Informative)
ScreenShot MIRROR. (Score:4, Troll)
Screenshot link is fine... and helpfull. (Score:1)
Re:Screenshot link is fine... and helpfull. (Score:2)
I notice that the trolls have already defeated the Slashdot [link.url] thingies though, take a look at the AC replying to your post with the google.com kde.gif link. It fools both Slashdot and IE, if you mouseover it says it's a link to google. Amazing. To discover the trick, you have to use the "Copy Shortcut" command and paste it into your URL bar. Think what creative energies like that could do, if they were turned to the light! Think of the programs that could be written with talents like that! And yet whatever sad person thought that up sits here at Slashdot finding ways of fooling a few people into seeing the wrong website, until the post is modded into oblivion 2 minutes later. It truly is sad...
Slashdot caches URLs? (Score:3, Informative)
Alas, it was only a typo...
From the feature list... (Score:3, Redundant)
KWin
magnetic borders for window resizing, gallium
At last! I'm so sick of gluing my windows in place, and the glue makes the screen blurry.
Hold on, don't magnets make the screen dark and erase the hard drive?
Is this the one? (Score:2)
Re:Is this the one? (Score:1)
As with any open source project, KDE will go in the direction that interests those who contribute to the system. Feel free to get KDE 3.0 and submit bug reports though - each helps KDE 3.0 be better all the time.
Re:Is this the one? (Score:1)
Bear in mind... (Score:5, Informative)
- 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
Re:Bear in mind... (Score:3, Insightful)
It is a true tribute to KDE that a major version change doesn't look or feel much different.
Dunstan
Re:Bear in mind... (Score:2, Insightful)
I second that. And because the codebase does not change, it should be a lot more stable than KDE2.0.
I know a lot of people who have tried KDE2.0 and left it because it was quite buggy.
KDE3.0 will (hopefully) be stable from version.0 on, so the large audience trying the .0 version won't be scared away from it.
I think KDE3 will make inroads in the desktop-market.
This is not a flame! (Score:4, Interesting)
* - 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.
Re:This is not a flame! (Score:1, Interesting)
Besides, I've fallen in love with Galeon. Much better than Explorer or Konqueror (does konqueror have tabbed browsing yet? haven't checked it out in a little while.) I'm currently running 0.11.3, and it's still more stable than Explorer. And on the two occasions it has crashed, it's restored my browsing state. Poetry.
Memory usage (Score:1)
Re:Memory usage (Score:2)
[jharris@servo jharris]$ free
total used free
Mem: 255516 199036 56480
Swap: 265032 0 265032
Re:Memory usage (Score:3, Informative)
So you're claiming your KDE needs 450MiB memory? Wow, I wonder how I managed to run it on a machine with just 96MiB RAM and 128MiB swap (and a lot of free memory was still available).
Seriously, understanding 'top' or 'ps' output is not that simple as it seems. The formula for computing used memory from numbers given by 'top' is : Used_memory = mem used + swap used - cached - buff . Now go again to measure your memory usage, and if your number is still higher than 100MiB for plain KDE, there's something wrong with your install. For me, the number for a booted computer with plain KDE started is less than 50MiB (I'm not sure how much exactly and I'm not going to close all apps and logout just to find out).
Also, important portion of KDE's memory usage comes from gcc/glibc/binutils inefficient handling of C++ libraries ( see http://dforce.sh.cvut.cz/~seli/en/linking2 [sh.cvut.cz] ). This is being worked on.
It would be nice if this got moderated up. I'm getting tired of repeating it.
The killer feature (Score:1)
I've been waiting for that for a LONG time...
Unfortunately it's still in the "TODO" group, but I think this feature is worth waiting for.
Super fast UK mirror (Score:2, Informative)
KHTML vs. Gecko (Score:4, Interesting)
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.
Re:KHTML vs. Gecko (Score:4, Insightful)
I don't really know why you want Gecko so much. KHTML is just as fast, if not faster, than Gecko. For a comparison, try loading this page (which is just straight CSS, no images, so it's a good rendering test) in the latest Konqueror (2.2.2x) and the latest Mozilla/Galeon. You'll notice that it renders much faster in KHTML. Now, I'm not saying this would be true of every page (although it may be!), but I think it goes to show that KHTML can stnd on its own, and there is really no need to use Gecko in Konqueror. [w3.org]
Re:KHTML vs. Gecko (Score:1)
Re:KHTML vs. Gecko (Score:1)
It's just my experience that Gecko is more advanced than KHTML in terms of standards compliance/technology support.
Re:KHTML vs. Gecko (Score:2)
The reason that menu isn't showing is the previously poor JS support in Konq. This is said to be much improved in KDE 3.0, and I will be curious to try this site out under the new Konq.
Javascript for a start (Score:2)
I don't really know why you want Gecko so much
A number of sites I visit won't work under Konq, but work perfectly under Galeon. That plus the fact when I've got 1/2 dozen browser windows open and the software dies with Galeon it retrieves them upon next boot but with Konq I lose them all and have to start hunting for them all over again. Hence my switch. These two factors oughtweigh by a wide margin any slight increase in speed.
In fact I now prefer Galeon to IE. The first reason is the tabbed browsing option. Secondly, my IE locks up the parent page until its pop-up window has loaded. This makes browsing very frustrating under Windows. Now if only plugins installed automatically...
Phillip.
Re:Javascript for a start (Score:4, Interesting)
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
Screenshots (Score:1, Insightful)
OK, I checked out the screen shots. Looks just like my current KDE 2.2.1.
KDE is a good product, don't get me wrong. But why does it have to look just like MSFT's products?
I actually would like to work more on finding desktops/WM's that do not look like MSFT. It's interesting to see what other ideas are out there and to see who's got a fresh new paradigm on this desktop. After all, it's not really a desktop anymore.
Re:Screenshots (Score:5, Insightful)
The point is, it doesn't have to, it just can.
Re:Screenshots (Score:1)
Somebody please mod that up, that answers about half of all the anti-KDE/Linux FUD out there:
"KDE looks like Windows"
"Linux is recompiled on a daily basis"
"Linux is used from the CLI"
Themes? (Score:2)
If you don't like the style, change your style engine. If you don't like the theme, change the theme. KDE is totally customizable.
Re:Screenshots (Score:2)
Because, like it or not, the MSFT products it looks like (i.e. not XP, which out of the box is horrible IMHO) do a really good job at making day to day tasks simple. There's more than 20 years of research behind that (Xerox PARC ripped off by Apple ripped of by MSFT), so why should the KDE-team spend unnecessary time redoing that research?
This is of course not to say that they shouldn't if they feel they can come up with a better solution, but the one they have now works well enough, so
Re:Screenshots (Score:2)
afterstep
windowmaker
just about everything other than gnome and kde look completely different and act completely different.
My favorite is afterstep, small, super fast, and written in C instead of that damned C++ (because I know C and personally Hate C++, actually blackbox is awesome example of how C++ can fly!)
If your window manager is larger than 4 megabytes, it is no longer a window manager, it's an application integration environment.
Re:Screenshots (Score:2)
That's because Blackbox did C++ right. C++ done right is awesome. C++ done mediocre is really mediocre. And C++ done bad is abysmal.
Unfortunately, the foundations of Qt were made while the C++ standard had not yet been finalized. And it is still portable to non-standard C++ compilers. Because of this there are a few hacks, quirks and workarounds that aren't good C++ and will never be good C++. Qt is a great library, and there are valid reasons for its kludges, but they still remain kludges.
What about speed? (Score:3, Interesting)
I know it is mainly something about a compiler/linker issue, but what is the progress in that area?
Re:What about speed? (Score:1)
Re:What about speed? (Score:1, Offtopic)
Re:What about speed? (Score:2)
Horse, dead. Beat.
BeOS is no more and is thus merely a footnote, a "might-have-been". All we can get from BeOS now is rough modeling on some of the things it did well - ROUGH is the keyword since the source is not available.
These pissing contest statements of linux vs windoze are usually silly when no useful content is added to them. Keyword here is USEFUL. There are some things that windoze does that linux distros/GUI developers should strive to copy NOT because they are necessarily the best way to do something, but because they are the way that most people are familiar with. Reduce the steepness of the linux learning curve as much as possible and make the transition from doze to linux as simple as possible.
It must be windoze that we copy in many ways, not MacOS X, nice in its own right, because no one is likely going to switch from MacOS X to linux. They are much more likely to switch from doze to linux. Make it as painless as possible while also NOT making the same mistakes that doze has made AND maintaining configurability for power users.
Wait for glibc 2.3... (Score:5, Informative)
...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.
Re:Wait for glibc 2.3... (Score:2, Informative)
Re:Wait for glibc 2.3... (Score:2)
Back in the old days of Linux, circa 1994, it was precisely that model that was used for libraries. Back then Linux used the COFF (or a.out) executable format that required libraries be pinned to fixed base addresses, there was also a registry that assigned base addresses to libraries. It was a complete pain in the ass. When Linux moved to the ELF executable format, we got relocatable shared libraries and I don't think anyone seriously wants to go back. The prelinker sounds like a pretty good compromise to me.
Re:Wait for glibc 2.3... (Score:2)
Re:Wait for glibc 2.3... (Score:2)
Stable Development Cycle (Score:1)
"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.
One argument tending away from Linux and to *BSD is the advantage of maturity. Another important trait is the slow implementation of new features (eliminating many bugs). Introduce two features simultaneously and something breaks, which was to blame?
Re:Stable Development Cycle (Score:2)
I think it's a clear advantage to have both new, possibly bleeding-edge stuff and old, probably rock-solid stuff available.
Speed (Score:3, Interesting)
Woohoo... (Score:3, Interesting)
Re:Woohoo... (Score:1)
Re:Woohoo... (Score:2)
I've just started (about 2 hours into it) creating KOSD, which is can display like XOSD, but have information scroll up, fix an information bar on the display, or display information in Kinkatta style OSD. Much of that is "TODO", not in code. It can be attached to by all apps via DCOP, and then you can centrally control (via a paneltray icon)color per app, turn display on per app, how the app will display, and scroll back through old messages.
It's *very* much an idea rather than code at this second, but I'd like to scramble and get it functional asap so the dcop connection works at least. (Hey, OSD status for one off bash scripts running in the background or with long run times would be nice).
If you're interested, email me at slashdot@timewarp.org. Quite frankly, I'm swamped with contract work through to the first of next year, and I'm dubious as to when I can get some serious time on the project, but someone else working on it would be great incentive. :)
--
Evan
What I'd like to know is... (Score:2)
Also, it's interesting but maybe the kde folks have been holding themselves to a very high standard *because* of that bug. Maybe it just forced them to write code as slim as possible and when that bug is removed it will really pay off :)
Re:What I'd like to know is... (Score:2, Informative)
Right now, you can install Red Hat's rawhide distribution to get KDE 3 built with a snapshot of GCC 3.1.
Re:What I'd like to know is... (Score:2)
Features needed!!! (Score:2)
That's all. Hope I didn't ask too much
Re:Features needed!!! (Score:4, Informative)
"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
Re:Features needed!!! (Score:2)
I don't understand what you mean. Isn't the whole point of filing a bug report to let the developer know that you got "burned"? So they can fix it? Or are you saying that you had a bad experience with a previous KDE bug report that you filed?
Re:Features needed!!! (Score:2)
Anyway, you may be interested to know that I submitted a bug report on the fact that the "noxft" option isn't in the docs for konsole:
http://bugs.kde.org/db/36/36371.html
Re:Avoid Konqueror Crash (Score:2)
Nice bindings (Score:1)
People tend to forget but you don't have have java bindings under Windows!!! (Well, unless you want to lock yourself up with MS broken Java implementation.)
Of course, this is rarely used, but the mere fact that it is available is amazing. I don't know about Objective C and windows though... How does that work?
Multiple sessions per user? (Score:1)
I currently use fvwm2 because kde 2.x doesn't support more than one kde session per user per machine.
Has this changed in kde 3?
Re:Multiple sessions per user? (Score:2)
Huh? that is plain false. You can run as many kde
sesssions per machine as you want
konqueror java (Score:2)
How far are we from KOffice for Mac OS X? (Score:2)
I like it so far, but the idea of dropping half a grand on Redmondware sort of defeats my purpose in buying a non-Wintel machine. Trolltech's site says that Qt3 comes in a Mac OS X version, but I'm fuzzy on how much of KDE is Qt "skeleton" vs C "muscle." Could someone make a SWAG at how much effort would be involved in creating a working KOffice for the Mac?
Re:Expect ... (Score:1, Funny)
- The "KDE and gnome are both cheap imitiations of the Windows GUI" posts
- The "KDE and GNOME are bloated and slow, use a window manager like WindowMaker" posts
Re:Expect ... (Score:1, Offtopic)
You forgot... (Score:1, Offtopic)
Re:Expect ... (Score:1)
Re:Had a look at the screenshots.. (Score:5, Insightful)
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?
Re:Had a look at the screenshots.. (Score:4, Insightful)
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...
Re:Had a look at the screenshots.. (Score:4, Insightful)
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.
Re:Had a look at the screenshots.. (Score:2, Informative)
Re:Had a look at the screenshots.. (Score:1)
Re:Had a look at the screenshots.. (Score:2)
I'm all for eye-candy and coolness (how about rendering the whole desktop in OpenGL with alpha shading and bump mapping? that would look awesome!) but forcing things down peoples throats that are not needed is plain silly, and is a trademarked Microsoft tactic. it has no place in any open source code.
Re:Had a look at the screenshots.. (Score:2)
I concede that the browser icons in the Gnome screenshot look as sucky as KDE's icons. But look at Gnome's folder icon. Look at Gnome's icons in the task bar (the larger icons, probably 48x48 pixels). They're beautiful. The shading behind the folders, the gradient on the folder itself, these are gorgeous icons. In the words of Steve Jobs, these are "lickable" icons. Don't underestimate the power that beauty has to make a work environment more livable and comfortable. KDE needs this.
Re:Had a look at the screenshots.. (Score:2)
Umm. Okay. Well, since you posted as an anonymous coward, I have no idea if you're a KDE developer or just some nerd like me who has an opinion. But I'm going to go out on a limb and say that regardless of who you might be, if you really think the best solution is to let Gnome be the superior tool here, well okay. I disagree with you, but you're free to have an opinion.
I don't see any conceivable way you could say that Gnome's icon of a folder is less usable simply because it looks better. That's absurd.
Re:Had a look at the screenshots.. (Score:2)
...And my vote, not having seen all the other themes, would be that yes, this should be the default icon set. It's far stronger than the existing one, but it isn't flashy or obnoxiously kewl. It's just great. The real experts (I'm just a guy who cares enough to make a post or two, not an expert on the system) should decide if iKons falls apart as you drill down into obscure areas (are there icons for everything? or just enough to make the desktop look good?). Or, if it really shines all the way through. If so, I'd be seriously considering this "pre-built" solution.
Re:Had a look at the screenshots.. (Score:2)
Not according to the auhor, although he could certainly be lying. At this page [kde-look.org] (about 5 screens down) he writes:
If true, then I have no problem with this. Blatant copying is not legal, but "clean room" reimplementations have been upheld in court -- this is what Apple did to Xerox, and what Windows did to Apple.
Why should an interface keep evolving? (Score:4, Insightful)
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.
Re:Why should an interface keep evolving? (Score:2, Interesting)
It's inconsistent (Changing between apps is done through the finder-menu in the up-right corner, changing windows within apps is done using some menu (usually, but not always called "window"))
It's lacking basic abilities every GUI should be able to do (maximize(!), easier resizing)
I bought a Powerbook 2 years ago and I can summarize my experience as following: The software is pretty useless, but the hardware is fine and runs Linux very well.
I only used MacOS to watch DVDs and even that was a PITA (just insert a scratched DVD and see your system freeze -> hard reset)
I did not try MacOS X, but I have yet to hear what MacOS X can do what KDE can't. I won't shell out big bucks just to "try", thank you very much. (Wouldn't probably run very well on a G3/400 192MB RAM anyway)
The interface can easily evolve (Score:3, Insightful)
SVG Icons, SVG widgets, 60fps animation on widgets and icons, genie effect,motion blur, alpha channeling,morphing animation windows widgets and menus, full use of Gforce special effects on the GUI is how you can help the interface. Theres no excuse why we shouldnt take advantage of graphics cards that can render millions of polygons per second and do all of these effects i mentioned with ease. And when you have 1-2-3-4ghz CPUs and 512-1gig of ram it makes absolutely no sense why you should be worrying about your resources.
Its time to update the GUI, and make use of this new hardware. Why have 80s style GUI and software on 2000+ hardware? Really the GUI and software hasnt changed much since the 80s except for games, development tools and $10000 photoshop like tools.
Re:The interface can easily evolve (Score:2)
Actually there's a really good excuse: lack of developers and resources. And perhaps lack of developer interest. Maybe few of the devs care about such gee-whiz features. If you want to see them happen, contribute! That's what it's all about.
Re:The interface can easily evolve (Score:2)
You're confusing two very different issues. 3d and 2d acceleration are two *very* different and seperate things! Just because a card can render 2mil polys/sec doesn't mean that your 2d performance is improving dramatically. Add to the fact that most business machines (esp for large Co.'s) aren't equipped with even reasonably powerful 3d hardware and your target audience just got a lot smaller. Unless you can find a team to write your whole UI in OpenGL you won't be seeing a 3d desktop as you describe any time soon. Besides, we haven't even been able to perfect a 2d UI and you want to open a whole new can of worms? Yikes!
Re:The interface can easily evolve (Score:2)
I never said 3d. Just because you use polygons does not mean its 3d. Polygons can be used on 3d GUIs to add special effects like sparkles and morphing.
Re:The interface can easily evolve (Score:2)
full use of Gforce special effects on the GUI is how you can help the interface.
The gaming industry has proven just the opposite of this. The more glitzy and pretty games have become there is an inverse reaction in how original, bug free and innovative the games are. If programmers are busy adding in motion blur, morphing to their UI they are going to spend less time coming up with useful new features, stamping out bugs etc. IMO it would not make GUIs better but worse. Granted more pretty to look at... but less useful.
Theres no excuse why we shouldnt take advantage of graphics cards that can render millions of polygons per second and do all of these effects i mentioned with ease.
Here is where you are really confusing me if you're really just talking about animating sprites in the UI. 3D hardware acceleration rendering a polygon (a triangle really) is soley based on 3D acceleration. If you have a sprite rendering (from 3DS etc) of a polygon you will not take advantage of *any* 3D hardware acceleration. With that in mind why would you even mention how many polys a card can render? Its meaningless in that sense.
And when you have 1-2-3-4ghz CPUs and 512-1gig of ram it makes absolutely no sense why you should be worrying about your resources.
Programmers don't need any more excuse than they have now to be lazy and focus on eye candy over useability...
I never said 3d. Just because you use polygons does not mean its 3d.
If you say 'polygon' to a graphics guys his mind is going to be thinking '3D'. Esp in the context of "XYZ card can render XYZ polygons per second." Renderings of 3D objects would be a more apt description IMO.
Polygons can be used on 3d GUIs to add special effects like sparkles and morphing.
To use true particle effects you're going to need a 3D API like OpenGL or D3D etc which takes advantage of only 3D hardware accel in the case of particle effects.
Re:Had a look at the screenshots.. (Score:1)
I'll fall for the troll. It's been a while since I chased one
What great innovations has Microsoft made? Windows 95-2000 looked identical, and although winxp may be different, but to me it looks like a toy and the only feature that they put in that I liked was the item grouping on the taskbar which gnome has (not sure about KDE).
If you want to truly compare who is evolving faster load up a august 95 copy of linux and see what X looked like then, then install a current one, and I think it is should be pretty apparent that the linux desktop has come a lot farther.
dewke
Re:KDE: doomed to failure (Score:1)
And what do you mean by dead technology? Linux? Qt? gcc?
Jono
Re:KDE: doomed to failure (Score:1, Funny)
Re:Looks like windows (Score:2, Interesting)
Windows copies other people's innovations and claims it as it's own. Then people like you think that Microsoft came first and claim that linux is copying. I consider KDE more advanced than the windows GUI, not catching up (there are some deficiencies in KDE compared to Windows, but overall it is better).
So what have you done about it? (Score:1, Insightful)
The KDE team has always seemed open minded for new ideas, and they're always saying that anyone can contribute. For everyone out there that doesn't like the UI, GET INVOLVED! Shees, people lavish the open source/free software culture and then turn around and show they have no idea what it's about. You don't have to be a programmer to contribute to projects. I mean, if all the supposed UI and human factors experts who post on Slashdot got together, we'd have the most perfect interface possible by next May
To the KDE team members who read Slashdot, I have an idea. Each time a story gets posted about KDE, and people complain about the UI, why don't you start tracking how many people actually submit ideas to you. I'm sure it would be some interesting statistics.
The true advancements... (Score:2, Informative)
However, there are true advancements. Those are not eyecandy. You won't see them at first sight. But if you begin to use KDE, you'll soon love them.
F.e. there is the kio layer. Any KDE program can load from and save to any file service. Open a script in your IDE directly from a FTP server and save it back to the server. kio accepts plugins. If you write a Freenet plugin, any program can load from and save to freenet.
And this is just one example. Look at how programs and components can be integrated using kparts. Or at how nationalisation is done.
Re:KDE and Qt are great. Suggestion: (Score:1)
As for the rest of STL, most of it CANNOT be implemented effeciently and is therefore redundant. We want to decrease the loadtime in KDE, not increase it (like advanced templetes and virtual functions does).
Re:KDE and Qt are great. Suggestion: (Score:2)
A) The STL doesn't use virtual functions. It's template-based.
B) Its just an indirect call. For most non-trivial functions the cost is negligible.
Now, don't get me wrong. C++ can lead to bloated code. However, it can also lead to very fast code. C++ pushes a lot of work on the compiler. The compiler can often do things to make high-level code perform as well as dirty/hackish low-level code. The template data structure I mentioned above is nice and clean. Yet, it is just as fast as writing seperate linked-list data structure for each object type (which even the Linux kernel doesn't do!).
Re:KDE and Qt are great. Suggestion: (Score:2)
You should've signed in... (Score:1)
Anyhow, both KDE and GNOME are too damn slow. Log-in/startup speed, ugh...
I love KDE too, but KDE startup and application startup does seem a bit stone aged. I suppose its part of the trade off between being a fully featured GUI and ther limited features which KDE possessed less than 2 years ago. The distance that it has come is impressive. When two things happen I will be giving Windows the boot for all professional work
a) KOffice gets a Word and Excel Input/Output doc filter which works reliably. [Followups mentioning StarOffice will be ignored.]
b) Konqueror speeds up - I loved it and then its startup time seemed to slow down drastically.
Re:You should've signed in... (Score:2)
a) KOffice gets a Word and Excel Input/Output doc filter which works reliably.
While I don't have much trouble with Word/Excel doc import (big fancy ones yes, but straightforward ones no), I don't know why straight RTF isn't supported in KWord. Crazy.
b) Konqueror speeds up - I loved it and then its startup time seemed to slow down drastically.
I hear that Konq has totally rewritten their JScript interpreter. I hope the hell they fixed the popup problem... popups normally get a prompt action for me (i.e. "this site is trying ot use a popup. Allow?") but for Flash sites the popup never ever gets prompted, which drives me insane. Especially when 8 or 10 windows pop up because the JScript interpreter doesn't provide the right answer. UGH!
Speedups will be good though. I wonder if they were able to speed up any further than the 2.2.2 and prelinking. Startup time is still ugly for most KDE apps. That is one thing I noticed right away. Every time I start up xchat, it's onscreen almost immediately after I click the button. Konq, KWord, KMail... ~3-5s pause. Prelinked. On a Cel300 @1024x768x24 with 256M of RAM and no swap. Shouldn't be this slow.
Re:You should've signed in... (Score:2)
Re:Pre-compiled Headers (Score:2)
Re:Get Real... KDE *IS VERY* SLOW. (Score:2)
Solutions to the problem are in the works:
objprelink [bottou.com]
ELF prelinking by Jakub Jelinek [gnu.org]
See a discussion on why Gnome is having similar problems [gnome.org]