argv@turnpike.Eng.Sun.COM (Dan Heller) (09/19/90)
In article <1990Sep14.172922.27088@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: > > You need to add 2*(number of buttons-1), > >assuming one is a "Cancel", to get the functionality of a single pushpin. > Now you are asking whether having pushpins is better than Okay/Apply/Cancel. > I don't buy the 2* number. In fact, I can just make all of the buttons > do their operations and have no Okay button, then Cancel will take it down > and I have all the functionality of a Pushpin. There is a point to the "default button" in motif dialogs: if this is the only one that take down the dialog, then it's difficult to indicate which buttons to choose. I don't want the user to think he has to select the "cancel" button in addition to any other button displayed just to remove the dialog. "Cancel" has impliciations that are not consistent across all dialogs. In one respect, it should mean: "reverse all changes I've made in this dialog (reset all button values) and close the dialog." Or, it could mean, "reverse the changes that my last "apply" selection caused." Whatever it means or is interpreted as, that interpretation is not the same as "just close the window". A new choice must be made. I've found that the best thing to do in such situations is to label the default button (otherwise known as the "Ok" button) with "close" and the "apply" button has the label "Ok" -- there is no other "Apply" button. "Cancel" doesn't close anything -- in fact, "close" is/should be the ony button in the dialog that closes it. Having "close" be in the same spot in all dialogs and does the exact same thing maintains consistency and reduces confusion among the users. While this seems to be the thing that makes the most "sense", I wonder if any Motif GUI experts out there think that there is anything wrong with that assumption? > Personally I think pushpins > are cute, I'd prefer tearoffs for my menus though, but that's probably hard > to do under X. Pushpins functionally do the same thing as tearoff menus. The argument about pushpins is an interesting one. I didn't quite get the point of it until someone I was corresponding with privately made it clear (altho we've lost contact and I forget who it is). OL does provide a user interface element (pushpin) that is drawn and managed by window manager. Since that pushpin is the sole element responsible for dismissing the popup menu, the application *does* require an open look window manager to provide this element. Without it, the application does not necessarily have to provide a way for the user to dismiss the menu. I argued before that all good window managers (motif, open look, twm) should provide some method for dismissing all toplevel windows -- if you are not using one that does, this could be considered pilot error. I have been convinced that this isn't really a strong argument. Thus, I think the best solution is for the XView toolkit to provide its own pushpin item and not require the window manager to provide it automatically. > But given the lack of a better suggestion I'd love to see > pushpins added to Motif. As noted before -- tear off menus provide virtually the same functionality as pushpins and could thus be implemented without "stealing" the concept of pushpins from open look. The user interface itself needn't match OL or Apple's exactly, but I'm sure someone creative enough can figure it out for himself ;-). -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
toml@ninja.Solbourne.COM (Tom LaStrange) (09/19/90)
In article <142694@sun.Eng.Sun.COM>, argv@turnpike.Eng.Sun.COM (Dan Heller) writes: |> I argued before that all good window managers (motif, open look, twm) |> should provide some method for dismissing all toplevel windows -- if |> you are not using one that does, this could be considered pilot error. |> I have been convinced that this isn't really a strong argument. Thus, |> I think the best solution is for the XView toolkit to provide its own |> pushpin item and not require the window manager to provide it automatically. Are we coming full circle back to the X10 days when if a client wanted a titlebar it created one for itself? We went through this very problem when developing the Open Look side of the OI toolkit. Our dialog boxes started out with their own pushpins and titles, not relying on the window manager to provide them. Then we ran across this OLCI document thing that told us how to ask the window manager for pushpins and other stuff. So we changed our dialog boxes to use this interface and let the window manager provide the pushpin and title. One problem we ran into was the pushpins on popup menus. When the menu begins life, it is an override-redirect window and therefore the window manager doesn't see it. Because of this, the pushpin in the menu has to be owned and operated by the menu. When the user pins it, should the pushpin still be part of the menu or provided by the window manager? Well, we chose to keep it as part of the menu so the user could unpin it when not being used with an Open Look compliant window manager. Of course one can only hope that our menu pushpins look and act exactly like the pushpins provided by the window manager so as not to confuse the user... -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501