[Panel-devel] Systray (was Re: Drag'n'drop everything)

[Wade Olson]

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. 

Note: Not being on the core-devel list, I'm sure what's in place for 
guidelines now.

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.

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.

Are such things being kicked around on other lists? Do people regard this 
idea well or poorly?




On 8/16/05, Aaron J. Seigo <aseigo at kde.org> wrote:
> 
> On Tuesday 16 August 2005 09:55, Georges A.K. wrote:
> > On 8/14/05, Vince Negri <vince at bulbous.freeserve.co.uk> wrote:
> > > Georges A.K. wrote:
> > > 2) Objects in the systray are singular: that is to say, you don't want
> > > two icons that look the same in the systray, even it they relate to
> > > different instances of something. This is because
> > > identical icons need to be differentiated by hovering the mouse over
> > > them, and then you lose the at-a-glance-ness. Contrast with a taskbar,
> > > where you do have to potentially negotiate 12 identically-iconed
> > > document windows.
> >
> > But how can we enforce such a policy ? It seem to me that it's more
> > about educating the developpers than a plasma functionality.
> 
> yes, it is. but we can do things to make getting it wrong harder. like if 
> we
> do the systray Right(tm) we'll get the default icon by name and if we 
> already
> have that icon visible we may be able to merge the two entries or throw up 
> a
> warning or ... something ;)
> 
> also, don't be surprised if we see "KDE application certification" with 
> KDE4
> so that we can at least control and manage the apps that our in our SVN.
> given that most 3rd party apps simply mimic (often through cut 'n paste ;)
> what the hundred or three apps we ship do ... this is a good step forward.
> 
> > > 3) Objects in the systray relate to something that is already 
> "working"
> > > on the machine. So they can relate to hardware (which is obviously
> > > always "running") or a running program. Contrast with launcher 
> buttons,
> > > which start something running that wasn't running before.
> >
> > It could also be a sleeping daemon, waiting for user input. Although
> > it is started, it's not technically running. If I look at my tray
> > right now, an example would be kscmp (for those who are not familiar
> > with SuSE, it's a utility that allows you to change working profiles,
> > for example wireless settings, printer settings...). Although it
> > doesn't raelly relate to hardware, nore does it alert me of anything,
> > it's still very useful to have.
> 
> yes, and this is the most controversial type of the bunch. should it be an
> applet? if we force it to be an applet, are we just relocating the 
> problem?
> perhaps splitting the systray visually to denote the two kinds of icons
> (notification vs mini-interface) is the way to go...
> 
> --
> Aaron J. Seigo
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
> 
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
> 
> 
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
> 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050816/a8d3d69b/attachment-0001.html