nazgul@alfalfa.com (Kee Hinckley) (02/21/91)
> Eh? I don't understaaaand.. The XmFileSelectionDialog is pretty > easy to put up and use and so forth. BUT.. There's no button to > move up to the parent directory. And editing the value in the ... > BTW, this is with v1.0.x. I've looked at the v1.1.1 documentation > and it looks as if there was a lot of work done on this widget, > but I don't see any mention of a "parent" button. ... > If any/all of this is fixed in 1.1.x feel free to beat me about > the head and shoulders. It depends on your definition of "fixed". It is certainly the case that you can move about in the hierarchy in 1.1 - just double click on ".." in the directory section. On the other hand I have yet to meet anyone - hacker, novice, Mac user, Unix user or otherwise, who can figure out how to use the FileSB without a detailed explanation. There's a filter section which has a pathname in it, and there's a file section which *also* has the pathname in it. And guess what, you can ignore it all and just use the file section if you want. This is totally bogus. We are almost certain to write our own file selection box for the ]next release of the product - this one is just too confusing. It *might* help if the file portion only had the filename and not the path, but it wouldn't help much, and that would of course make it harder to use for a lot of people, since the common mode of operation is to ignore the pretty little lists and just type the name. The other common error is to change the filter but not put a trailing "/*" on the end of it. That ought to be the default if the user doesn't specify it.
daniel@osf.org (02/21/91)
The 1.1 FSB has now 2 lists for directories and regular files. The directory list on Unix system always shows the parent item as "<current>/..", and if you double click on it , it acts just as a parent button. Daniel Dardailler OSF
nazgul@alfalfa.com (Kee Hinckley) (02/26/91)
> >> Wouldn't it make much more sense for it to be a down arrow? That, people > >> would understand. > >> > > NO, a general human factors rules is "similar controls should behave > similarly". In Windows 3.0 and PM a down arrow is used to indicate > a Drop-Down List or Drop-Down Combination Box. Since the option > menu is NOT a Drop-Down List or Combination Box, a down pointing > arrow should not be used. To a Windows user the Option Menu would > look like a Drop-Down list, if a down arrow graphic was used. Funny, I thought that an OptionMenu *was* a drop-down list. "A drop-down list is similar to a drop-down combination box, but it does not have an entry field for typing text. Instead of an entry field, users see a single selection field with one choice displayed as the default value. As for drop-down combination boxes, users have the same visual cue that a list is hidden; they see a prompt box containing a downward-pointing arrow at the right side of the selection field." IBM SAA CUA Advanced Interface Design Guide, First Ed., Page 68. Sounds like an OptionMenu to me! The only significant difference is that OptionMenus try and be smart and come up on the item that you are most likely to want. If you really don't think that the two are the same, then throw out OptionMenu and give me DropDownList - because right now I've watched several users who had absolutely no idea that they were even active options (on a BW screen), let alone that it would pulldown a menu when they selected it. > Another obvious problem in using a down pointing arrow in the option > menu is that it would imply that the menu will be posted BELOW the > option menu button. In Motif, the Option Menu can often be posted > ABOVE the option menu cascade button. An optimization, nothing more. > The current graphic of a bar > is similar to the bar graphic used in NeXTStep option menu and > similar to the bar in the mwm window menu. I'm not sure it's really relevant what NeXT does, and as to the mwm window menu - novice users don't know what that does *either*. > Lastly, in the UEC SIG held on January 1990 a vote was taken on what > the graphic should be for the Option Menu. The results are: > > Right arrow : 1 - same as cascade menu graphic > Down arrow : 4 - same as IBM CUA "drop-down list" graphic > Bar : 8 - same as window menu graphic and provides visual > cue that menu will appear over graphic How does a little rectangular blob provide a visual cue of anything to someone who has never seen it. Arrows people understand, but blobs are not part of their normal everyday interactions. I assume that vote was made with the assertion that OptionMenus were not DropDownLists. I believe that the difference between the two is so small as to make it undesirable to have both kinds of objects, and that therefore the two objects should be treated as identical. Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
argv@Eng.Sun.COM (Dan Heller) (02/26/91)
BTW, can we remove all the excessive To: adresses? We're all on the same mailing list, you know :-) On Feb 25, 7:11pm, yee@osf.org wrote: > Yes, OptionMenus != DropDownList. Some vendors may chose to > implement DropDownList and used them instead of the OptionMenu. ^^^^^^^^^ HAHAHAHAHAHahahahahhhah (cough) (cough) I love it. <snif> What a great sense of humor :-) Sigh... now, all we need are some internal specs/doc from OSF on "how to sublcass motif widgets" and we'll all be set! :-D :-D --dan
yee@osf.org (02/27/91)
From motif-talk-request@osf.org Tue Feb 26 16:35:22 1991 >> >> > Yes, OptionMenus != DropDownList. Some vendors may chose to >> > implement DropDownList and used them instead of the OptionMenu. >> >> In what way does an OptionMenu behave differently from a DropDownList? >> So far you have told me one thing. That the menu positions itself >> under the cursor. In fact, neither the CUA or the Motif Style Guides >> mention this behavior, so I can't see how it is relevant. >> I think we should take this discussion off-line, or at least change the subject line. I am not saying that OptionMenu and DropDownList are very different. They are not. But since they are different controls (one posting a menu and the other posting a list), a different graphic symbol was used. =Mike
garyo@THINK.COM (Gary Oberbrunner) (02/27/91)
>From motif-talk-request@osf.org Tue Feb 26 16:35:22 1991 >> >> > Yes, OptionMenus != DropDownList. Some vendors may chose to >> > implement DropDownList and used them instead of the OptionMenu. >> >> In what way does an OptionMenu behave differently from a DropDownList? >> So far you have told me one thing. That the menu positions itself >> under the cursor. In fact, neither the CUA or the Motif Style Guides >> mention this behavior, so I can't see how it is relevant. >> I think we should take this discussion off-line, or at least change the subject line. I'm finding the discussion very enlightening. Somehow simplicity has gotten broadsided by creeping functionality. No surprise there, but it's a very clear example of how living with something for a long time obscures its true nature. Maybe it's time for OSF to do Round 2 of the human factors tests... I am not saying that OptionMenu and DropDownList are very different. They are not. But since they are different controls (one posting a menu and the other posting a list), a different graphic symbol was used. =Mike I defy a naive user to tell the difference. You press the button, you takes your choice. - Gary Oberbrunner Thinking Machines Corporation 245 First St Cambridge, MA 02142 garyo@think.com