Slashdot Mirror

Duplicate link. Try this one http://edu.kde.org/.

You should at least take a look at the kde4 and Education projects. Arguably, they're the best parts of KDE4 (no argument about the games; they *are* the best parts), and since KDE4 is destined for Windows too, it's cross-platform, although I don't know what state the Windows port is actually in.

You should at least take a look at the kde4 and Education projects. Arguably, they're the best parts of KDE4 (no argument about the games; they *are* the best parts), and since KDE4 is destined for Windows too, it's cross-platform, although I don't know what state the Windows port is actually in.

You should at least take a look at the kde4 and Education projects. Arguably, they're the best parts of KDE4 (no argument about the games; they *are* the best parts), and since KDE4 is destined for Windows too, it's cross-platform, although I don't know what state the Windows port is actually in.

But it does! http://amarok.kde.org/en/node/446 :)

It looks like Google awarded KDE the most number of projects (47 total) of any SOC participant.

This one:

"To make a long story short: KDE 4.0 is not and never was meant to replace 3.5.x for regular users. The main goals were porting to Qt4 and creating the frameworks to create all the things announced for KDE 4. Frameworks are unfortunately hardly visible to the user, so most things that use them, like plasmoids, panel-functionality etc., will only appear after the frameworks are in place, i.e. starting with 4.1." (see http://news.opensuse.org/2008/04/18/announcing-opensuse-110-beta-1/)

Now that's a useful comment for an end-user like me. It honestly tells me what's not in the package and what not to expect, and it does so in an up-front manner in three short sentences. As such it's a relief from the way you have to dig for this sort of information on the KDE webpage (see http://www.kde.org/).

Don't get me wrong, I like the KDE desktop ... but I just don't want to know about (or have to dig through) the details of how the desktop is evolving. Let alone the vagaries of all those applets starting with a K. This announcement is end-user friendly in that it gets to the heart of the matter (i.e. I can try KDE 4 in SuSE 11.0 if I want to beta-test it, but it won't give me anything new) without me having to wade through pages of details ... or worse an install. My compliments.

Yes, Amarok does the same on Ubuntu (gotta love Amarok)
:)

Well, I just did a simple test. Start Firefox 3 beta 5, no extensions loaded and open the parent story on slashdot. Then start konqueror (4.0.2) to view the exact same page and scroll to the bottom on both browsers.

Memory usage measured with exmap (the only decent way to measure memory usage on linux http://ktown.kde.org/~seli/memory/analysis.html )
Effective resident (K)
firefox-bin 71262
konqueror 30868

So on this simple test, konqueror uses less than half the RAM as Firefox 3b5. Obviously this test is simple minded, as I only load one page. And Konq in KDE 4.0.2 still has some nasty bugs. But because I'm running KDE, konqueror actually shares a lot of its memory with other apps, while Firefox is one monolithic beast that doesn't share libraries with any other app on my machine.

http://www.kde.org/

Even the KDE foundation voted for it !!!

I'm always saddened when people who have obviously not really used both OS's being discussed try to argue the superiority of one over the other. Seriously, don't even bother unless you actually know both OS's and what they can do.

Yes, it is an API as well. It is also still worlds behind OS X's very innovative system services which has allowed users to plug in arbitrary functionality via a simple plug-in or offer functionality contained within an application. With Sonnet, you can add functionality like grammar checking and application developers can then alter their programs to take advantage of it. With OS X, all cocoa apps can automatically use these functions, even if the developer never even considered a use. I dropped a grammar checking service into my Services folder in 2001 and have been able to use it in Safari, Terminal, MS Word, TextEdit, Mail.app, iChat, etc. ever since. I also dropped in some text manipulation scripts, language translation services, automatic bibliography formatting, etc. When I installed a payware professional thesaurus it offered itself for use in all the other programs as well. KDE is ahead of OS X in a number of ways, but this definitely is not one of them.

Actually OS X does have tools to do the same sort of thing, but they don't ship with a GUI, although there are several freeware GUIs. That said, I hope Nepomuk helps to bring this sort of functionality into the mainstream with more ubiquitous, standardized use across program UIs, in a default install.

I've never used Solid, but I don't see anything to imply it is revolutionary, or even a best of breed solution.

Even Windows Vista offers this these days.

There are certainly some very useful Widgets and it is nice that KDE can use ones designed for OS X (even if I will probably never use them). Nothing prevents Widgets from having the functionality of full fledged apps and on OS X they can plug into the normal APIs like CoreData.

For quite some time I've been maintaining a large list of the advantages each major OS has over competitors. Maybe I should expand that into a full-fledged comparison and submit the article to Slashdot. Then at least users can have an informed list they can use as a basis for comparisons. It just seems like most arguments turn into emotionally charged messes with very few people arguing from the position of actually having used on a regular basis the OS's in question. The only thing holding me back from writing it right now is that I've ditched Vista for the time being and am on WinXP for my Windows needs (until Vista stabilizes).

Sonnet - It isn't simply spell check but a bevy of language tools including language recognition and grammar check.
Nepomuk - This is FAR more than search. http://nepomuk.kde.org/
Solid - I don't know anything about I/OKit, but Solid provides an easy API for apps to interact with hardware.
Plasma - In many ways it offers previous functionality (panels, dock, widgets, etc) but it brings them all together under one library and framework, however the real innovation and advantage of Plasma is the ability to generate apps easily in most any language. And while widgets have existed for a while, most widgets are useless toys. Plasma provides powerful data engines to create actual useful apps.

Check it out: http://dot.kde.org/20080401/"

I know it's not a "true2 part of KDE and I hate to make another rant about this, but I've been unable to see anything but a horrific downturn in amarok, both in terms of usability and basic visual appeal and the developers are convinced their "content-centric" way of doing things is The Right Way. In my experience this translates to:
Making it look like superficiallyiTunes whilst continuting to ignore the ability to have the user decide where to put things like the playback controls and position slider
Seemingly ephemeral "content window" taking up greater than a third of the main app real estate so I can repeatedly read the wikipedia articles on my bands, or something. Why would I want to do this all the time? Oh right, because it's plasma
Aforementioned content window gets in the way of dragging things from the tree browser on the left to the playlist on the right
Playlist has been severely gimped compared to amarok 1.4 IMHO. Devs have been telling users like me that keep several thousand items in their playlist are stupid (the only valid reason I ever saw was because it increases startup time - something I'm not particularly worried about with my current amarok uptime being about fifteen days) whilst failing to provide me with a convenient way to listen to my music in the way I liked (generally on random/semi-random unless I want to listen to a particular album or artist, in which case I use the boolean filter)

Maybe I'm horrifically sad and very much music 1.0 or some such crap, but I use amarok because it makes managing and quickly picking out music from a massive collection really, really easy. Amarok 2 just seems to me to be a catalogue of style over usability and change for changes sake. Pretty much every criticism I've seen of the new UI on the blog from the very first mockups has been shouted down with either "these aren't even alpha yet, shut up, the final design will look nothing like this!", "you're wrong, this way is prettier", "we think it's more usable even if you don't, no we won't provide that as an option, it goes against our philosophy" or "can't change it now, we're too close to release". Seriously, how much time to /.'ers spend staring at their music application (not counting pretty visuals like projectm)?

Since the site seems slashdotted, here's the latest dev image posted to the amarok blog: http://amarok.kde.org/blog/uploads/Newtheme.png

On a more KDE-centric level, I'm not enjoying the low-contrast Qt themes with the insistence of rounding every possible corner, and I've yet to come across any themes that give be the beautific simplicity of Plastik
The new XP-style kicker replacement is an absolute abomination to use. Too many clicks, practically impossible to browse the program hierarchies quickly. Everyone says "use the search!" - sorry, I shouldn't have to use the search function because you neglected basic functionality
Still doesn't like working across multiple monitors
Panel and window configuration options are still severely lacking
Seeming enforcement of "the desktop is the application!" metaphor with the proliferation of widgets replacing apps. The desktop, in my way of working at least, is visible for about three seconds after login until an app or five autostarts and covers it. Thanks to KDE's fantastic setup of multiple individually configurable panels and/or kb shortcuts I was able to do away with all of that tiresome minimising of windows. If you're going to make us use widgets, at least give us the option to make them use the window manager so they get an entry in the taskbar, please. The lets-have-windows-without-taskbar-entries philosophy is annoying enough on windows, as anyone who's spent time trying to find that security dialog box that took a minute or two to appear will testify
Speaking of the taskbar, the icons are still huge and it still doesn't play very nicely with having lots of windows open
Last time I checked, those somewhat confus

If you're into C/C++ check out KDE ! You'll receive mentoring, and money.

http://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas

We are all making comparisons to IE trying this direction years ago. I was tempted to further comment on KDE's similar attempts that were split up with 4. But in making looking to the original article, I found that I couldn't compare much. Prism, the direction in which "the lines are blurred", does not make attempts at system management or even at messing with your files. It does however give the option to make web applications like GMail work similar to local apps. According to more information about Prism, this also gives the options of having specific profiles for specific web applications. Think about it: you could have a slimmed down, no add-on profile for quickly checking your e-mail. And for general browsing you could have the full profile, no-script, adblock plus etc. Sounds pretty original

Yeah but at least a few users complain that it doesn't fit in with the style of their OS and they won't use it because of that.

165MB is a HUGE amount of source code for something that you claim has a 'much smaller and cleaner' design and is "not all that large".

Firstly, that tarball is a SVN working copy and includes such things as Bugzilla and other Webkit-related websites/web applications, testcases, etc. Deleting the Subversion directories alone drops the uncompressed size by a gig from ~1.4GB to ~400MB. Deleting most of the testcases drops that ~400MB to ~100MB. Deleting the websites drops that ~100MB to ~80MB. So you see the actual source code for Webkit only comprises about 5% of the archive, and there's a bunch of testcases and support tools I missed removing there.

Secondly, I didn't say that Safari is "not all that large". I said that browsers are not all that large. Download, for example, KDE, and see how small a part of it Konqueror is. You were characterising developing a browser as this monumental effort that required a special, painstakingly slow development approach. In reality, there are far larger codebases that are worked on at a much faster rate by many more people, with way less communication. Browsers really aren't anything special in this regard.

Thirdly, it's not just my claim about the relative sizes of the codebases. Check out the announcements (1 and 2) explaining the reasons for going with KHTML:

Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance

Weighing in at less than one tenth the size of another open source renderer, Konqueror helps Safari stay lean and responsive.

Do you think Webkit is ten times the size it was then? Or do you think Gecko is ten times smaller than it was then?

Instead of fixing the rendering of the 'Ahem' font, it seems to turn off font smoothing just to make it look like the reference rendering(note that it does it only for the web font). What about such bugs for other fonts?

Ahem isn't a real font. It's a dummy font that only has four glyphs and weird sizing. Its glyphs need to have very specific dimensions in order for the test to be accurate. Turning off font smoothing for this font in particular is enforcing those very specific font metrics. Yes, it looks like a hack, but that's far from the whole truth. In the real world, users that change their font sizes would also cause "failures" like this; the specific font metrics of the Ahem font are assumed by the test for accurate results. At worst, you could say it's a hack to set up the necessary conditions for the Acid3 test to run. These font metrics aren't part of the Acid3 test, they are a prerequisite for accurate results.

Bug 17086 is the bug you should be looking at for background. The question is whether or not antialiasing/font smoothing should have an effect on font metrics or if it should be clipped. It may turn out that the Acid3 test is updated to make this a non-issue.

What about such bugs for other fonts? Brushed under the carpet called Acid3 compliance.

Here you go misrepresenting your guesses as actual fact again. If you don't know the details, don't make accusations like that. Should antialiasing/font smoothing increase the size of text slightly or is that a bug? That's a difficult question to ans

165MB is a HUGE amount of source code for something that you claim has a 'much smaller and cleaner' design and is "not all that large".

Firstly, that tarball is a SVN working copy and includes such things as Bugzilla and other Webkit-related websites/web applications, testcases, etc. Deleting the Subversion directories alone drops the uncompressed size by a gig from ~1.4GB to ~400MB. Deleting most of the testcases drops that ~400MB to ~100MB. Deleting the websites drops that ~100MB to ~80MB. So you see the actual source code for Webkit only comprises about 5% of the archive, and there's a bunch of testcases and support tools I missed removing there.

Secondly, I didn't say that Safari is "not all that large". I said that browsers are not all that large. Download, for example, KDE, and see how small a part of it Konqueror is. You were characterising developing a browser as this monumental effort that required a special, painstakingly slow development approach. In reality, there are far larger codebases that are worked on at a much faster rate by many more people, with way less communication. Browsers really aren't anything special in this regard.

Thirdly, it's not just my claim about the relative sizes of the codebases. Check out the announcements (1 and 2) explaining the reasons for going with KHTML:

Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance

Weighing in at less than one tenth the size of another open source renderer, Konqueror helps Safari stay lean and responsive.

Do you think Webkit is ten times the size it was then? Or do you think Gecko is ten times smaller than it was then?

Instead of fixing the rendering of the 'Ahem' font, it seems to turn off font smoothing just to make it look like the reference rendering(note that it does it only for the web font). What about such bugs for other fonts?

Ahem isn't a real font. It's a dummy font that only has four glyphs and weird sizing. Its glyphs need to have very specific dimensions in order for the test to be accurate. Turning off font smoothing for this font in particular is enforcing those very specific font metrics. Yes, it looks like a hack, but that's far from the whole truth. In the real world, users that change their font sizes would also cause "failures" like this; the specific font metrics of the Ahem font are assumed by the test for accurate results. At worst, you could say it's a hack to set up the necessary conditions for the Acid3 test to run. These font metrics aren't part of the Acid3 test, they are a prerequisite for accurate results.

Bug 17086 is the bug you should be looking at for background. The question is whether or not antialiasing/font smoothing should have an effect on font metrics or if it should be clipped. It may turn out that the Acid3 test is updated to make this a non-issue.

What about such bugs for other fonts? Brushed under the carpet called Acid3 compliance.

Here you go misrepresenting your guesses as actual fact again. If you don't know the details, don't make accusations like that. Should antialiasing/font smoothing increase the size of text slightly or is that a bug? That's a difficult question to ans

I was going to say that the webpage you linked sucked as a HIG because it hardly defined an actual style for KDE applications, but it seem like you got the pages mixed up. That one wasn't the real HIG, it was just a document with general UI design advice meant to complement the actual HIG.

That said, I can't say that KDE doesn't respect its own guidelines —as the last time I used the environment full time was for a few months in 2005-2006— but I can tell that they don't care much for that advice page you cited, as the last time I fired up a Kubuntu live CD I saw the one thing that annoys me from KDE: the little icons in the many toolbars. I find that they klutter (sorry, couldn't resist ;) the interface, and that they're hard to hit. I specially dislike the vertical toolbars, but I guess that's a matter of taste.

This is not only from Kubuntu, this is exactly how I remember Suse's KDE to be back in 2005 (only without the folders that jumped at you when you clicked them ;), of which I have fond memories after coming from Windows.

Perhaps it was just the bright icons, or their padding, but I really disliked those toolbars. I guess that makes me a GNOMEr (that sounded weird...)

In tomorrow's story, don't you all hate that weird 'Control' and 'Meta' stuff in EMACS?

I was going to say that the webpage you linked sucked as a HIG because it hardly defined an actual style for KDE applications, but it seem like you got the pages mixed up. That one wasn't the real HIG, it was just a document with general UI design advice meant to complement the actual HIG.

That said, I can't say that KDE doesn't respect its own guidelines —as the last time I used the environment full time was for a few months in 2005-2006— but I can tell that they don't care much for that advice page you cited, as the last time I fired up a Kubuntu live CD I saw the one thing that annoys me from KDE: the little icons in the many toolbars. I find that they klutter (sorry, couldn't resist ;) the interface, and that they're hard to hit. I specially dislike the vertical toolbars, but I guess that's a matter of taste.

This is not only from Kubuntu, this is exactly how I remember Suse's KDE to be back in 2005 (only without the folders that jumped at you when you clicked them ;), of which I have fond memories after coming from Windows.

Perhaps it was just the bright icons, or their padding, but I really disliked those toolbars. I guess that makes me a GNOMEr (that sounded weird...)

In tomorrow's story, don't you all hate that weird 'Control' and 'Meta' stuff in EMACS?

Back when KDE received all the development attention from the major distros

What? When was this? I've been using KDE since the 1.0 betas back in the 90s and don't remember this ever being the case.

KDE's basic HIG is just "see how many buttons you can add to that menu".

That is simply not true.

KDE is a tree stump. You must whittle it down in order to make it resemble something attractive or functional.

Now you're bordering on trolling. You need to "whittle KDE down" to make it even resemble something functional? Nonsense.

So, those who are still using KDE are possibly:

Okay, final strike, my troll alarm is going off. You need to find stupid excuses to explain why people use KDE to avoid the fact that many people choose it over GNOME? You don't think it's at all possible that it might just be better at some things than GNOME?

Using Linspire or Xandros or PC-BSD or some other "easy" distro

You just finished explaining how the people who want "easy" should use GNOME because it's "intrinsically" easy. Surely this is evidence that KDE is easy too, by your own admission.

Gnome is better.

The other issue is that Gnome has really solid User Interface Guidelines. KDE's basic HIG is just "see how many buttons you can add to that menu".

So, those who are still using KDE are possibly:
A) Northern European (this is true for some reason)

