Notification spec issue: Ability to assign an icon *and* an image to a notification
Brian J. Tarricone
bjt23 at cornell.edu
Thu Jun 25 12:28:17 PDT 2009
On 06/25/2009 12:00 PM, Jeff Mitchell wrote:
> Brian J. Tarricone wrote:
>> Thank you -- that's exactly how I feel like this conversation is going.
>> As a notifications daemon implementer, I *really* don't appreciate
>> being told "hey, just because we're pissed off that this wasn't
>> standardised in the 'proper' way, you have to change how your app works
>> and make a new release, otherwise you won't be compatible with apps
>> going forward." That's a dick move.
> That statement isn't entirely honest.
Yes, it's completely honest.
> The problem is not just (or even
> mainly) that the spec wasn't standardized in the proper way, the problem
> is that the spec isn't robust enough for the needs of some of the active
> members of this community (whose voices were raised and ignored, with no
> consensus or official spec ever finalized).
Where is the current API being broken by the changes suggested on this
list? I'll admit I haven't kept up with the thread as well as I'd like
since it's seen a lot of activity, and I've been out of town for a few
days. But from today's and yesterday's posts, it seems like the current
renaming discussion is presupposing that the changes with the most
consensus right now do not break backwards compat.
> Keeping backwards-compatibility in the spec for a period of 1-2 years so
> that app maintainers can code in some fairly straightforward changes
> doesn't seem like an onerous burden (I don't see HAL apps complaining).
While I understand David Zeuthen's reasons for wanting to redo HAL the
"right way," I still resent having to rewrite my HAL-using apps to work
with udev/DK/DK-disks/DK-power/etc... as well as figuring out which in
all that mess I need to use and how to use it. There, a HAL user just
complained -- happy? But that's for another discussion...
> "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. libnotify
is maintained, though doesn't see frequent releases (releases it doesn't
really need). notify-osd is maintained. xfce4-notifyd is maintained.
notification-daemon is possibly unmaintained, but has also seen a
release last November. I'm really tired of the common misconception in
the OSS world that just because a piece of software hasn't seen a
release in a while it means it's unmaintained or somehow broken or not
useful or used in the real world.
> I don't think the "dick move" here is people raising the same objections
> that they raised years ago.
Correct: no it's not. But don't put words in my mouth, as that's not
what I said at all.
>> 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?
>> 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?
(This is of course a great argument for why this sucks a lot -- I took
"org.freedesktop.XYZ" to mean there was community consensus when there
apparently wasn't. I *do* feel a bit misled, and I certainly sympathise
with efforts to avoid this sort of thing happening again in the future,
but... again: I hate extra make-work that doesn't serve a useful
> (Unless you're part of Galago, in
> which case, yes, people are saying it's your own damn fault.) The
> message I've been hearing is not "those various apps/libraries should
> have known better", rather "how can we make the spec what we need and
> make the transition simple and relatively painless for apps and libraries?"
Right, I'd love to hear that too: but making things simple and
relatively painless includes considering not changing the interface name
for backwards compat reasons.
If there *really* isn't a good way of keeping the current API while
adding the new flexibility and functionality people want, then by all
means, change the name of the interface. But that hasn't been the --
possibly mistaken -- impression I've gotten with the recent discussion
>> 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.
More information about the xdg