nazgul@alphalpha.com (Kee Hinckley) (09/08/90)
In article <141998@sun.Eng.Sun.COM> argv@turnpike.Eng.Sun.COM (Dan Heller) writes: >In article nazgul@alphalpha.com (Kee Hinckley) writes: >> Application modal won't work without Mwm, system modal works fine. >Is this implementation responsible for the annoying behvior of Motif >applications where if you raise _one_ shell in the app, all of them >raise to the top. How can you allow these windows to act independently >from one another? All the Dialog's will since they are parented off of some window. If you create a separate application shell it shouldn't raise. If you want the dialogs to be separate I _think_ you could parent them off an unmanaged application shell but I'm not sure. I haven't tested all these configurations yet though, so I'm not sure. >> Not having pushpins means that you either let the user get annoyed >> or you create an alternative mechanism for keeping dialogs up. >In XView, pushpins in popup menus is implemented simply by creating >a similar base frame that "looks" like the menu and then mapping it >to the screen. The menu itself (override shell) certainly isn't stuck >up on the screen and left there... Right. But it used to be that the only way you could do this was to tell the window manager. Has that changed? Do pushpins now work under Mwm? >> In Motif this is the difference between the "Ok" button (which takes >> it down) and the "Apply" button, which keeps it up. You have both >> and the user decides which to select. Given that XView isn't made >> with a widget set I'm not sure how easy it would be to add an extra >> button to your dialog boxes. >I don't really understand what you aer asking here, but I feel >compelled to provide some sort of response :-). Unlike the Motif >toolkit, XView doesn't provide any pre-built dialogs -- therefore, Ahh. Does XView have any tools for building dialogs (forms, tables...), or do you put all of the pieces into a bulletin board? -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 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@turnpike.Eng.Sun.COM (Dan Heller) (09/10/90)
In article <1990Sep8.060601.2512@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: > >Is this implementation responsible for the annoying behvior of Motif > >applications where if you raise _one_ shell in the app, all of them > >raise to the top. How can you allow these windows to act independently > All the Dialog's will since they are parented off of some window. > If you create a separate application shell it shouldn't raise. > If you want the dialogs to be separate I _think_ you could parent > them off an unmanaged application shell but I'm not sure. > I haven't tested all these configurations yet though, so I'm not sure. Since I can't get Motif 1.1 to work yet, I'm still stuck with testing 1.0. Under Motif 1.0, I have not been able to successfully map a dialog shell that doesn't have a parent that isn't mapped. Since the parent must be non-null (DialogShells are popup shells that require parents), there doesn't seem to be a way to escape the problem I described above. ...except for: don't use dialog shells. One could argue that by using application or toplevel shells, I can avoid the problems -- however, the cost of doing that is the loss of all those shell-style resources that are available in the dialog shell, but not in the other shells.. Rather, I'd have to use a vendor shell and set all those resources myself. > >> Not having pushpins means that you either let the user get annoyed > >> or you create an alternative mechanism for keeping dialogs up. > >In XView, pushpins in popup menus is implemented simply by creating > >a similar base frame that "looks" like the menu and then mapping it > >to the screen. The menu itself (override shell) certainly isn't stuck > >up on the screen and left there... > Right. But it used to be that the only way you could do this was to > tell the window manager. Has that changed? Do pushpins now work > under Mwm? Tell the window manager what? This is the way it works ... a push-pin menu has its first item appear to be a pushpin. When the pointer selects the menu item that appears to be a pushpin from the user's point of view, a new toplevel shell-type widget is created ... in xview terms, the menu is unmapped and a command frame is created with a panel that has panel items that all look just like the menu items (or as close as they could) and is displayed at the same place as the menu. Since this new frame does not have override_redirect set, the window manager puts its decorations around it as it would for any other shell. > > Unlike the Motif > >toolkit, XView doesn't provide any pre-built dialogs -- therefore, > Ahh. Does XView have any tools for building dialogs (forms, tables...), > or do you put all of the pieces into a bulletin board? XView has a "panel" item which is like a composite widget. It's got capabilities similar to a combination of the form, bulletinboard, and row-column widgets. You can also create a panel that has a scrollbar attached, but this "technically" violates open look (this is a rather silly limitation and people use them all the time -- I wouldn't be surprised if OL change its spec to support this in the future). "Command Frames" are similar to DialogShells that have BulletinBoard children -- many things are automated on the window manager's behalf. While most of the layout is handled by the panel, they don't go as far as providing default action area buttons such as Ok, Cancel, etc. You have to do that yourself. However, the ease and simplicity of creating objects in XView is such that the advantages and disadvantages of each cancel each other out. XView's "panel" is certainly not as robust as all the composite widgets that are available in Motif, but it does serve its purpose and has some excellent qualities in and of itself. Also remember, XView is quite young and is still under substantial development efforts; they are working on new and better mouse traps all the time :-) I've been watching the development of Motif from OSF and XView from sun over the past year. Sun's motto should be "we try harder". The number of bug fixes and product enhancements from XView 1.0 -> 1.1 -> 2.0 has been respectible. The move from Motif 1.0 to Motif 1.1 has been disapponting. It's especially bothersome when you see how long it took OSF to get there. The "new features" are somewhat yawners and many older, more serious bugs still exist. Don't ask me which I like better because I consider the two to be apples and oranges; you can't compare them. I think both toolkits have their strong points and their drawbacks. Both are going thru growing pains right now and need time to mature. To their credits, they both do the most important thing well -- they provide their respected user interfaces for applications. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.