I like the idea of application certification, and it doesn't
necessarily have to be intimidating or overly restrictive.
There's certainly variance in the degree of scrutiny that could be
performed, but even a basic checklist is a start. <br>
<br>
Note: Not being on the core-devel list, I'm sure what's in place for guidelines now.<br><br>
But the systray discussion triggers the need for me, because MS doesn't
get it right either. Their flexibility/laziness allows for
freedom from application installation to execution to removal.
And it gets them into trouble with memory management, process control,
etc. Their systray is a Wild West (lawlessness or a miserable
Will Smith remake, take your pick) for applications in functionality.<br>
<br>
In the same way that you have expectations when discussing reliable rpm
packages or J2EE manifests, a KDE application should evoke an
agreed-upon consensus on i18n, 'what's this" tags, systray use,
usability, etc. Or if I see that amarok is "Grade AAA Seigo", I
know that I'm only getting the best.<br>
<br>
Are such things being kicked around on other lists? Do people regard this idea well or poorly?<br>
<br>
<br>
<br>
<br><div><span class="gmail_quote">On 8/16/05, <b class="gmail_sendername">Aaron J. Seigo</b> <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tuesday 16 August 2005 09:55, Georges A.K. wrote:<br>> On 8/14/05, Vince Negri <<a href="mailto:vince@bulbous.freeserve.co.uk">vince@bulbous.freeserve.co.uk</a>> wrote:<br>> > Georges A.K. wrote:<br>> > 2) Objects in the systray are singular: that is to say, you don't want
<br>> > two icons that look the same in the systray, even it they relate to<br>> > different instances of something. This is because<br>> > identical icons need to be differentiated by hovering the mouse over
<br>> > them, and then you lose the at-a-glance-ness. Contrast with a taskbar,<br>> > where you do have to potentially negotiate 12 identically-iconed<br>> > document windows.<br>><br>> But how can we enforce such a policy ? It seem to me that it's more
<br>> about educating the developpers than a plasma functionality.<br><br>yes, it is. but we can do things to make getting it wrong harder. like if we<br>do the systray Right(tm) we'll get the default icon by name and if we already
<br>have that icon visible we may be able to merge the two entries or throw up a<br>warning or ... something ;)<br><br>also, don't be surprised if we see "KDE application certification" with KDE4<br>so that we can at least control and manage the apps that our in our SVN.
<br>given that most 3rd party apps simply mimic (often through cut 'n paste ;)<br>what the hundred or three apps we ship do ... this is a good step forward.<br><br>> > 3) Objects in the systray relate to something that is already "working"
<br>> > on the machine. So they can relate to hardware (which is obviously<br>> > always "running") or a running program. Contrast with launcher buttons,<br>> > which start something running that wasn't running before.
<br>><br>> It could also be a sleeping daemon, waiting for user input. Although<br>> it is started, it's not technically running. If I look at my tray<br>> right now, an example would be kscmp (for those who are not familiar
<br>> with SuSE, it's a utility that allows you to change working profiles,<br>> for example wireless settings, printer settings...). Although it<br>> doesn't raelly relate to hardware, nore does it alert me of anything,
<br>> it's still very useful to have.<br><br>yes, and this is the most controversial type of the bunch. should it be an<br>applet? if we force it to be an applet, are we just relocating the problem?<br>perhaps splitting the systray visually to denote the two kinds of icons
<br>(notification vs mini-interface) is the way to go...<br><br>--<br>Aaron J. Seigo<br>GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br><br>Full time KDE developer sponsored by Trolltech (<a href="http://www.trolltech.com">
http://www.trolltech.com</a>)<br><br><br>_______________________________________________<br>Panel-devel mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/panel-devel">
https://mail.kde.org/mailman/listinfo/panel-devel</a><br><br><br><br></blockquote></div><br>