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

Jeff Mitchell mitchell at
Thu Jun 25 12:46:48 PDT 2009

Brian J. Tarricone wrote:
>>   "Breaking five years' worth of software" is not really an honest
>> statement either, unless you're talking about five years of unmaintained
>> software (considering that apps/libraries could have a long period of
>> time in which to transition, which would certainly be long enough for
>> maintained software to make that transition...and for unmaintained
>> software, that's why it's Open Source).
> Uh... please point to this software that is not maintained.

That's my point.

>>> Perhaps I took a "risk" by implementing something that isn't a
>>> community-blessed standard (apparently; I thought most people were happy
>>> with it since it's been around some time without any new complaints that
>>> I heard)
>> (Maybe people simply got tired of being ignored.)
> I can understand that, but I still resent having extra work put on my 
> plate now because those same people have decided to get involved again. 
>   I wasn't involved in the original discussion.  It wasn't due to 
> inattention: I just wasn't involved in fd.o at that time (and I may not 
> have been involved quite as much in desktop-level OSS at all, even). 
> I'm sorry I haven't been around for more than 5 years.  Do you feel the 
> need to penalise me for that?

I wasn't involved in the original discussion either.  But you and I have
differing opinions as app developers.  You see a change that is being
proposed for purposes of clarification as busywork forced on
("punishing") everyone else.  I see a change that is proposed that will
end up making all the code using it or wanting to use it more "clear"
and understandable, and will not be terrifically difficult to implement.

If an fd.o spec is changed based on community consensus (and in this
case, it's not  even changing an actual spec), I generally figure there
were reasons, and I spend the small amount of time required to update my
code.  Just like when libraries that I use break API or ABI -- I may not
know the entire reasoning, but I figure the people working on the
library had good reasons for doing so, and I fix it.

I understand why you consider this busywork, but not all coding is fun.

>>> but telling me that it's my own damn fault doesn't make me
>>> feel particularly inclined to redo some of my work to support a new spec.
>> I didn't see anyone say it was your own damn fault, but I might have
>> missed that; it's a long thread.
> I believe someone (possibly Aaron) did say something to the effect that 
> people who jumped on a non-community-blessed spec (despite the namespace 
> usage) shouldn't be surprised when that spec changes.  From my 
> perspective as a late-comer, it seemed community-blessed to me.  Clearly 
> that assessment was in error, but how was I to know?

I don't remember that statement (long thread) but I can see how you as a
late-comer would see that dbus namespace usage and could easily figure
it's a standard.  However, I would have thought when you failed to find
documentation of the spec on fd.o's web site you'd have proceeded
carefully -- if you developed based solely on the interfaces exposed on
dbus instead of an actual spec/"API", then that's not dissimilar to
making use of undocumented methods you found in libraries via "nm" and
then complaining when the library maintainer yanks them away.  When I
had to make use of HAL, I looked at the spec, I didn't just look at the
output of "lshal -lt"...

>>> appropriate level of consensus.  That's a shame, but it's done, and
>>> can't be undone.  "Punishing" people for that now is just childish.
>> I haven't seen anyone state that they want to do this to punish the
>> Galago guys.
> The galago people aren't the only "other side" stakeholders here.  Other 
> people (such as myself) have implemented the current spec and are not 
> involved in the galago project at all.

Right, OK, so I'll update my statement.  I haven't seen anyone state
that they want to do this to punish anyone.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : 

More information about the xdg mailing list