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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
