[35] in Athena User Interface
Re: Task list
daemon@ATHENA.MIT.EDU (Richard Tibbetts)
Fri May 12 14:49:25 2000
Message-Id: <200005121849.OAA01159@hikari-no-ken.mit.edu>
To: Dan Winship <danw@helixcode.com>
cc: aui@MIT.EDU
In-reply-to: Your message of "Fri, 12 May 2000 14:11:55 EDT."
<200005121811.OAA01746@twelve-monkeys.helixcode.com>
Date: Fri, 12 May 2000 14:49:17 -0400
From: Richard Tibbetts <tibbetts@MIT.EDU>
On 5/12 Dan Winship <danw@helixcode.com> wrote:
> There are some problems with this approach: the normal GNOME menu is
> not an applet, it's part of the panel, and that gives it some special
> powers. I started writing an Athena menu applet a few months ago, in
> /mit/gu/gnash/. I forget exactly how it broke, but I think one problem
> was that you couldn't press on the icon then and drag into the menubar.
> It's possible that this is fixable though: I didn't know much Gtk at
> the time.
That is good information. I was under the (apparently mistaken)
impression that the menu was just a special applet. I will revisit the
code before I make any sort of descision then.
> [Gnash also includes code to parse the rather interesting Dash menu
> definition file format. You may or may not have use for that. (I
> figured that allowing the fl's to only maintain a single menu file
> during the transition period would be a win.) It also has some hacked
> tooltip code to allow for big dash-style tooltips. (GtkTooltip doesn't
> deal well with very large, or preformatted tips).]
This is a difficult problem, not certain what the solution will be. I
might be inclined to have a single top level entry "Dash menus" with
all of the dash stuff there, for the interim.
> But the look, feel, and feature set of the built-in panel menus are a
> moving target, so the old Athena Menu Applet would not match the new
> GNOME menu. You're likely to have to continually steal code from the
> panel to make it keep working "right". (At the moment, it doesn't deal
> with non-default panel sizes, for instance, and it would be nice if
> there were icons in the menus for the programs that had them.)
>
> OTOH, there isn't any nice way to make a dynamically-changeable menu
> in the existing panel menu framework. So the applet may turn out to be
> the best (or only) answer.
My thoughts here were that a crufty looking Athena menu (which will
continue to work with new panels) is better than being stuck with a
cruft panel. The implicit assumption is that maintaining an applet is
not much more work than maintaining a sizable patch to panel.
> That needs to be thought out a bit. The (il)logical extension of it
> would be that "Netscape" wouldn't appear in the menu until after the
> user typed "add infoagents".
Certainly. Personally I think that having infoagents be a locker is
poor, since Netscape is probably the piece of software that the most
people run on Athena (as distinct from xterm, which we run for them).
I fully plan to have a default set of software in the menu, that the
user can augment by adding lockers. For instance, I would also be
inclined to have Maple and Matlab be there by default. At this point
though, I think that discussion of what specifically should be in the
base set of applications should wait.
tibbetts
-*- http://www.mit.edu/~tibbetts -*- finger tibbetts@monk.mit.edu -*-
