JAN
29
2004
|
The freedesktop.org discussion in three simple pointsI think the whole discussion can be simplified with three points that hopefully everyone can agree to:
|
![]() |
Comments
Don't agree.
Point #1: I think KDE is competitive *today* as a desktop. The vast majority of this code is based on KDE/Qt C++. Projects such as libqtgtk and the Qt Style for GTK+ are not really needed, but they do provide some extra benefits for those users who wish to use GTK+ apps in KDE.
Point #2: I don't see this horrible mixture that you are alluding to. KDE does not have a horrible mixture at the moment. A few folks are looking at Python and Ruby, but the vast majority of code that makes up the KDE desktop is a homogenous combination of KDE/Qt C++.
Point #3: I like Freedesktop.org when it sticks to what it does best... a shared place to gather and talk about shared specifications and standards. I *don't* like Freedesktop.org when it mixes and confuses this worthwhile goal with a sort of sourceforge like repository for software which seeks to become the 'standard'. First: implementations != 'standards'. Second: some of the implementations look cool from this perspective and will likely be used by some KDE developers *ahem* Keith's Kdrive *ahem* and others are not likely to see any light of day on the KDE desktop. So, I think FD.o would do well to leave the hosting to other folks and concentrate on shared specs/standards.
I believe this is what Ian was talking about.
Don't agree.
I think KDE is competitive *today* as a desktop.
No, it's not even close. It lacks non-standard software, like video editing or DTP or tax software. Even some mainstream software, like a media player that can compete with WM9 or RealOne, is missing. In almost every KDE app (exceptions: Konqueror and KMail) I can show you dark corners that would freak out every regular user. There's no user-friendly way to configure the system (e.g. network confguration). No easy way to install third-party software. No GUIs for configuring apps like web servers. And so on...
Point #2: I don’t see this horrible mixture that you are alluding to. KDE does not have a horrible mixture at the moment.
KDE itself doesn't. I was referring to all those GTK/Qt integration discussions, DBUS, GStreamer, HAL, FUSE/KIO and so on.
I think also that KDE is comp
I think also that KDE is competitive as a desktop today (at least for me). I wasn't very impressed by WMP (very confusing interface) and I would rate the new kaffeine-0.4.1 definitly better. Some apps might not be as good (feature-wise) as there windows counterpart but at least they exist (see Mainactor (video editing) and scribus (DTP, both QT based)).
IMHO one of the things that are most needed today for a better KDE desktop is a better integration with the underlaying system. E.g. it would really be nice to have something like "Project Utopia" for KDE. "Project Utopia" consists of gnome-volume-manager, dbus, udev, hal and should provide enhanced automount functions for gnome (hot-plugged storage devices and inserted media). See http://primates.ximian.com/~rml/blog/archives/000315.html
I think it's better to share some underlaying "infrastructure" (like dbus, udev, hal in the example above) than to have different underlaying structures for every DE.
Different subject.
KDE is competitive from my POV, but not from yours. It is for some and not for others. But that has nothing to do with fd.o or Ian's objections. The real simple points:
1. fd.o works as a place to consider shared specs.
2. fd.o does not work so well as a platform of technologies (precisely because the two major existing platforms will not agree on these technologies)
3. Ian is concerned (as well as quite a few KDE developers) of this whole genesis of fd.o the 'platform' and the confusion of 'specs/standards' with 'implementations'.
4. The concern is that political pressure will be brought upon the KDE developers to conform to these so-called 'standards' not because of technical merit... rather because of the political pressure to just get along with braindead tech.
Platforms ...
2. fd.o does not work so well as a platform of technologies (precisely because the two major existing platforms will not agree on these technologies)
Well, that's because only one of the major platforms has really come to the table, elaborated on what they want, and been forthright about it, helped with code, etc. Hint: it's not KDE.
3. Ian is concerned (as well as quite a few KDE developers) of this whole genesis of fd.o the ‘platform’ and the confusion of ’specs/standards’ with ‘implementations’.
We have standards, and we have implementations. We have sample implementations for most of these standards. I really don't see the problem. Oh, BTW, the fd.o platform is separate to the whole specs/standards/implementations effort, but it is meant to provide a common base for desktops.
*sigh*.
Oh come on...
Hint: it’s not KDE.
Another hint: GNOME isn't it either. It's individuals, and your approach to the whole issue is not going to win you support from any developer at KDE.
We have standards,
No, you don't have standards, at the very most you have agreements between interested parties discussing unified solutions for existing problems. This is where developers from KDE do participate because it's in their interest to find solutions which can be useful to and be used by as many people as possible. To quote the fd.o front page:
"freedesktop.org is a free software project to work on interoperability and shared technology for desktop environments for the X Window System." and "freedesktop.org is not currently a formal standards organization, though some see a need for one that covers some of the areas we are working on."
Oh, BTW, the fd.o platform is separate to the whole specs/standards/implementations effort, but it is meant to provide a common base for desktops.
You are funny to encapsulate such a clarification in a carefree "oh, btw" sentence, you should be aware that the whole fd.o platform thingy is crucial to the impression of developers that fd.o's so called "standards" are set in stone somehow already an now tried to force upon them without any disscussion how the previously mentioned "interoperability and shared technology" is actually going to happen. A hint: by reading the responses by actual developers on this site about the whole issue you can bet that the individuals within the KDE project will be increasingly reluctant to adopt any fd.o "standard" decided this way. And your steady sighing giving others the impression that you either don't take the whole issue serious or didn't even understand it at all so far doesn't make the issue go away either.
Err ...
I think with the amount of GNOME people on there, it can safely be considered very GNOME. Havoc, Robert Love, David Zeuthen, everyone. As for KDE, it's Waldo and Zack, and Alex is starting to work on some D-BUS stuff. That's it.
For standards, I think we can pretty safely call something like XDG a 'standard'. Given that, oh, only GNOME, KDE, XFce and others use it. But nevermind.
How are we forcing the platform on you? What do you mean, 'without any discussion'? The discussion was large, and some of it's still occurring, but you can't blame fd.o if KDE happened to miss the boat entirely. Seriously. It hasn't yet, though, so why not join up and ... well, actually discuss things? Seems to be a far more productive idea than bitching and whining about GNOME's agendas for subversion on some obscure site where you mainly preach to choirs.
I understand the issue. It's reading the reactions here that make me sigh so frequently, because it really is quite depressing for me. I've seen the reactions, I understand the issue - and I'm beginning to wish that I was naive.
Forcing
How are we forcing the platform on you?
I think the release of the platform was considered forcing a minimum required subset of foreign parts into our project.
I guess the release of the fd.o platform was meant to increase the number of developers knowing about/working with the new stuff.
But I also understand the negative reactions.
The release makes all included technologies look like some agreed-upon standard that everyone will support, which puts pressure on the KDE devs.
I guess if the release would only contain the standards
/specifications that were agreed on and possible implementations, say a lib to access the shared mime files, there wouldn't be any problem, because we can use our own implementations, which we already have.
"reference" implementations
But I also understand the negative reactions. The release makes all included technologies look like some agreed-upon standard that everyone will support, which puts pressure on the KDE devs.
I guess if the release would only contain the standards/specifications that were agreed on and possible implementations, say a lib to access the shared mime files, there wouldn’t be any problem, because we can use our own implementations, which we already have.
I agree.
Another problem is (IMHO) that the platform contains stuff that most KDE developers don't even know what it is (e.g. intltool, scrollkeeper). Also what specifications do they implement?
I really wish Daniel would have answered Navindra Umanee's question about this on the platform mailing list.
Christian
Stuff, and things
Another problem is (IMHO) that the platform contains stuff that most KDE developers don’t even know what it is (e.g. intltool, scrollkeeper). Also what specifications do they implement?
Right now, the only things the platform contains are: xlibs, D-BUS, HAL. That's it, basically. The rest is undecided.
I really wish Daniel would have answered Navindra Umanee’s question about this on the platform mailing list.
My mail was screwed up, apparently, so I was on nomail from platform for a bit (and didn't get told, because I was the admin, and undeliverable ...). I didn't get it, but I'll be bouncing myself a copy of the mbox today so I can sift through and answer the two outstanding questions, and spark off a discussion.
Pages