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

[Aaron J. Seigo]

On Thursday 25 June 2009, Brian J. Tarricone wrote:
> On 06/25/2009 12:11 PM, Jeff Mitchell wrote:
> > By this logic, you should be using Windows.  Microsoft takes on huge
> > burdens to maintain backwards compatibility (see an interesting blog
> > called The Old New Thing).  Sure, it's not the best OS out there, but
> > things don't always work out as they should.
>
> There should be a form of Godwin's Law that describes how arguments can
> devolve into "well then you should just use Windows."

hahaha.. yeah, no doubt.

> >  The
> > problem is not certain developers not getting their way, the problem is
> > the ineffectiveness of fd.o at reaching community consensus, agreeing on
> > standards, and enforcing them (in whatever manner possible or
> > appropriate).
>
> How are those two things different?  Emotionally, they are, but
> semantically and practically, they're the same thing.

actually, they are _opposites_, not synonyms.

if fd.o was effective at reaching community consensus, we'd all end up making 
some compromise on some issue at some point. we'd also have a way of 
documenting what this consensus is. this allows us to create something 
together, and that will in the end be not only a better system through 
participation it will be one that everyone coordinates on using and we don't 
end up with these after-the-fact bolt-on systems.

developers getting their way means no compromise, lots of ill fitting 
technology and no documentation of consensus.

so, opposites, not synonyms.


if we want to just create a bunch of uncoordinated technology, we already have 
GNOME and KDE and XFCE and others that are just great places for doing exactly 
that. if we want to create a platform of shared technologies, then we need a 
place for cooperative, consensus based technology creation.

> But please understand that I'm not advocating a continuation of making
> specs into 'blessed' standards when they haven't achieved a reasonable
> level of consensus.  Going forward, I would be thrilled to see greater
> participation, and fewer people getting frustrated and going their own
> way.  But, that's the key bit: "going forward." 

how will this happen?
what will it look like?
how can we have confidence that it is how it will actually be adhered to?

let me give you a concrete example so we can talk in concrete terms:

if i put forward a new system tray spec, how will we know and then document 
whether or not there is consensus on it?

what happens if i then decide not to collaborate on the matter with anyone?

what happens if i call it org.freedesktop.NotificationItem and 
org.freedesktop.NotificationWatcher and ship a KDE version with those names, 
despite it being not implemented by or even approved by, anyone else?

> If going forward really
> does mean that the current org.freedesktop.Notifications interface
> cannot be turned into something we can all agree on without breaking API
> compat, then, sure, change the name and make the incompatible changes.
> But, as I said earlier, I don't think an incompatible change has been
> suggested or agreed upon.

> >> Right, exactly.  Forgive me if I'm mainly considering *my* psychological
> >> reasonings and emotions here, but they do exist as well.  I understand
> >> that some people are rightfully annoyed at being mostly left out or
> >> ignored when the current spec "hijacked" a name in the org.freedesktop
> >> namespace, but that doesn't mean they should feel free to "retaliate" by
> >> making extra work for those of us who have invested time in the old
> >> interface.
> >
> > Again with "retaliation".  Believe it or not, the current (forced) spec
> > really isn't seen to be sufficient.
>
> That isn't at all clear.

several emails have been sent over the spans of years noting these issues in 
detail on this list as well as to the the writers of the spec directly. 

so the question is: how can we make such things more clear?

this is one reason i have been advocating for a shared, open, repository for 
specifications. mailing lists don't cut it, and it's too easy for one group to 
just withdraw from involvement. in the case of the galago team, it was at 
least for some part of the time, due to them being too busy and not 
prioritizing any sort of interaction or work on galago despite having already 
dumped it into org.freedesktop.

that needs to be fixed.

> Or rather, it isn't at all clear that the
> current spec (whether it was forced or not is irrelevant to the
> technical discussion) can't be molded into something sufficient without
> breaking backwards compatibility.  When that changes, sure, change the
> name and break API.

i'm not sure we need to break the API; it could use some small additions and 
some tweaking. i think specifying the pixel format of the image data is silly 
and unnecessary, but that can be kept. adding the app icon / image data bits 
(something that the original spec was _internally inconsistent on_, btw, 
calling these things different names in different parts of the spec) is 
needed. changing the service name on the bus is something that would be really 
good to happen for the quality and clarity of the platform.

we've been saying all these things for a few years, actually. it never became 
a discussion until i started:

* implementing it in KDE (iow "taking the first step")

* digging my heels in here to make sure people SIT UP and take notice of the 
brokenness we are facing

i'm glad you're speaking up now. where were you in past years? that's why it's 
gotten to this point, and while i wish there was another way to do it, it 
would be just more "status quo is status quo, let it ride openly broken". and 
that is not acceptable.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090625/d89fd0ce/attachment-0001.pgp