JAN
28
2004

We need to embrace freedesktop.org

Submitted by Cornelius Schumacher

What's up with freedesktop.org? Daniel says KDE people don't care about it, Ian says we have to abandon it. I say let's embrace it and make it what it's meant to be, a common building block for all desktops, KDE, GNOME and whatever else.

There is some cool technology on freedesktop.org like the X server and Cairo, some interesting stuff like D-Bus, but where are the cool things KDE could provide? Where is KConfig XT, where are DCOP bindings for D-Bus, where are the specifications for the various desktop file flavors we use? Let's put them on freedesktop.org. It really can't hurt if some more people outside of KDE get some exposure to KDE technology. Many things we have aren't tied that much to our specific desktop, but could very well turned into something useable as a common base for multiple desktops.

Ian stated that freedesktop.org standards are polluted by implementations. Well, that's how free software works. Those who write the code decide. We aren't able to sit down as bureaucrats, write formal standards as thick and as interesting as phonebooks and contemplate about philosophical details of extended Backus-Naur forms. We are able to write code that works and gets the job done. This code which actually exists defines the standards and we should extract that and put it on freedesktop.org.

Think big. KDE isn't about developing one specific cool desktop environment, it's about providing the base for desktop computing at all and about executing our vision how this desktop should be.

Comments

I'm only a user[TM], but I tend to agree here. After a flurry of activity in the early days (agreements on common file formats, etc.), KDE.org seems to have become somewhat passive towards freedesktop.org, when in fact it has a lot to offer (KDE to fd.o, I mean) - so instead of criticizing what freedesktop.org is right now, why not just add your own stuff to it? Turning KDE technology into open standards can only help developers targeting the KDE platform, I think, and more KDE-compatible apps are what I, as a user, want most.

Sure I'm happy (read: thrilled!) about the GTK/Gnome integration stuff that's been announced over the last few weeks (using KDE dialogs in GTK apps, the GTK-QT Theme engine, ..), but shaping freedesktop.org doesn't necessarily compete with those efforts, but actually sounds more like extending them and making them work in the first place by getting independent developers on board. Because there's a difference between having the option to integrate and actively chosing to maintain such an integration, and I think the indy devs will be more willing to target fd.o than KDE /or/ Gnome.

To sum it up, I think KDE can benefit from participating in freedesktop.org.

By eike hein at Wed, 01/28/2004 - 23:54

This comment is required reading, as far as I'm considered. You hit the nail bang on the head.

What I don't get is people complaining about how they don't get to shape anything, when they actively shy away from doing so? "Hey, come check out this platform, it's looking pretty cool, wanna check it out?" "No, we like what we have." "Hey, the platform's released now." "What? How come we didn't get input? You suck! What are you, some hell agent from Boston?".

By daniels at Fri, 01/30/2004 - 05:48

Our standards are open already and can be improved and deployed at will. And if you want integration, there is no choice but only KDE: you can't possibly call GTK+/GNOME/OO.o/Mozilla/GAIM/XMMS integrated.

If you want more KDE-compatible apps, stick to KDE. No need to endorse anything else.

By capzilla at Fri, 01/30/2004 - 23:40

Hello Cornelius,

While I understand Ian's doubts, I must say that I really, really appreciate your attitude there. I feel you have the right idea. Maybe we'd need a KDE Integration thing created (or at least, somewhat formalized)? Nothing overwhelming really, just a couple of people in charge of having KDE's side of the integration work (KDE dialogs in GTK, Qt-GTK, KAutoConfig, DCOPC) up and, if at all possible, documented on fd.o, things like that. The nice thing about having people for whom managing interactions with fd.o is a more or less official job, is that it saves the rest of the devs from having to worry about it themselves, which sounds like a good idea, at least until fd.o has definitely proven trustworthy.

Some implementation work would certainly be nice too. How hard would it be to make DCOP 100% compatible with D-BUS? Or would it be easier to write a DCOP/D-BUS bridge? (I think I like the latter solution better intellectually, because I don't entirely trust fd.o's ability to come up with an API as great as DCOP, to be honest).

