From kde-panel-devel Thu Nov 26 17:28:25 2009 From: "Aaron J. Seigo" Date: Thu, 26 Nov 2009 17:28:25 +0000 To: kde-panel-devel Subject: Re: messaging-indicator in kdereview? Message-Id: <200911260928.25702.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=125925656111122 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1530171556==" --===============1530171556== Content-Type: multipart/signed; boundary="nextPart1264803.HebKZbmYvk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1264803.HebKZbmYvk Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On November 26, 2009, Jonathan Riddell wrote: > On Tue, Nov 24, 2009 at 05:49:22PM +0100, Sebastian K?gler wrote: > > It seems there's a messaging indicator applet in kdereview since the > > start of November. It doesn't build however (with karmic's packaged > > libindicate-qt) and didn't get any non-scripty activity in more than two > > months. Also, it's built unconditionally, even if its dependency > > (libindicate-qt) isn't there, another breakage. Feature freeze is > > looming, and I've not seen it proposed for review or at least a build > > fix. > > > > I'd suggest to remove it from kdereview. >=20 > It was proposed a while ago but rejected because it doesn't use the > new systray/notifier item spec (a shame the spec dosen't make it clear > that this is an intended use).=20 a protocol specification should not indicate all possible uses. that steps= =20 outside what a protocol specification does and gets into application-of-the- technology territory. the intent of the spec is to allow for both known and= =20 unforeseen application of status notification, so it's really unreasonable = to=20 expect such things in the spec itself as it would be instantly limiting=20 (besides being off topic). it would be like describing how a webbrowser's t= abs=20 and location bar should look like in the html spec ;) now, that said, i did, *repeatedly* communicate this aspect of the technolo= gy=20 to people who were working on this code at Canonical. so the "it's a shame.= =2E"=20 thing feels pretty unfair. it wasn't a secret, it was just impossible to ge= t=20 it heard through the iron curtain of Ayatana. i also don't believe that had this been spelled out in the spec that it wou= ld=20 have changed what happened in the least. there was already a decided upon=20 path, and i've discovered through years of watching that those decisions ar= e=20 ultimately unflexible. i understand this is a tradeoff made for project=20 control and release marketing reliability. > It's still a > great deal better than what's in KDE currently the UI is nice, the idea is good, the implementation is, tbh, ungreat. our= =20 shared users will suffer as a consequence. i looked at the code and had thi= s=20 been developed openly with upstream coordination, i would have offered=20 feedback on it that would have highlighted a few issues. but if a group=20 doesn't play by the rules of the game, i refuse to play the game with them = at=20 all. this is not petty, btw, it's protecting the value of the commons. i wi= ll=20 not offer feedback on efforts that subvert the established process, no matt= er=20 how good an idea it represents in the moment. the long term consequences of= =20 separate silos, non-open-consensus development and downstream fracturing ar= e=20 simply too severe. now, i really dislike treating an ally like that, but i simply can't abide = the=20 behaviour. it is not welcome here and it will never be welcome here. were t= hat=20 to continue, your would become increasingly isolated in your efforts and wh= ile=20 pushing on with your self-grown agenda we would compete for developers. giv= en=20 project Timelord, i don't think that aligns with your goals at all. that's the crappy doom, but here's the happy glow: the recent meeting we had about using status notifier spec in Ubuntu's gnom= e=20 and working on integrating dbusmenu into both KDE and GNOME's implementatio= ns=20 is a great step towards playing by the rules of the commons. it's consensus= in=20 action, it's getting needs met, it's communicating and coordinating our pla= ns.=20 i'm really, really hopeful that's the way it continues and currently am=20 committed to supporting those movements. let's try to ensure that those sor= ts=20 of efforts are what the Kubuntu - KDE relationship are characterized by goi= ng=20 forward. let's make that the reality and not accept anything less. (interestingly, i recently came across some academic literature via a frien= d=20 that documents how societies with successful long term commons often have=20 ultra-strong us-and-them, in-and-out boundaries with very real consequences= =20 for those on the other side of them.) > and continues to > be developed as a standalone project with support upstream in KMail and > Quassel now. personally, i find such ad-hoc-additions-to-upstream to be absolutely=20 repugnant. it's not a sustainable development model because we have so many= =20 actors who would 'innovate' and if we chase after every cool cat that comes= =20 into the neighbourhood our software is going to become riddled with things= =20 that have no consensus support and which in many cases will fade away. yes, yes, yes, i know, consensus is hard to get. but it prevents most=20 (granted, not all) fuck ups. if you look at the majority of really big fuck= =20 ups in the last few years on the Linux desktop, it's been when some cowboy= =20 somewhere or another decides "this is the way to go!" without any consensus= =20 generation outside his little circle of BFFs and often in direct opposition= to=20 the general consensus. there are a few people in this world who can get awa= y=20 with that kind of behaviour because they are just that good/lucky. most of = us=20 are not those people and shouldn't pretend otherwise. =2D-=20 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 Development Frameworks --nextPart1264803.HebKZbmYvk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAksOurkACgkQ1rcusafx20PM1gCeNEM4eDgcTD1a7dab2g+i+E0I GyIAn1fWBXBPydJ/MTKVMGzdL7NUIGWj =X7ch -----END PGP SIGNATURE----- --nextPart1264803.HebKZbmYvk-- --===============1530171556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============1530171556==--