Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: OSF statements about OPEN LOOK
Message-ID: <826@auto-trol.UUCP>
Date: 17 Sep 90 15:10:13 GMT
References: <1990Sep13.204215.5215@Solbourne.COM> <1990Sep14.172922.27088@alphalpha.com>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 65

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