Notification spec issue: Ability to assign an icon *and* an image to a notification
Brian J. Tarricone
bjt23 at cornell.edu
Thu Jun 25 13:49:10 PDT 2009
On 06/25/2009 01:27 PM, Aaron J. Seigo wrote:
> On Thursday 25 June 2009, 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.
> Brian, while I don't appreciate the tone of your email here (and feel it
> borders on offensive), I'm glad that you're at least expressing your opinion.
> I'd ask, however, that you do not rewrite history: we have been raising these
> issues about galago for years here on this list as well as directly with the
> authors. i understand that it's convenient for you to ignore that, but the
> annoying situation you're in is your own making at this point.
Sorry, but I wasn't involved in the Galago project, and, unless my
memory is off, I wasn't involved with fd.o back when Galago came about.
If you're saying that the situation I'm in is of my own making because I
found galago-project.org, saw that it used the org.freedesktop
namespace, and saw that people were using notification-daemon and
libnotify on the desktop and thought it was useful enough to write an
implementation of it, then... sure, that situation is of my own making
and is certainly my "fault."
If you're trying to suggest that I was a part of the initial
standardisation non-process and I'm responsible for hijacking the fd.o
namespace, then that couldn't be farther from the truth.
> I'd also hope that you would value the working nature of fd.o as a
> collaboration point for F/OSS projects, and as such start engaging in a
> process of "how do we fix this" instead of continuing to argue something that
> will not actually lead to significant improvement.
Yes, I'm getting the feeling that this thread is a dead end. I intended
perhaps 2 emails on the subject, but clearly it's gone farther than that.
I love maintaining backwards compat when possible. I hate rewriting
things. I hate throwing away code that works. And while yes, it does
have flaws, current o.fd.Notifications code does work. It would be nice
to keep that working when we move forward.
But I don't just mean that in the sense that we can support both
interfaces at the same time. If we add a completely new interface and
clients start using it, presumably they won't be using the old interface
anymore. So daemon implementations that haven't implemented the new
interface yet just don't display notifications from those clients
anymore at all, rather than displaying notifications that are
> now, you don't want to see any change in org.freedesktop.Notifications. i'm
> willing to accept that, and if that is what happens it will mark the end of my
> involvement with and support of the current freedesktop.org _unless_ we as
> a group can come up with a way of ensuring to our consensual satisfaction that
> fd.o will no longer be run this way and thereby avoid creating more poor
I don't want to see *incompatible* changes if they aren't necessary. If
you can achieve what you want by making compatible extensions to the
interface, that's fine. If you can't, and you really have to change the
API of the current interface, then yes, absolutely it should be renamed.
My objection is more to changing the name with no corresponding need
to from an API-compat perspective. If that isn't what's going on, I
apologise, but that's what Aurelien suggested was happening in the email
I originally replied to.
> this is a vote of no confidence in fd.o as it stands, and the cause of that
> lack of confidence is galago in how it represents the broken / lack of
> processes here.
> start arguing about that and we'll get somewhere.
Well, I don't have much to argue about that. I'd agree that fd.o
suffers from lack of consensus and participation from all desktops (and
even if we had great participation from GNOME, KDE, Xfce, and LXDE,
maybe that even wouldn't be enough, since we're not the entire world).
But I don't really know how to fix that. You mentioned elsewhere about
being able to track and record consensus -- I think that's important.
What tools exist to do that? Is it necessary that it be a very formal
process, or is a simple series of "My name is Foo and I represent Bar
and I approve of this spec" in a list somewhere sufficient? Then
potential spec users can say "I can implement this spec, and it should
work with apps on any desktop," or at the very least can easily
acknowledge, "well, I can implement this spec, but there may be interop
problems on desktop XYZ," and at least make an informed decision.
 Of course then there's the question of what "qualifies" Foo to
represent Bar, which can be difficult with large decentralised OSS projects.
More information about the xdg