What do you think?

By [email protected] at Thu, 01/29/2004 - 01:19

I have some thoughts about integration:

* gstreamer: It is a really cool architecture. I believe both DEs should use it for multimedia framework, with the JACK backend (gnome people, forget esd, it just sucks). arts can do its magic now, but it is showing its design limitations (FAR from being as pluggable as gstreamer). If the glib event loop is a problem, just use QtGTK to make it use the Qt event loop! (and thus we get to use the same plugins, at least)
* icon themes: Please save the current icon theme to some common place, e.g., .icon-theme. Thus both DE's will look the same regarding to this.
* DBUS: We lost in timing. We already had DCOP ready for ages, but the only implementation was coupled with Qt, and thus D-BUS came, with a clean (as in dependencies) implementations and became a standard.
* Qt vs. glib event loops: glib is LGPL'ed (AFAIK). Can't Trolltech work to make Qt 4.0 _optionally_ use glib event loop? If KDE used the glib event loop, it would make a lot of problems just go away... (all right, and maybe introduce a lot of new ones...)
* KIO vs gVFS: The slaves should be the same, only the front end should be different. We should have a standard API for IO slaves (unfortunately, kio hasn't streaming, so the API would have to be more like gvfs's)

Standards we should submit to fd.o ASAP:
* address book/calendar (just use vcard and i/vcal. Specify some standard location, ~/pim, for example). Make Kopete's format of adding IM ids to address book entries the standard. Or we may end up having to save stuff to ~/evolution
* QtGTK, GTK Qt theme engine: Just submit and ask people to try to be compatible with these.
* Decouple k3b's backend from KDE (that is, if it is somehow coupled) and send it. K3b is the defacto CD burner for linux, and thus its backend would start with a lot more momentum than libburn (which is alpha)
* Colors. This is really important to desktop consistency. Gnome is moving towards configuring the colors along with the theme, which could ultimately break cross desktop color settings forever. We should come up with a standard on saving color settings.
* Sound notification schemes: these have not been talked about yet. If KDE and GNOME ever agree on a common sound backend, it would mean both would be able to play stuff. Thus we need to set a common sound scheme specification.
* Now that we have Cuckoo and QtGTK, someone could work on a similar way to embed GTK apps (is bonobo still the gnome counterpart to kparts?). The least it would do is show how few GNOME apps are embeddable compared to the universe of kparts...

By rmsousa at Thu, 01/29/2004 - 04:39

gstreamer

GStreamer does not have glib event loop issues, since you can run pipelines in a separate thread (and this is a good idea most of the time anyway). The disadvantage of using gstreamer is rather that for the developer it is less friendly to use than a native implementation would be.

By tjansen at Thu, 01/29/2004 - 13:05

Wow, I'm reading through those comments and I can't believe my eyes. You're supposed to be a developer who acknowledges that this is a public site. If you get the urge to post something of which you're not sure - just sit tight and wait till it goes away. People will read that and later quote you when talking to others.
1) We won't use JACK as default, it works only on Linux.
2) What timing with respect to D-BUS? That doesn't make _any_ sense.
3) Event loops... Now that was just funny.
4) Make a theme a standard? heh...
You could have had a few good points but you buried them under a stack of nonsense.

By zack rusin at Thu, 01/29/2004 - 16:28

I think it would be enough to specifie standardized protocolls:
X11 is standard, but what's with DCOP/D-BUS etc.? Some should make a standard here, but no standard implementation! Every DE should have it's own implementation, if they like.

And to specifie standardized URI shemes:
So nautilus would have no problem to start a KDE program which uses kio-slaves, if the URI is in the right form.

And maybe standardized configuration files/directories for COMMON things, like color shemes, font settings, cursor icons, etc.

