Conference bulova::decw_jan-89_to_nov-90

    It sounds like you may be talking about pop-up menus, which XUI does
    have.  The basic definition is that it is a menu that comes up over the
    workspace of the application, via a special mouse button (in XUI, MB2).
    Sun has been going on about this feature in Open Look like they
    invented it and nobody else has it.  I'm waiting for the Sun press
    release that mentions that they invented silicon...

    Hi,
    
    Thanks for the quick reply...
    
    What I a believe I am looking for is menus that go up from a message
    bar vs down.  For example in DECwrite you have a menu bar when you
    click on one of the menu bar categories the menu is displayed from
    there down.  Would it be possible to display from there up?  
    
    Thanks,
    
    Peter

    It seems like a possible benefit of pullup menus would be less handling of
    exposure events.  That is, with pulldown menus, you're normally
    obscuring your work area.  With pullup menus from a menu bar at
    the top of your window, you'd normally then be obscuring the window
    managers decoration and whatever is above your window.

    Make any sense?  Save under for pull down menus would accomplish
    the same thing.

Jake already said it.......

What Sun is selling is pop-ups with a separation widget.

I have a Sun here (Suntools), so I know the thickeness of
the wool Sun is pulling over the customers eyes.

Boy..Sun is doing a real number out there!

Kris..

    re .4
    
    Ok popups it is... what does that mean?  Do we do it???  I know
    we do popups but can we do them the same way ie from bottom up?
    
    Thanks,
    
    Peter

    Let's separate a few things here:
    
    The appearance of the menu itself, which is the same for a pull down
    and a pop-up.
    
    How it gets on the screen: a pull down appears because MB1 is pressed
    on a menu bar.  A pop up appears because MB2 has been pressed.
    
    Where is appears: a pull down appears underneath the menu bar.  A pop
    up appears at the current location of the pointer.
    
    How is disappears: these menus are "spring-loaded", that is to say they
    unmap when the MB1/MB2 is released.
    
    A application programmer can make a menu appear anywhere, it's just
    that the XUI suggest a style for doing so.  I'm not a XUI-developer,
    but let me offer a suggestion.  It seems "unfair" for applications to
    seize screen real estate from other applications just to put up a menu.

    If Pop up and Pull Down menus are (as only the experts know whether
    they are) easy to implement, why not provide an option in the Session
    Manager's CUSTOMIZE menu where a user can select his preference! 
    
    Talk about flexibility!  We already do color, etc.
    
    Oh well . . . {:)
    
    Regards
    
    -Piyush
    
    P.S. I still don't understand what the advantages of having one
    versus the other are!
                                                  

The advantage of having the one vs. the other is that, given good enough
marketeers, you can use them as a marketing advantage over the competition.

From what I've seen in the previous answers, I'd say your answer to the
customer should be "Yes, we have them".

	paul

    Re: .8
    
>   The advantage of having the one vs. the other is that, given good
>   enough marketeers, you can use them as a marketing advantage over the
>   competition. 
 
    How?
    
    -Piyush

Can I use this note to enter a gripe about pop-up and pull down menus
in general? if not, feel free to move it were appropriate.

