Re: panel prelight on focus

[Seth Nickell <snickell stanford edu>]

On Tue, 2002-03-19 at 06:20, Calum Benson wrote:
> Luis Villa wrote:
> 
> > There must be a better way to do this. This behavior is the most
> > frequently reported non-crash bug against the new panel, and if users
> > think it is a bug, it is a bug.
> 
> Well, alternative suggestions are always welcome.  Drawing a dotted box
> around the panel is next-to-invisible, though, so I'm not sure what
> options there are other than changing the panel background colour.

It may be not terribly visible, but I don't tihnk that matters so much.
The problem is that prelight is *really* visible, and it affects the
majority of users in a very negative way. I'd rather incur a negative
effect on 0.x% (hell, or 0x% for that matter) than a negative effect on
9x% of users. And I don't think the negative effect to having it "not
very visible" is much worse than "having it overly visible". People
really hate the prelighting.

I'm wondering if, at this point, we should just make it a preference. I
don't think most people will want it, and users that really need keynav
for the panel can turn it on. They're going to have to make changes to
get accessibility working anyway.

> Some of the reports are probably spotting genuine bugs-- the panel
> should only change colour when the panel itself, not a panel object, has
> focus.  So generally you should only see a panel getting focus when you:

Without using nasty hacks you can't prevent child widgets from
inheriting PRELIGHT though. This breaks a lot of applets. PRELIGHT might
be nice, but its just not the right thing the way GTK uses it. GTK uses
it to mean "mouse is over the applet". So this affects things like
menubars, where all the top level menus then focus. So ideally it might
be nice, but its a technically broken approach (unless, maybe,
inheritance of prelight can be stopped at the panel level, it shouldn't
be done at the per applet level).

-Seth