Well, and maybe it would be great to have a abstraction lib for using common dialogs. commdlg.so? This lib should work on every X11 platform and if there is no gtk/qt it should use motif or some statically linked very basic dialoges. So you just have to use on common dialog in your apps and in every DE the right dialogs would be displayed.

It just would be a good thing to have good communication between all toolkits/DEs (with or without sharing code).

By Mathias Panzenböck at Fri, 01/30/2004 - 15:20

gstreamer: It is a really cool architecture. I believe both DEs should use it for multimedia framework, with the JACK backend

Yep, GStreamer is good but I think it should be used because it is good technology, not because of some stupid interoperability drive crap. I love the look of JACK, and tried it out a few weeks ago. However, as a default, if it only works on Linux platforms then it is a problem.

icon themes: Please save the current icon theme to some common place, e.g., .icon-theme. Thus both DE's will look the same regarding to this.

Here we go with this theme crap. Multi-DE themes just are not necessary.

DBUS: We lost in timing. We already had DCOP ready for ages, but the only implementation was coupled with Qt, and thus D-BUS came, with a clean (as in dependencies) implementations and became a standard.

Come again? D-BUS is not finished the last time I looked, and no one even knows if it will work properly. If there was a specification which could mean that different software could be written to that spec without requiring x, y, or z packages, then it would be a standard. Maybe my idea of a standard just isn't in at the moment. D-BUS is a bit of software, an implementation, but not a f*****g standard!

Can't Trolltech work to make Qt 4.0 _optionally_ use glib event loop?

Er, how about no? If you are going to promote a desktop to developers out there, i.e. Windows developers, they will want a C++ desktop with perhaps some RAD languages on top to get things done. They don't want to know glib or C at any price unless it is absolutely necessary i.e. really (and I mean really) low level stuff where it really is necessary, which 99.999% of the time people are not interested in because it just isn't used. The LGPL stuff is also crap as well, although the LGPL is necessary to get software to work together, and KDE supports this by having some core stuff LGPL'd. I don't see the problem there. I guarantee you that if developers out there want to develop proprietary software they will buy a toolkit and development tools - it's a business decision. Recognizing and supporting free GPL'd software is a good step by a company like Trolltech, because that license also presents a credible business model. The LGPL license does not, which is why I'm not sure about the rational for QtGTK.

Or we may end up having to save stuff to ~/evolution

Er, why?

QtGTK, GTK Qt theme engine: Just submit and ask people to try to be compatible with these.

The jury's still out on that one as far as I'm concerned, so I can't comment.

Decouple k3b's backend from KDE (that is, if it is somehow coupled)

Er, no. K3B is a Qt/KDE application, and the reason why we use Qt and KDE is because of the development advantage it has. You decouple that and what is Qt/KDE development good for? User Interface-only stuff?

Colors. This is really important to desktop consistency. Gnome is moving towards configuring the colors along with the theme, which could ultimately break cross desktop color settings forever. We should come up with a standard on saving color settings.

That sounds like more theme rubbish.

Sound notification schemes: these have not been talked about yet. If KDE and GNOME ever agree on a common sound backend, it would mean both would be able to play stuff. Thus we need to set a common sound scheme specification.

Well, I think the notification stuff goes well beyond sound.

Now that we have Cuckoo and QtGTK, someone could work on a similar way to embed GTK apps (is bonobo still the gnome counterpart to kparts?).

Cuckoo exists because of the weight of Open Office, particularly the MS Office filters. I'm still not sure about QtGTK. I fail to see why effort should be wasted embedding Bonobo into KDE apps. Let's let the Gnome people embed KParts into GTK apps. Coming from a Windows world I took one look at Bonobo and shook my head. It's that bad.

By segedunum at Fri, 01/30/2004 - 22:12

Here we go with this theme crap. Multi-DE themes just are not necessary.
I think the icon theme spec is largely targeted at third part applications, so they can use a defined way to locate and load standard icons of the desktop they run on without having to know which DE it actually is.

By krake at Sat, 01/31/2004 - 15:28