My gripe is when menus popup and roll off the edge of the screen (i.e.
the top or bottom of the screen). How then do you get to the item that 
you wanted? For example, (assuming that you're reading this in a DECwindow)
move this window down until its bottom is at the bottom of the screen.
Now move the mouse down near the bottom of the screen and push/hold MB2.
Now try to get to the "Close Conference" item. 

Shouldn't it be that menus not fall off the screen?

Sm

>>My gripe is when menus popup and roll off the edge of the screen (i.e.
>>the top or bottom of the screen). How then do you get to the item that 
>>you wanted?

FileView's popup and pulldown menus will not fall off the screen in V2..

-steve-

RE: .12

Is this because they fixed the toolkit, or does it only apply to the widgets
that FileView rolled on its own?

--PSW

Just "fixed" in FileView, I'm afraid.

-steve-

    Re: -1

    Steve, how about telling us what you did? 

    Denis.

    Yes, please!

Well, my solution was to use the "VMenu" widget.  (Couldn't you guess?)
This widget checks the screen width and height, and forces its popup
position to ensure full visibility of the window.

I haven't thought of a way to "fake" the Dwt menu widget into it.  Sorry.

-steve-

You could also examine the UWM source code.  It is carefull to keep its
menus onscreen.

Re no universal buy-in... does that mean that some people consider it a 
feature to have text appear where you can't see it?   :-(

	paul

    RE .19 - I'd also be interested in hearing just what not not
    "universally" bought into. The current behavior is clearly and
    indisputably a bug. Is there a question of whether fixing it is high
    enough on the priority list, or are there actually some people who do
    not view it as a bug (and what are they smoking)?

I haven't been trampled in the halls of ZKO2-3 by hordes of toolkit people
tripping over each other in their eagerness to fix this problem.  The most I've
heard from the developers so far is a non-committal "(mumble) yeah, it does
do that doesn't it?"

Has anybody actually QARed the problem?

--PSW

    Actually, the toolkit people have been waiting for the Style Guide
    people to tell them how they want it to act:
    
     o is the menu moved to the edge of the screen, or is it important
       not to obscure some information (like the pull-right that gave
       rise to it)?
    
     o is the pointer warped?  Is so, what does this mean for a tablet
       user?  If not, how does this affect "muscle-memory" (i.e. the fact
       that the default choice will be different for a pop-up menu)?
    
    No answer yet, and it's past V2 code freeze for field test...
    
    Leo
       

    What's wrong with following Grace Hopper's advice? Just do it, and let
    the Style Guide bureaucrats complain if they don't like the results.

Nothing wrong with it, but it's not like the toolkit group has been
"tripping over" each other looking for things to do...

Personally, my priorities are performance and influencing the "standards"
arena.  MS-Windows still has this "bug" and they have survived...

Leo

>> MS-Windows still has this "bug" and they have survived...

    It's somewhat worrisome that you put quotations around the word "bug" -
    does this mean you question its status as a bug? A "feature" which
    prevents me from reliably using MB2 popup windows certainly seems like
    a bug to me.

    And I certainly wouldn't suggest using MS-Windows as the touchstone for
    quality for DECwindows! I assume you were joking. 

No I wasn't joking.  Engineering is a constant process of identifying
priorities and making tradeoffs.  This problem is not high on my priority
list.  And since neither the SUE group nor the DECwindows programs nor
customers (that I know of) are making a lot of "noise" about this, it's
not going any higher...

And, since it's past V2 field test code freeze, anyone who thinks this is
important better get a lot of people in the right places excited about
it or it won't happen until V3.

Leo

Popups are  one thing, but this bug can cause real problems.  I'll give you
one example.  I have a DECwrite document that has a rather large number of
paragraph styles in it.  Some of these I want to get rid of (or, in some
cases, subject to a "delete" operation to "uncover" the definition from
the style file).  But...  the pulldown off the "delete a style" menu is
sufficiently far down the screen that the bottom falls off the bottom of the
screen.  Since the menu bar is already as high as it can go, it is absolutely
impossible to use this function -- some of the selections are inaccessible
and there is NO workaround.

	paul

I would like to make it clear that the SUE (Software Usability Engineering)
group does consider this a serious, high priority problem that should be fixed
AS SOON AS POSSIBLE.

We have brought this problem up repeatedly...during the development of
DECwindows V1, during the post-V1 requirements gathering process (to quote
from our requirements input, "the Style Guide should specify that menus...should
not go off-screen, along with a toolkit mechanism that lets this work for both 
mice and tablets."), and as recently as last week.

No, we do not have a ready-made solution to this problem sitting on the shelf.
But...like Leo said about the toolkit group in .24, the SUE group isn't 
exactly twiddling thumbs while waiting for work to arrive.  When we get the
nod that the toolkit group is ready (or, will soon be ready) to change the 
toolkit, we will make the resources available to work with the toolkit folks
to define a solution.

By the way, anyone out there who thinks "what the heck?  the solution should
be easy!" is more than welcome to suggest solutions.  Just remember that the
solution must work for both mice and tablets...and mice are relative-positioning
devices while tablets are absolute-positioning devices.  I beleive (recall)
that this was the heart of the matter which prevented a solution during the
development of V1...one of those cases where there's dozens and dozens of 
things to solve, and the extremely difficult problems tend to get attended to
last...

tms

The Macintosh expects that menus can be longer than the available screen.  If 
this turns out to be the case (real-time determination to allow for moved
windows) then the bottommost printable entry is replaced by a special down-pointing
arrow.  If the user drags onto or below this arrow, the menu contents scroll up
(at a speed relative to the distance from the arrow.)

Once items scroll off the top of the menu, a similar up-pointing arrow appears
on the top, and the user is in complete control of what section of the menu
items are displayed.

As is often the case with things like this, it explains poorly compared to
trying it; so I invite all you developers to give it a shot (er 'drag').  
I'll gladly provide Mac-time.

By the way, the same applies where sub-menus touch the screen boundry:  Currently
in DW they just display the part they can, often leading to unreadable items
and complete inaccessibility of the sub-menus.  Instead, if any part of a
sub-menu were to touch the screen boundry, how about simply displaying it on 
the other side of the main menu?

Jeff

I believe the answers can be simple.  The questions are the right ones.
Here are my answers:

>>     o is the menu moved to the edge of the screen, or is it important
>>       not to obscure some information (like the pull-right that gave
>>       rise to it)?

	Menus should always be moved so that they are completely visible.  This
	applies to all menus, including pullrights.
    
>>     o is the pointer warped?  Is so, what does this mean for a tablet
>>       user?  If not, how does this affect "muscle-memory" (i.e. the fact
>>       that the default choice will be different for a pop-up menu)?

	The pointer should never be warped.  "Muscle memory" is no subsitute
	for "look before you click".  Warping the mouse is a big-time no-no.
	(Tablet users cannot abide by a mouse warp.)

	In the (obscure) case where the mouse is close to the right edge
	of the screen and the menu pops up such that the mouse is exactly
	over a pullright activator, then the pullright should be activated
	immediately, immediately obscuring the primary menu.  Deeper pullrights
	should be activated as needed, but the process will eventually
	end.  (This may obscure the underlying menu.  I have a slightly
	more complicated suggestion for popping down pullrights when
	the mouse moves to the left of the pullright, thus giving the
	user a way to popdown a pullright without explicitly entering
	the primary menu.)

	At any rate, this would be an improvement over today's behavior.
	This is the way that FileView V2 will work.  In all fairness,
	FileView does not use pullrights, so that part of the problem
	was a non-problem for us.  But I don't think that it should be that
	hard to settle on the solution.

-steve-

Considering the comment elsewhere that X doesn't really support the tablet
(except as a funny mouse -- which matches what I observed) I don't understand
the claim that the existence of tablets makes the problem harder.

	paul