We should carefully examine specifications and code on freedesktop.org

freedesktop.org is a website. Really! It contains code and documentation. We could use some of that for KDE, if it suits us. But KDE is a volunteer effort, and we don't have to read any particular website, nor use any particular code, nor implement any particular specifications.

The specs are at http://www.freedesktop.org/Standards/Home and include:

  • Xdnd
  • X clipboard
  • XEmbed
  • System Tray
  • Mimetypes

    The code is at http://www.freedesktop.org/Software/Home.
    It includes stuff like:

  • DRI for X
  • cairo 2D renderer
  • D-BUS message passing system

    Essentially its a hoster, more focussed that Sourceforge, but not that different in some ways.

    I think that Ian mistook the some of the implementations (eg. D-BUS, which I think avoided a glib dependency by importing bits of glib :) Update: I was wrong :-(. It doesn't do any such thing.) with the protocols or behaviours that they implement. We generally want a good, stable, interoperable implementation. So do the Gnome guys - at least they claim to, despite their selection of tools. The difference is that we want it in C++ and Qt.

    There is nothing that I could see that requires use of Glib in any of the specs that are likely to be important. Sure, we could choose to not re-implement some of the reference implementations (and live with any stability or performance issues), but that isn't a function of the spec, it is about the reference implementations. Would it really take 25K lines of Qt/KDE/C++ code to implement a D-BUS client? I'd hope not, but that is how much C is claimed to be in libdbus.

    Now the choice is about what we want to work on. I wish you well in your choices, and remind you that just cause you saw it on the web, it may not be a good idea.

    Oh yeah, I'm not sure why Rants is so close to the bottom of the kdedeveloper blog category list. Seems to be what I (and more than a couple of other people around here:)) use.

  • Comments

    isnt KParts on there? What makes those hosted projects so important as to be there? Are they friends with the sysadmin? If so is a virtual server so hard?

    Seriously, if they are good ideas nice, but FD.o condoning one implementation over another is a radicle departure from what I originally saw it to be. I dont like where its going one bit.

    -ian reinhart geiser

    By Ian Reinhart Geiser at Thu, 01/29/2004 - 14:44

    They actually allow any project that asks to be hosted there... so I've started to look at that project as nothing more then a sourceforge for desktop projects :(

    By Peter Simonsson at Thu, 01/29/2004 - 18:55

    Sourceforge (like fd.o) has some great stuff, and a lot of dead/dying/stupid stuff. The point is that when you need something, you search through and critically examine the offerings.

    By brad hards at Thu, 01/29/2004 - 20:06

    Well, the thing is that we host a fair bit of stuff, right. It takes a bit for us to knock something back, but we do look at the long-term viability of the project before we make a decision. That meant me asking ChipX86 what his long-term plans for Galago were, asking about acceptance among other developers (actually asking them, not him), and making a critical assessment before I said yea.

    Look, we host a lot of stuff. That's one of our functions. Another of our functions is as a standards body, which provides reference implementations. We're in the process of collecting these reference implementations into a 'platform'. That's it. Doesn't mean stuff like uim will have some major impact on it.

    By daniels at Thu, 01/29/2004 - 22:28

    Are you suggesting KParts in the Software or Specification sections?

    I don't see KParts software needing hosting - KDE already has a good hosting system.

    So we are presumably talking about hosting the KParts specification (which would presumably talk about what a KPart is, what the interface is, and some sample code). If there were such a document, I don't see it being a problem to get it onto FD.o.

    I think that there may be some value in making a clearer distinction between the Specifications (with reference implementation(s) if any) and the hosted software.

    By brad hards at Thu, 01/29/2004 - 20:33

    Ian, excuse my French, but what the fuck?

    No-one ever asked for KParts to be on there. And what relevance does it have, if we're not hosting Bonobo (which we aren't)? I really don't understand your rant ... next you'll accuse us of trying to subvert the American political system or somesuch.

    Seriously, I actually don't understand your post. We're not condoning Bonobo over KParts, or vice-versa. But we'd at least consider it if you asked for us to host KParts.

    By daniels at Thu, 01/29/2004 - 22:23

    Unfortunately, Drupal's censorship of my use of a word that started with 'f' and ended with 'k' did not allow me to express my true bewilderment and confusion.

    By daniels at Fri, 01/30/2004 - 09:59

    D-BUS avoids Glib dependency by doing what? We should reimplement D-BUS? Wow, that's pretty silly. You started sensible but the ending doesn't make any sense.

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

    Been sick - might explain the no-sequeiters (sp?).

    The idea is that if we want D-BUS interoperability, we could implement D-BUS protocol compatible code, without reliance on the Glib derived (as I understand it) D-BUS reference implementation. No need to do so, but an option.

    By brad hards at Thu, 01/29/2004 - 20:17

    Still doesn't make sense. People are reluctant to drop DCOP for a very good reason - it works. Not because we have any problem with D-BUS implementation (excluding the fact that Ian want's to have everything go over shmem).
    And I'm assuming that you got "the Glib derived" idea from one of the comments on this site because it's also completely wrong.

    By zack rusin at Thu, 01/29/2004 - 23:14