Notification spec issue: Ability to assign an icon *and* an image to a notification

Jannis Pohlmann jannis at
Fri Jun 26 18:15:42 PDT 2009

On Fri, 26 Jun 2009 20:49:30 +0200
Julien Danjou <julien at> wrote:

> At 1246038223 time_t, Aaron J. Seigo wrote:
> > moreover, this is something nobody has been taking on, so there is
> > no prior or competing effort. if there had been, i would have
> > joined up with that some time ago.
> > 
> > this is quite different from the closed system that has grown
> > around fd.o and which had been a hallmark of the galago drafting,
> > and different in that nobody else is even trying to do what i'm
> > trying to get people to do here.
> FTR, I just fully agree with what you said.
> It's obvious that fd.o is a failure in being the "desktop cooperation
> platform"[1], mainly because you, KDE/GNOME people, have your own
> infrastructure, process and freedom, and fd.o is just getting in your
> way.
> What you (and you is major-desktop-environment representative people,
> not you Aaron ;) should have done a long time ago, is kick the fd.o
> admins in the balls for not doing their job, and think about new
> option[2] like, i.e. building a new common place based on your
> infrastructure*s* (e.g. a GNOME/KDE/XFCE collaborative platform). And
> I don't even talk about a git repo server, just a Web page or a wiki
> with various pointers would be nice and enough. If it's listed on and
> from GNOME and KDE webpages/wiki, it's trustworthy.

Uh, no. From the discussions I've seen on this list over the past few
weeks, it becomes obvious that

  - there's an always growing interest in new cross-desktop specs and
    shared D-Bus services

  - there are different opinions on how specification X or Y should be
    maintained. Unresolved disagreement leads to dissatisfaction for
    all parties involved. In the end there's danger of specs being
    ignored by potential users or abandoned by their maintainers.

  - there's absolutely no pre-defined standard way to make a spec
    "". People talk about "hijacking the namespace" but
    in fact most specs seem to be introduced without a proper
    discussion to see if there's a consensus on their design. 

    (Just take the thumbnailer D-Bus spec as an example. Nokia likes it
    and so do I. There's a spec, there are two reference
    implementations (hildon-thumbnail for Nokia, tumbler for
    Thunar and Xfce) and the D-Bus API uses the org.freedesktop
    namespace ... but is it really freedesktop? Alexander Larsson for
    instance doesn't think it's a good choice for Nautilus. So, who
    is going to decide about the spec integration on

  - nobody being active on this list actually seems to know or belong to
    the group of people (I know, this is probably not true) who are
    responsible for administration and decision-making on and who could improve the situation if they wanted

Julien, I don't think kicking someone in the balls or starting new web
pages will improve the situation. Neither does telling people they
screwed up, Aaron. Don't blame individuals for the lack of well-defined
processes. And finally, Rodney, moving specs to other hosting platforms
will not help at all. 

I get the feeling that the past weeks were not really healthy with
regards to our overall cooperation. *is* the right place for all this. Cross-desktop
specifications, services and common APIs really belong here! I think
we all want this. What we're facing here IMHO is a governance problem,
and a lack of community management in general. We've all seen a lot of
different communities, but I guess is one of the most
explosive and diverse ones, because we're not always pulling on the
same string together and we do things very differently in our projects.

To define processes and establish healthy governance, of course, we need
volunteers, people with communication talents and knowledge about
communities. Not saying I'm a perfect match for these requirements, but
I'm here to let you know that I'm interested in taking responsibility
improving things for everyone, even if it's just in small iterations in
the beginning.


More information about the xdg mailing list