cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/04/90)
> I haven't been reading the UNIX trade rags much lately. Can you give refs > for this 'mudslinging campaign' and particularly their claim that OL is a > 'closed, proprietary standard'? That is complete rubbish and deserves the > widest possible refutation. The mudslinging I refered to is an OSF paper entitled "OSF/Motif: Unparalleled Portability. This is dated July 1990 and has a part number (?) of OSF-1-WP4-0790-1. This is a comparison of OSF/Motif with OPEN LOOK and, of course attempts to show Motif in the best posssible light while making the unenlightened reader wonder why Sun and AT&T ever bothered with OPEN LOOK. It is also rather economical with the truth. Although they don't go so far as to claim outright that OPEN LOOK is closed and proprietary this is the clear slant of the document. Here are some choice extracts: "...the XView toolkit is more difficult to extend than a toolkit based on the Xt Intrinsics level of the X Window System. Developers creating application-specific widgets must write to the Xlib level (roughly comparable to coding in assembly level)." (p10) OK, the first part is true. But the second part is kind of wierd. XView uses a different paradigm to Xt based toolkits: you don't program in XView by creating application specific widgets. It seems rather peculiar to criticise XView for making it difficult to do something that you wouldn't normally want (or need) to do. Besides, writing Xlib calls can hardly be compared to writing assembly level -- Xlib drawing is more like GKS without normalization pipelines. "The OPEN LOOK GUI (XView implementation) is currently running on SPARC, 80386 and 680x0 architecture computers..." (p11) In July 1990 it was also running on DECstations. If the Convex C compiler hadn't blown up while compiling the text sub-window code (insufficient symbol space) it would have been running on at least one Convex C-1. Porting XView to BSD systems should not be a major exercise and I would guess that there are several unannounced ports of version 1 around. Version 2 ports will become common when Sun replaces the missing files in the XView 2 distribution (are you listening Sun?). "None of the OPEN LOOK toolkits currently complies with the ICCCM specifications for interclient communications." (p11) This one sentence is responsible for my antipathy towards this document. Sun claims that XView conforms to the ICCCM conventions and I have found no evidence of any ICCCM violations. I believe that AT&T are also of the opinion that OLIT is also ICCCM compliant. The above is a very serious accusation and requires some explanation from the OSF. If they actually have evidence of departures from the ICCCM these departures are contrary to the intent of the OPEN LOOK developers and should be reported so that they can be fixed. "Dependence on proprietary protocols requires the presence of the OPEN LOOK window manager for proper operation of OPEN LOOK applications. This dependence can hinder the ability of OPEN LOOK clients to work with other clients to work with other clients on heterogenous networks." (p11) OPEN LOOK uses its own protocols to support interclient communications that are not covered by the ICCCM (yet), such as drag-and-load and pinnable menus. Since Motif does not support these (unless these features have been extremely well hidden by the people at OSF) we can hardly expect the OSF to point this out. We could play semantic games for ever about whether the OPEN LOOK protocols are proprietary or not. They do, however, conform to the ICCCM rules regarding vendor extensions. The real point is that I have used OPEN LOOK clients in conjuction with non-OPEN LOOK window managers (the X11R4 version of twm and DECs dxwm) and while the clients may not work "properly" in the sense of having push pins in menus and allowing file icons to be dropped on them they do work acceptably in such circumstances. "OPEN LOOK implementations are currently limited to eight-byte [shurely shome mishtake] character sets and are English-based." (p11) Whew --- this only just made it before Kanji OPEN LOOK was announced. "... the OPEN LOOK toolkits, NDE, XView and Xt+, are proprietary to individual, for-profit organizations." (p12) But Sun give the XView source away for nothing. "OSF/Motif has already achieved widespread industry acceptance outside the sphere of its original propenents." (p15) I accept that more vendors supply Motif binaries than OPEN LOOK binaries but the last count I saw seemed to show that OPEN LOOK had the lead as far as ISV applications vendors were concerned. In all probability neither interface has been around long enough for a clear trend to be established. ------------------------ Closing note: I don't like to see negative marketing of this kind. I believe that is an insult to the consumer and is does no credit to the people who indulge in it. Both OPEN LOOK and Motif have their good points. Neither one is about to go away. An important point is that workstations purchases are rarely (if ever) determined by GUI considerations. This means that many people are likely to end up with networks running a mixture of OPEN LOOK and Motif. I would much rather see the OSF and the AT&T/Sun axis getting together to improve the interoperability of OPEN LOOK and Motif rather than trying to score cheap shots of one another. End of sermon. Chris Flatters ----- End Included Message -----
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/05/90)
>>In July 1990 it was also running on DECstations. > >If it's handy, could you give me a reference for this? I'd like to >run Open Look on a DS3100. You can reference me. I took the source from expo.lcs, applied the patches for the DECstation and tried building it. After that I found the comment about the way the Ultrix/DS3100 C compiler treats void and tried again -- this time it worked. The only other trick to this was that DEC do not use .snf fonts but their own font format (actually I think that this is a display PostScript format) so you have to substitute their font compiler for the standard X11 compiler: I didn't see this mentioned in the documentation (Sun may have been assuming that you would build XView for X11R4 rather than DECwindows). There are currently two problems if you want to get XView onto a DECstation. The first is that DECwindows has a X11R3 server so that you need the file giving pre-R4 ICCCM support which appears to be missing from the xview2 source distribution (see several previous xpert mailings). The second is that the xview2 patches for the DECstation haven't been released yet. My recollection of the DECstation patches is that they messed with configuration files rather than the code, so it is possible that specific DECstation patches are not necessary for XView rev 2. The DECstation patches for the first release of XView seemed to appear fairly quickly so it probably easiest to keep an eye on the contrib area on expo.lcs over the next month or so and wait for Sun to pull their finger out and post a patch to XView. Chris Flatters
guy@auspex.auspex.com (Guy Harris) (09/06/90)
>Sun claims that XView conforms to the ICCCM conventions and I have found >no evidence of any ICCCM violations. Well, I have - XView doesn't support INCR properties. I don't know whether this is an official violation, but 1) the ICCCM doesn't appear to say support of them is optional, and 2) even if it *is* optional, not supporting them can be annoying if you want to cut and paste a sufficiently large chunk of text. I've filed a bug report on this. Also, there's a bug in XView where it gives the TARGETS target a type atom of TARGETS rather than ATOM; a bug report+fix has been sent in about this. >"Dependence on proprietary protocols requires the presence of the >OPEN LOOK window manager for proper operation of OPEN LOOK applications. >This dependence can hinder the ability of OPEN LOOK clients to work with >other clients to work with other clients on heterogenous networks." (p11) Does Motif have its own protocols for communication between Motif clients and "mwm"? If so, then unless support for those protocols is less necessary for Motif clients than support for the OL protocols is for OL clients, this would appear to be a case of the pot calling the kettle black. >"... the OPEN LOOK toolkits, NDE, XView and Xt+, are proprietary to >individual, for-profit organizations." (p12) Hmm. Does this mean that OSF isn't an individual organization, that OSF isn't a for-profit organization, or that Motif isn't proprietary to the OSF? (Even if it isn't a for-profit organization, its main members sure are....)
randy@erik.UUCP (Randy Brown) (09/06/90)
uunet!auspex!guy (Guy Harris) writes: >Does Motif have its own protocols for communication between Motif >clients and "mwm"? I have read that the modal dialog features of Motif depend on mwm in what is probably a private protocol. This allows either "application modal" (user can interact with other clients) or "system modal" (answer my question or turn off the power...). Keyboard focus traversal under Motif is another interesting feature I'm eager to try under alternate window managers, but I have no evidence that it uses a private protocol. The pushpin protocol Open Look uses may be private (I've seen pushpins work under mwm, but I could be experiencing an alternate reality), but another point to consider is that I doubt that pushpin failure would wreak as much havoc as modality failure... If the application is SURE it's behaving modally and isn't, some interesting behavior could result.
nazgul@alphalpha.com (Kee Hinckley) (09/06/90)
In article <9009052346.AA27999@erik.uucp> randy@erik.UUCP (Randy Brown) writes: >uunet!auspex!guy (Guy Harris) writes: >>Does Motif have its own protocols for communication between Motif >>clients and "mwm"? > >I have read that the modal dialog features of Motif depend on mwm in >what is probably a private protocol. This allows either "application >modal" (user can interact with other clients) or "system modal" (answer >my question or turn off the power...). Keyboard focus traversal under Application modal won't work without Mwm, system modal works fine. >Motif is another interesting feature I'm eager to try under alternate >window managers, but I have no evidence that it uses a private protocol. Keyboard traversal is entirely in the widget set. >The pushpin protocol Open Look uses may be private (I've seen pushpins >work under mwm, but I could be experiencing an alternate reality), but >another point to consider is that I doubt that pushpin failure would >wreak as much havoc as modality failure... If the application is SURE >it's behaving modally and isn't, some interesting behavior could >result. As I remember there were two things in Open Look. One was pushpins, the other was style sheets, although maybe the latter isn't true (must have been the same alternate reality :-). I agree that application modal is potentially a more dangerous problem, however I think it's easier to fix (set the rest of the app insensitive) than pushpins. Not having pushpins means that you either let the user get annoyed or you create an alternative mechanism for keeping dialogs up. 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. But in any case, when it comes to protocols outside of the ICCCM neither is 100% pure. But are we really seriously trying to extract facts from a marketing brochure? Seems like a pretty hopeless task to me! -- 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/07/90)
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? > 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... > 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, you don't have a situation where you "add a button". Since you are responsible for building all your own dialogs, if you add a button, you do it at the time you create it. It is certainly possible to do it, but the analogy isn't the same; at least, it isn't what I think you might be looking for. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
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.
emike@cpg.trs.reuter.com (E. Mike Durbin) (09/12/90)
|> > 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... |> |> > 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, |> you don't have a situation where you "add a button". Since you |> are responsible for building all your own dialogs, if you add a |> button, you do it at the time you create it. It is certainly |> possible to do it, but the analogy isn't the same; at least, it |> isn't what I think you might be looking for. The problem is that XView applications DEPEND on the window manager dismissing popup, and even worse, killing the application. For example, Sun's Calendar Manager will use a popup window for entering an appointment. With out OLWM, there is NO WAY do dismiss this popup if it defaults to being push pinned in! In X, if you zap any client window, XLIB DOES AN EXIT, killing the entire application. This is real serious if you have a multi-threaded application that uses popups for lots of windows. Without OLWM, the screen becomes cluttered with popups than can NEVER be dismissed! Also, there is NO WAY to quit the application without OLWM or zapping the window. This, to me, it the only architectural flaw with Open Look (or is it with XView?). -------------- E. Mike Durbin Rich/Reuters Trading Room Systems emike@cpg.trs.reuter.com or uunet!richsun!emike
dshr@eng.sun.COM (David Rosenthal) (09/13/90)
> In X, if you zap any client window, XLIB DOES AN EXIT, killing the entire > application. > This statement is not true in an ICCCM-compliant environment. The ICCCM defines two protocols that clients (especially those with multiple top-level windows) should use to avoid this problem. See Sections 5.2.1 & 5.2.2 (page 542 of the Digital Press book) describing the WM_SAVE_YOURSELF and WM_DELETE_WINDOW protocols. A client that uses these two protocols can be assured that an ICCCM compliant window manager will never delete its windows or kill it without warning. David.
smarks@eng.sun.COM (Stuart Marks, There go I but for the grace of Root) (09/13/90)
emike@cpg.trs.reuter.com (E. Mike Durbin) writes: | The problem is that XView applications DEPEND on the window manager dismissing | popup, and even worse, killing the application. For example, Sun's Calendar | Manager will use a popup window for entering an appointment. With out OLWM, | there is NO WAY do dismiss this popup if it defaults to being push pinned in! | In X, if you zap any client window, XLIB DOES AN EXIT, killing the entire | application. | | This is real serious if you have a multi-threaded application that uses popups | for lots of windows. Without OLWM, the screen becomes cluttered with popups | than can NEVER be dismissed! | | Also, there is NO WAY to quit the application without OLWM or zapping | the window. | This, to me, it the only architectural flaw with Open Look (or is it | with XView?). The above statements are emphatically NOT true. XView does not require OLWM to dismiss or quit windows. XView applications depend on the existence of an ICCCM-compliant window manager for dismissing and quitting. XView uses the WM_DELETE_WINDOW protocol (described in sections 4.2.8 and 5.2.2 of the ICCCM) to implement these functions. The ICCCM is an X Consortium standard. It is not Sun- or OPEN LOOK-specific in any way. Any window manager that has a user interface for sending the WM_DELETE_WINDOW message can use it to dismiss or quit XView applications. Twm and friends, for example, have such a facility. Here are the relevant sections of my .twmrc file: LeftTitleButton "menu12" = f.menu "windowops" RightTitleButton "opendot" = f.delete menu "windowops" { "Window Menu" f.title "Delete" f.delete "Kill" f.destroy "Save" f.saveyourself "Refresh" f.refresh # ... } You can invoke the delete function by bringing up the "Window Menu" and hitting Delete or by hitting the button next to twm's resize handle. It works perfectly fine for dismissing XView popups and for quitting XView applications safely. For example, if you have unsaved edits in an XView text editor, and you invoke the Delete function, the editor will raise a confirmer to allow you to cancel the quit. Also, mwm's f.kill function will send WM_DELETE_WINDOW if the application has asked for it. This function is bound to the Close item on the mwm's Window Menu, so it even does what you'd expect it to do. I imagine that dxwm and gwm also have some facility for sending WM_DELETE_WINDOW messages. Once again, XView has no dependency on any particular window manager for supporting the dismiss and quit operations. XView works just fine with any ICCCM-compliant window manager. s'marks Stuart W. Marks ARPA: smarks@eng.sun.com Window Systems Group UUCP: sun!smarks Sun Microsystems, Inc.
argv@turnpike.Eng.Sun.COM (Dan Heller) (09/13/90)
In article <999@richsun.cpg.trs.reuter.com> emike@cpg.trs.reuter.com (E. Mike Durbin) writes: > The problem is that XView applications DEPEND on the window manager dismissing > popup, and even worse, killing the application. For example, Sun's Calendar > Manager will use a popup window for entering an appointment. With out OLWM, > there is NO WAY do dismiss this popup if it defaults to being push pinned in! > In X, if you zap any client window, XLIB DOES AN EXIT, killing the entire > application. I'm kind of at a loss for an appropriate response because I don't know of any particular case where this is absolutely true. You may be right -- I'm not disputing it; although I have strong reservations (see last paragraph). However, from what *I* have seen of the code, XView does everything within the X protocol to map and unmap windows. There is nothing sneaky going on with the window manager to do stuff like this. Note: There *are* cases where XView registers OL or (more simply) XView specific atoms that only an OPEN LOOK window manager will understand. However, the Motif toolkit is just as "guilty" of doing this sort of thing. As far as I know, the ICCCM doesn't say anything restricting applications and window managers from communicating with one another above and beyond what the ICCCM has outlined. Therefore, I put "guilty" in quotes because it's not necessary _wrong_ to do such things. One can't condemn XView (or OpenLook) for doing the types of things that allow it to specify an interface such as push-pins, drag and drop, system menu hints, menubar info, headers, footers, etc... On the same token, one can't condemn Motif for doing the same type of thing (which it does). However, your arguments are heard. There is a good reason for wanting an application to communicate well with any arbitrary window manager. That way, one isn't tied to using olwm or any arbitrary window manager. But to do that, you end up with a toolkit and window manager that is a lowest common demoninator and thus less dynamic as it could be. > Also, there is NO WAY to quit the application without OLWM or zapping > the window. This simply isn't true. It's not that olwm (or XView) is without bugs, but I have never had this problem. > This, to me, it the only architectural flaw with Open Look (or is it > with XView?). Sounds like you have a problem with your particular platform. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
golding@saturn.ucsc.edu (Richard A. Golding) (09/13/90)
In article <999@richsun.cpg.trs.reuter.com> emike@cpg.trs.reuter.com (E. Mike Durbin) writes: >The problem is that XView applications DEPEND on the window manager dismissing >popup, and even worse, killing the application. For example, Sun's Calendar >Manager will use a popup window for entering an appointment. With out OLWM, >there is NO WAY do dismiss this popup if it defaults to being push pinned in! >In X, if you zap any client window, XLIB DOES AN EXIT, killing the entire >application. > >Also, there is NO WAY to quit the application without OLWM or zapping >the window. >This, to me, it the only architectural flaw with Open Look (or is it >with XView?). This isn't an XView/OLWM problem, it's a problem with non-ICCCM-compliant window managers. XView clients rely on the window manager sending the WM_DELETE_WINDOW message, telling the client to take down the window in an orderly way. When you pull a pushpin in OLWM, the window manager sends such a message. The Delete Window protocol is one of the standard ICCCM WM-to-client protocols; unfortunately many window managers ignore that protocol and just do an XKillClient when the user requests that a window go away. Other window managers - including twm - can send Delete Window messages, and pinned XView windows should work just fine. You can't expect application writers to anticipate every brain-dead window manager. If the WM doesn't supply ICCCM functionality, it's going to lose when you try to do something sophisticated. (Note that OLWM is no exception; it has a few points of noncompliance which are annoying from time to time.) -richard -- ----------- Richard A. Golding, HP Labs (internship), golding@cello.hpl.hp.com UC Santa Cruz CIS Board (grad student), golding@cis.ucsc.edu and on leave from Crucible (work) {uunet|ucscc}!cruc!golding
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (09/13/90)
> XView applications depend on the existence of an ICCCM-compliant > window manager for dismissing and quitting. ... As I read that person's complaint, it sounded like the annoyance was that the application provides no way to dismiss its own dialogs, but relies on the window manager. I can see how a person could be annoyed by this. I can also see a number of potential pitfalls to this approach. In the realms of truth and beauty, it seems that if one manipulates application controls to post the dialog one ought to be able to manipulate application controls to dismiss it. Relying on outside services seems decidedly asymmetric. I would also agree that this whole issue is fairly minor. ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE ----------------------------------------------------------------------- All relevant disclaimers apply. -----------------------------------------------------------------------
garya@garya.Solbourne.COM (Gary Aitken) (09/14/90)
> Not having pushpins means that you either let the user get annoyed > or you create an alternative mechanism for keeping dialogs up. > 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. However, the "OK" and "Apply" implementation doesn't extend to dialog boxes with more than two buttons worth a darn. Consider the basic dialog box, which has "OK" and "Cancel". Both take the dialog box down. "Apply" was added to mean "OK and don't take it down". Now consider that there are numerous situations where you have dialog boxes with more than two buttons. You need to add 2*(number of buttons-1), assuming one is a "Cancel", to get the functionality of a single pushpin. -- Gary Aitken Solbourne Computer Inc. ARPA: garya@Solbourne.COM Longmont, CO UUCP: !{boulder,sun}!stan!garya
nazgul@alphalpha.com (Kee Hinckley) (09/15/90)
In article <1990Sep13.204215.5215@Solbourne.COM> garya@garya.Solbourne.COM (Gary Aitken) writes: >> Not having pushpins means that you either let the user get annoyed >> or you create an alternative mechanism for keeping dialogs up. >> 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. >Now consider that there are numerous situations where you have dialog boxes >with more than two buttons. You need to add 2*(number of buttons-1), >assuming one is a "Cancel", to get the functionality of a single pushpin. This really has nothing to do with the previous argument - I was simply saying why my application needs to know whether I have pushpins or not. 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. Personally I think pushpins are cute, I'd prefer tearoffs for my menus though, but that's probably hard to do under X. But given the lack of a better suggestion I'd love to see pushpins added to Motif. We even considered it when we were putting together the Motif definition, but we didn't think it would go over real well. I can see it now... "Hi! We don't really want most of Open Look, but we really liked your pushpins, how about if we just take those? And if you really want us to take more, how much is that cute little magnifying glass in the Help window?" :-) -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.
marbru@auto-trol.UUCP (Martin Brunecky) (09/17/90)
In article <1990Sep14.172922.27088@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >In article <1990Sep13.204215.5215@Solbourne.COM> garya@garya.Solbourne.COM (Gary Aitken) writes: >>> Not having pushpins means that you either let the user get annoyed >>> or you create an alternative mechanism for keeping dialogs up. >>> 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. >>Now consider that there are numerous situations where you have dialog boxes >>with more than two buttons. You need to add 2*(number of buttons-1), >>assuming one is a "Cancel", to get the functionality of a single pushpin. > >This really has nothing to do with the previous argument - I was simply >saying why my application needs to know whether I have pushpins or not. > >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. Personally I think pushpins >are cute, I'd prefer tearoffs for my menus though, but that's probably hard >to do under X. But given the lack of a better suggestion I'd love to see >pushpins added to Motif. We even considered it when we were putting together >the Motif definition, but we didn't think it would go over real well. Please, excuse if I show too much of an ignorance. But I don't see what's so difficult about adding pushpins to Motif or any other widget set. I don't understand why Open Look needs a special WM protocol do do that. In fact, any Window Manager involvement (as long as popup is an override shell) is undesirable. As Paul Asente reminded me a while ago, the application can accomplish tear-off by simply changing shell's override resource to false. But there are also other means of doing it (in Motif with shared shells I am reparenting the shell's child to a new shell - works fine). So adding pushpins FROM the application is no big deal. An issue may be how the pushpin(s) should look like - ( a topmost button in a menu, a...), but I'd leave it to those guys ho spent their life writing Style Guides -). With pushpins implemented by the window manager (I disclaim any knowledge of Open Looks implementation), I see two problems: 1) The window manager must know about the (menu) shell. This means to redefine the meaning of an Override Shell, or some other type of shell KNOWN to window manager must be used. This implies a slowdown on popup activation. No big deal on DECstation with 24MB of memory, but paging a Window manager in on anything like SPARCstation with 8MB ('v seen transient shell popup take 5 sec or more) scares the hell out of me. 2) A new protocol must be added to notify the application about the fact that a menu has been "pinned down". This is not a MUST, (may be the application should wait for Unmap events), but being an application writer, I would like to know about the fact that my popup remains UP, and my XtPopdown or Unmap request has been IGNORED. So, from my limited point of view, I see PUSHPINS as something very USEFULL. However, using a Window Manager to accomplish them does NOT seem appropriate, but rather an overkill to me. Again, it sounds like making a Window Manager everything in the world (menu manager, file manager, session manager, resource manager, ... manager). Used to be ONE good rule in UNIX: one piece does one thing, and does it right. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
toml@ninja.Solbourne.COM (Tom LaStrange) (09/18/90)
|> |> Please, excuse if I show too much of an ignorance. But I don't see what's |> so difficult about adding pushpins to Motif or any other widget set. |> I don't understand why Open Look needs a special WM protocol do do that. The private OL protocol allows a client to tell the window manager what type of decoration it wants around its window. This includes a pushpin and whether or not the pin is in or out. The window manager also updates a property on the client window whenever the user changes the state of the pushpin, persumably so the client can take down the window when the user unpins it. Motif has a similar protocol that allows clients to request what type of decoration to place on its windows. Gee, here's an idea, why don't we try and agree on what this protocol should be rather than having two different ways to do the same thing? I'll come back to reality now :-) Pushpins are a very useful concept, regardless of how they're implemented or what they look like. -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
stripes@eng.umd.edu (Joshua Osborne) (09/22/90)
In article <999@richsun.cpg.trs.reuter.com>, emike@cpg.trs.reuter.com (E. Mike Durbin) writes: > The problem is that XView applications DEPEND on the window manager dismissing > popup, and even worse, killing the application. For example, Sun's Calendar > Manager will use a popup window for entering an appointment. With out OLWM, > there is NO WAY do dismiss this popup if it defaults to being push pinned in! > In X, if you zap any client window, XLIB DOES AN EXIT, killing the entire > application. It uses the ICCCM Delete. In TWM that's the "f.delete" action, a window manager that can't gennerate the delete action in most likely broken... (I use OL stuff under TWM all the time, mabie some day I'll hack TWM to understand a few of the useful or interesting OLWM things into it, but so far I have done nothing to make OL and TWM talk nicely and it works out Ok) -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Isn't that a shell script?" - D. MacKenzie "Yeah, kinda sticks out like a sore thumb in the middle of a kernel" - K. Lidl
garya@marvin.Solbourne.COM (Gary Aitken) (09/26/90)
> 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. Yep. But at the added inconvenience to the user where they now have to click on two buttons for the "normal" case (do the operation and take the box down). > But given the lack of a better suggestion I'd love to see > pushpins added to Motif. We even considered it when we were putting together > the Motif definition but we didn't think it would go over real well. > I can see it now... "Hi! We don't really want most of Open Look, but > we really liked your pushpins, how about if we just take those? And if you > really want us to take more, how much is that cute little magnifying glass in > the Help window?" So, out of curiosity, how much else suffered from NIH? OK, all you OSF spec writers, how about it? I'd sure vote for it but my vote doesn't count since I'm not a member...
garya@marvin.Solbourne.COM (Gary Aitken) (09/26/90)
> In fact, any Window Manager involvement (as long as popup is an override > shell) is undesirable. > The window manager must know about the (menu) shell. This means to > redefine the meaning of an Override Shell, or some other type of shell > KNOWN to window manager must be used. This implies a slowdown on popup > activation. Not necessarily. It depends on how the unpinned object is implemented. The unpinned object can be an override_redirect window, while the pinned object is not. I'm not saying I think this is the best implementation, but it works. Part of the problem is that you would like a pinned object to be manipulatable via the window manager (e.g. you would like to be able to move it), whereas this is not the always case for the unpinned object. For example, an unpinned popup menu has no need for move/resize via the WM, but an unpinned dialog box does have a need for this. Thus, OPENLOOK popup menus in the unpinned state are override_redirect, and the pin is owned by the client; but unpinned dialog boxes in the unpinned state are not override_redirect, and the pin is owned by the WM. If the pushpin were located anywhere but in the header it would be great to have the client own them all the time; but since the spec puts them in the header, the WM pretty much has to own them some of the time. We have menu pushpins which are, in fact, owned the whole time by the client, and it is an annoyance because it is hard to grab the border to move them with the WM; you really would like to grab them in the title area. > A new protocol must be added to notify the application about the fact > that a menu has been "pinned down". This is not a MUST, (may be the > application should wait for Unmap events), but being > an application writer, I would like to know about the fact that my > popup remains UP, and my XtPopdown or Unmap request has been IGNORED Yes and No. The protocol must be defined so the toolkit (assuming you are using one) can maintain state info, but from the application writer's point of view, this shouldn't matter. Since the application writer has no control over the pinned/unpinned state (the user controls it), the application must be written in a manner which will work whether the object is pinned or not. If the toolkit handles it properly, you never look at pushpin state.