B) Have been using linux since the 90's and don't feel like changing ANYTHING

C) Using Linspire or Xandros or PC-BSD or some other "easy" distro

D) Like the letter "K"

I thought that Konqueror service menus are the equivalent of Nautilus actions? (I'm just making sure that you know about these, if that is the reason why you moved to Gnome. ;-))

I have recently switched to Leopard and Xtools was on the disk. If you want to use KDE etc. you can. Once you have MacPorts running you can use most Gnu stuff. I think that MacPorts is better than Fink for getting all the Gnu stuff running but that is because I prefer an easy life.

well, yes, i believe the thingie taking care of that is even called "threadweaver" :)

yep, here it is : http://api.kde.org/4.0-api/kdelibs-apidocs/threadweaver/html/index.html

It would be nice, but it is probably not going to happen anytime soon... A few problems would be that some at KDE are still behind KHTML instead of WEBKIT, let alone be interested in a Gecko version. An other problem is that someone (Dirk Muller - http://wiki.kde.org/tiki-index.php?page=Firefox+KDE+Integration) already did something like that, but at mozilla you need to do a lot of difficulty to get your code checked-in. He probably wasn't interested in spending days, finding someone. They would give him an CSV account...

The easiest thing would probably websites like the following:
http://gentoo-wiki.com/HOWTO_Integrate_Firefox_with_KDE
http://ubuntuforums.org/showthread.php?t=110353

(there are a few more, could find the one I wanted...)

... then all you'll need is a patch for Ubuntu and another patch for Gnome.

Kde 4.0 supposed to be a rapid improvement and Kubuntu is supposed to be alot more polished and integrated

Actually, KDE 4.0 is more of a beta quality release (like Mac OS/X 10.0 or pre-SP1 Vista) - it's 4.1 or so that'll really be ready for daily use by normal users. Unfortunately, Hardy falls at an awkward time with respect to 4.0 (or vice versa) - 4.0 isn't ready for long term support, but 3.5 isn't likely to be relevant for 3 long years. As a result, while Ubuntu 8.04 will be a Long Term Support (LTS) release, Kubuntu 8.04 will not be.

I agree with your opinion of Gnome (I use it myself), and with your assessment of KDE 4 (I look forward to trying it out - looks great so far!). And I'm very suspicious that Mono contains Microsoft-patented technology, and believe free software developers should avoid it until the title is clear. But that's just my $0.02 worth (and it seems to be worth less every day...) I don't believe any critical part of Gnome is dependent on Mono, however.

Because, after the release, the developers can get on with making a great piece of software and threads like this start to happen: http://lists.kde.org/?t=120006419200003&r=1&w=2

Really, what happened to Slashdot. I'm surprised there hasn't been any mention of Nokia buying Trolltech. Pretty big news, I think. http://dot.kde.org/1201517986/ Maybe it's been posted, but I haven't seen it.

I assume that over the next day or two an official announcement will be made about Nokia's intentions for the Qt licensing.

This being Slashdot, the summary's pretty light on details like for example what will happen to KDE and Qt's relationship with Free Software at large. Well, there is an open letter to the community, so you can read it here. The letter's pretty encouraging insofar as it reaffirms the Qt team's commitment to the current symbiosis, and it says that Nokia is going to become a "Patron of KDE"(TM). Additionally, the Free Qt Foundation offers protection in case a buyout turns things nasty.

Having said all of the above, I can't help but remain a bit concerned about this turn of events. I was under the impression that Nokia have a rather tarnished reputation in the eyes of the Free Software world, since they seem to be pro-patents for software and there was that opposition from them concerning Ogg Vorbis as a web standard or something. Things like this make me worry. On the other hand, it seems like there is still a large gap between the cultures of proprietary software and free software, and maybe Nokia will gain a more balanced standpoint by getting involved with GPL projects like Qt. Ah well, I suppose we'll have to see how things turn out, but I don't really think a project the size of KDE can be killed so easily as this.

Some other people have remarked that it's interesting that Nokia should acquire Qt, seeing as how they use GTK in a few of their products. It seems fine to me though - I reckon heterogeny is a pretty big part of what Free Software is all about.

I really hope that the KDE Qt Free Foundation agreements are valid because I have a gut feeling that they will be tested in court soon...

"By design, KDE-windows does not provide the full-blown KDE desktop, thus no KWin composite manager, KDE-specific "start" menus, Plasma desktop, etc." from http://techbase.kde.org/Projects/KDE_on_Windows/Installation

So just the apps, not the desktop (Plasma).

Installation Instructions: http://techbase.kde.org/index.php?title=Projects/KDE_on_Windows/Installation

This exemplifies what I hate about many open source projects. If you want me to try it, don't make me work for it.

Per http://techbase.kde.org/Projects/KDE_on_Windows/Installation:

"By design, KDE-windows does not provide the full-blown KDE desktop, thus no KWin composite manager, KDE-specific "start" menus, Plasma desktop, etc."

Just Qt and KDE4 library based applications.

If only someone would point that out to Microsoft.. the most obvious exception to your relationship.

No kidding. If it wasn't for Microsoft, I could have used the word "quite" instead of "often". It's not enough to have millions of beta testers (err, I mean customers) - you have to provide a way to listen to them. Collecting $99 or $249 to open a PSS ticket (and then spout worthless advice such as "do an in-place Windows reinstall" instead of providing a fix) doesn't cut it.

At least free software gets this right.

What's your point?

http://enterprise.kde.org/faq/#WhatcostsareinvolvedinusingKDEasacommercialdevelopmentplatform

"However, the KDE libraries rely on the Qt library. Thus you will probably need to obtain a license of Qt from Trolltech."