kill the systray?

[Aaron J. Seigo]

On Thursday, September 26, 2013 12:19:11 Matthias Klumpp wrote:
> Incompatibilities are okay, IMHO, as long as they really
> provide improvements and are not just bikeshed about e.g. function
> naming or wheel-reinventing of working specs.

even then, it’s often best to just use what is already there and extend it as 
necessary. creating new things comes with huge costs, not just to us but in 
particular to our users and 3rd party app developers.

users get to deal with chaos while everyone re-syncs their implementations; 
they get to deal with new bugs; and devel time spent on doing that could have 
been spent delivering new value to the user instead of re-providing the same 
features that already exist.

3rd party app devs now get to deal with yet another possible protocol / spec 
in a big feature matrix with different versions of different environments 
supporting different things.

i think people hugely underestimate the cost of new specs. we need to show a 
respect for *platform development*. it’s not our own little sandbox / toybox, 
we’re not just adding new features here and there with no knock-on costs.

in a phrase: we aren’t writing the next application, we’re working on platform 
definitions.

so this new notification spec had better be the most amazing thing ever and 
come with hot chocolate and dancing butterflies.

> > if that is indeed what happens and it becomes a GNOME Shell specific
> > thing, i don’t think we should implement support for it for all the same
> > reasons we’re not implementing support for Mir.
> 
> Jup, we shouldn't do that then. But I can't see what is GNOME-specific
> about it (yet).

what is GNOME-specific: it is being developed for GNOME Shell and it will only 
be implemented there. meanwhile, we have existing specs that many others are 
using.

> Meanwhile I will ask some people at GNOME about placing the "tray"
> data at different positions and implementing a tray XDG spec in line
> with GNOME design principles. 

so .. you want to make yet another system tray protocol?

despite the fact that we have one that is used by other projects, including 
unity?

if so, that has got to be the worst idea i’ve heard all week. we don’t need 
more specs just to satisfy one projects NIH or self-centered insistence that 
their design principles somehow invalidates all other things.

because if we go down that road, then one project will design everything with 
no input from anyone else. all the other projects become vassals without any 
self-direction to that project.

and seriously: fuck that.

-- 
Aaron J. Seigo