[23092] in Athena Bugs
Re: Temporary workaround for panel lossage
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jul 18 13:45:02 2003
From: Greg Hudson <ghudson@MIT.EDU>
To: John Hawkinson <jhawk@mit.edu>
Cc: bugs@mit.edu
In-Reply-To: <20030718170312.GN7118@multics.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1058550287.21136.51.camel@error-messages.mit.edu>
Mime-Version: 1.0
Date: 18 Jul 2003 13:44:47 -0400
On Fri, 2003-07-18 at 13:03, John Hawkinson wrote:
> I just had a user for whom this did not quite cut it.
This sounds like the experience of a user whose dotfiles override the
setting of LD_LIBRARY_PATH on Linux. (Was this on Linux? You didn't
mention which platform.) Using the native GConf library rather than the
Athena one can cause both of the first two failure modes you saw: in
many cases it will fail to get a lock and not work at all, yielding the
broken menu panel, and when it does work it will use the native schemas
rather than the Athena ones, yielding the Red Hat icon. But once you
have your own preferences, such as the ones produced by the conversion
script, you're fine.
(I'll readily agree that it would be better if our software didn't rely
on LD_LIBRARY_PATH being set correctly. I'm just not sure how, for
native-built binaries. We could put wrapper scripts in /usr/athena/bin
for programs we know about, like gnome-panel, but that can't be a 100%
solution; people can install local RPMs containing GNOME programs and we
can't wrap those. Perhaps special-casing gnome-panel and gnome-terminal
would be appropriate, just to make things work a little better.)
> What data would you like me to gather in similar situations?
(1) The platform, of course.
(2) Whether the dotfiles muck with LD_LIBRARY_PATH.
(3) The contents of the .gnome directory, in order to figure out
why the conversion script created the redundant www icons.
