Re: [Usability] Notification Area Preferences



On Mon, Jun 16, 2003 at 07:11:45PM +0100, John Levon wrote:
> On Mon, Jun 16, 2003 at 10:18:45AM -0500, Gregory Merchan wrote:
> 
> Is there any reason you didn't open-cc usability gnome org again ?

I apologize for this. Unbeknownst to me, my ISP started blocking SMTP.
I was bouncing messages through an account I could reach, unaware that
bouncing wouldn't change the To: or CC: fields.

> > > I suspect you will get baffled looks and "well, of *course* I don't want
> > > unidentifiable icons ! I prefer identifiable ones please" ;)
> > 
> > I can't believe I'm going to write this, but that's why the Help button is
> > there.
> 
> Well you have to accept then that this is a clumsy solution. If it's
> really the only one, then fine, but ...

Oh, I do accept that it's clumsy. :-)


> > working; in part, because the tray spec doesn't require the hints.
> > 
> > Best case scenario, the specification changes to require the _NET_WM_NAME
> > or WM_CLASS hint be set. Without that change, either GNOME adopts a special
> > policy, or the checkbox must be there.
> > 
> > The only way to avoid the alert would be to provide a way for applications
> > to tell the tray that the user has changed his mind, which would require
> > an addition to the protocol.
> 
> I apologise in advance for not having read up on the spec, but have
> these issues been covered or discussed ?

Not to my knowledge.


> > Unfortunately, such an addition would also allow apps to do this
> > without user interaction, thus overriding the user's preferences.
> 
> Which would be an obvious bug. Unless you are talking about malicious
> applications, which is a different matter altogether IMHO.

The truly malicious application could work around almost anything. I
probably shouldn't describe how.

Even with an obvious bug, years may pass before there's a correction.
For example, the protocol for the clipboard has been basically the same
for 14 years, yet to this day it is claimed that the clipboard doesn't
work, only supports text, etc. It's better to not risk any such thing,
and to just leave the setting entirely in the tray prefs.


> > Actually, there's another way: don't include any such option in the
> > application. This way there's only one place for it - in the tray prefs.
> 
> Seems reasonable enough to me.

When the HIG describes tray icon expectations, this should be included.


I presume the only major problem now is what to do with unidentifiable
icons. This is only a problem until the spec is changed, but nobody
knows how long that will be.

How about: "Allow nameless icons"?  That should be more intelligible
since the list will be showing names.


Cheers,
Greg



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]