anon@dip.eecs.umich.edu (Omar S. Juma) (11/24/89)
In article <100920130@hpcvlx.cv.hp.com> keith@hpcvlx.cv.hp.com (Keith Taylor) writes: > > Is there any way from within mwm to make root menus scroll? > > I have a root menu that contains more options than will fit virtically > on the screen. What I would like to happen is that the menu scroll > if the cursor is moved to the top or bottom of the menu. > >Do you really want to look at that all at once? > >If you can restructure your menu items into a hierarchy, then you can >convert your root menu into a cascade of menus. Look at the f.menu >function and the Menu { ... } structure in the .mwmrc file. > > >Keith M. Taylor >Hewlett-Packard >Corvallis, Oregon OK. Let's try the question from a different angle. Is there any way from within Motif to make pulldown menus scroll? No, there isn't. Apple caught on to this problem three years ago, and added automatic scrolling to their standard menu manager on the Macintosh. Their reasoning was simple; they wanted to leave the ultimate choice of how long a menu has to be to the programmer. There are logical reasons, if you're not swayed by philosophical arguments. What about small screens? It's perfectly reasonable to run X on a small screen, where some of the larger menus may not be fully visible. And what about pulldown menus whose origin is not the root window, but the menu bar of an application? Or better yet, how about this scenario: - you've got a dialog box - in this dialog box is a pulldown menu with 10 items - the pulldown menu is attached to the dialog box via a push-button that displays the last selected item - the dialog box appears near the top of the screen - you pull down the menu and choose the last item, therefore setting the push-button to that item - the menu is now anchored from its last item - you change your mind, and decide to select the second item - you click on the push-button, and up comes the menu anchored from the last item - you notice that the top three items are above the top of the screen - you look around the Motif documentation for a way around this, and discover there isn't any - you go use a Macintosh, and understand a little bit more about the fine details of user interface systems - you assume, like all of us who have experienced this situation, that it's something OSF temporarily overlooked while they rushed this thing out the door If anyone says "Why don't you move the dialog box?", the error buzzer will sound and you'll be sent back to the audience with no money and no prize, and your tribe will be humiliated for ever more. There are countless details like this that can make or break a user interface system. The problem is that Motif (and even more so, OpenLook) come from companies whose past experience with successful user interfaces rounds out to the number zero. Yes, that means I consider Sunview a zero. Yes, that means I consider Decwindows a zero. Fortunately, Motif is turning out to be a worthwhile system, since Sun was excluded from the design process (yeah, massive flame-on: NFS SUCKS!!!!!), and DEC's influence was moderated by the participation of other organizations, and DEC's own accumulation of experience. Motif simply promises to raise the base level of functionality so that the rest of us can start building better tools and get to thinking about the next few steps. To add more fuel to the fire, here's an off-the-cuff subjective rating of some user interface environments: - Macintosh (Apple): A- - Motif (OSF): B+ - NextStep (NeXT): B+ - SmallTalk (Xerox): B+ - AEGIS/DM (Apollo): B - Andrew (CMU): B - Domain Dialogue (Apollo): B - Open Dialogue (Apollo): B - OpenLook (Sun+ATT): B - Microsoft Windows (Microsoft): C+ - SunView (Sun): C - DECWindows (DEC): C- - Layers (ATT): D+ - X Toolkit: D+ - HP Widget Set (HP): D To shed further light on these numbers, here's how the following would rate by the same subjective analysis: - Apollo DOMAIN filesystem A- - pre-1984 Bell telephone A- - HyperCard B+ - /usr/local/bin/emacs B- - AEGIS B- - UNIX B- - K-Mart C- - /usr/ucb/vi D - TV network news D - DEC mouse D- - NFS D- - Buick Digital Dashboard E+ - DOS E Omar S. Juma EECS Department University of Michigan anon@eecs.umich.edu 313-763-4324 my opinions...
casey@gauss.llnl.gov (Casey Leedom) (12/06/89)
I'm sure I shouldn't do this, but what the hey -- it's been a long time since I last flamed Apollo ... :-) | From: anon@dip.eecs.umich.edu.UUCP (Omar S. Juma) | | To add more fuel to the fire, here's an off-the-cuff subjective rating | of some user interface environments: | | - AEGIS/DM (Apollo): B I'm not sure I can respect anyone's opinion who gives Apollo's DM such a high grade ... :-) I also have objections to Omar rating their file system as highly as he did also, but not nearly so strongly. It's biggest problem is simply the company that controls it: refusing to extend the file system enough to subsume the functionality of the UNIX file system. But most of that stems from Apollo's extreme anti-UNIX feelings. We can only hope that the buy out by HP will help this. But I haven't had any experience with HP, so who knows ... But Omar's feeling on Apollos are to be expected. UMICH is Apollo Country after all ... As for the rest of Omar's comments regarding User Interface Issues, I agree wholeheartedly. It definitely a Good Thing when User Interface Support Software can be successfully generalized -- without making a kitchen sink of it -- to offer User Interface Implementors, and more importantly, Users more options. Casey
wesommer@athena.mit.edu (Bill Sommerfeld) (12/06/89)
In article <40618@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey
Leedom) flames about the Apollo Domain file system:
It's biggest problem is simply the
company that controls it: refusing to extend the file system enough to
subsume the functionality of the UNIX file system.
I just exchanged some mail with Casey about this, and he requested
that I post a followup. His flame was based on information well over
a year out of date; the particular thing that he was complaining about
(semantics of access control) was fixed in SR10, which was designed,
implemented, and shipped to customers months before the HP takeover.
--
Henry Spencer is so much of a | Bill Sommerfeld at MIT/Project Athena
minimalist that I often forget | sommerfeld@mit.edu
he's there - anonymous |