peter@sugar.UUCP (Peter da Silva) (06/19/88)
It should be doable. You would have to have a new menu manager and a new window an IDCMP flags "NEWMENUS". When you get a NEWMENUS message you get the address of the menu structure, like you do with gadgets. There would have to be one changed field: NextSelect would have to be a pointer to a menu. And there should be one new field: MenuID... though this could be consed up. And if you do go into the menus, add "scrolling menus": if there are more items than will fit on the screen, when the mouse gets to the bottom of the screen the items start scrolling up as you move the mouse. Then dPaint III will be able to deal with lots of fonts (:->). Also, a window flag MENUPOPUP would be nice. It would *stack* the top-level menus, and the rest of the menus would appear off to the side. It shouldn't be too hard... and it would defuse potential legal action from the fruity folks... Even better... make it a Preferences setting! -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
dpvc@ur-tut (Davide P. Cervone) (06/21/88)
In article <2148@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >It should be doable. You would have to have a new menu manager and a new window >an IDCMP flags "NEWMENUS". When you get a NEWMENUS message you get the address >of the menu structure, like you do with gadgets. There would have to be one >changed field: NextSelect would have to be a pointer to a menu. And there >should be one new field: MenuID... though this could be consed up. Good suggestions, all. One of my pet peeves right now is the way menus work. The menu code stuff is a mistake, in my opinion. I think your suggestion of returning a pointer to the item is better. Right now there are only 5 bits allocated to the subitem code. That means only 31 possible sub-items (after you subtract one for NOSUB). But I wanted to do a color-selection sub-menu! I can't do it for a 32-color screen if I only have 31 sub-items! I can use a main menu for color choice (there are six bits for the main menu item number). Anyone else want more than 31 sub-items? The NextSelect field of the MenuItem also has problems. Consider a menu with four items, ITEM1, ITEM2, ITEM3, and ITEM4. For simplicity, assume they are all CHECKIT and MENUTOGGLE items (when you select them, the checked status changes). Suppose you use the "extended menu select" option of clicking on menu items with the left button (that's what the NextSelect is all about). Do the following (all without letting go of the menu button; select using the left button): select ITEM1, then select ITEM2, then ITEM3; at this point, you decide you really liked ITEM2 the way it was before, so select it again, then select ITEM4; finally, release the right button. At this point, the NextSelect chain is from ITEM1 to ITEM2 to ITEM4. My program will NEVER KNOW that ITEM3 was selected, even though it's checkmark status will have changed! Now my menus do not acurately represent the internal status of the program (unless I check the status of EVERY toggle- menu item EVERY time I get a MENUPICK for ANY menuitem). How do the rest of you deal with this? Davide P. Cervone dpvc@tut.cc.rochester.edu dpvc@ur-tut.UUCP DPVC@UORDBV.BITNET
pds@quintus.uucp (Peter Schachte) (06/25/88)
In article <2315@antique.UUCP> vax135!cjp (Charles Poirier) writes: >In article <2467@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >>Other things that would be nice: >>-don't pop down submenus when user is just rolling down through the items > >I agree, this is annoying. How about delaying the submenu pop-down >until the mouse has been over the parent menu item for a minimum time, >like for instance, use the double-click delay time from Preferences? Unfortunately, this introduces a pause in using submenus. I think you would find this distracting, even if it only was a fraction of a second. Why not pop up submenus as soon as the mouse moves a few pixels to the right when over an item with subitems? You could also pop up the submenu when the mouse lingers on an item, if you like. Speaking of pausing over menu items, the Xerox Lisp window system has a really nice feature that I haven't seen in any of its imitators: a message window. On that system, if you hold over a menu item for more than a second or so, a message is put into this window saying briefly what would happen if you selected this menu item. This is REALLY nice: self-documenting menus! On the amiga, the help message could go into the screen's (or window's?) title bar. A bit small, but better than nothing. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
peter@sugar.UUCP (Peter da Silva) (06/25/88)
In article <138@quintus.UUCP>, pds@quintus.uucp (Peter Schachte) writes: > Why not pop up submenus as soon as the mouse moves a few pixels to the > right when over an item with subitems? You could also pop up the > submenu when the mouse lingers on an item, if you like. This is a good idea. Make it "right or left" for those people with lots of menus who put the submenus to the left when the menus get too close to the right of the screen. > On that system, if you hold over a menu item for more > than a second or so, a message is put into this window saying briefly > what would happen if you selected this menu item. This is REALLY nice: > self-documenting menus! On the amiga, the help message could go into > the screen's (or window's?) title bar. A bit small, but better than > nothing. Well, it can't be the *screen's* title bar, since the screen's title bar is hidden by the menu bar. Since the menus are playing with the screen bitmap directly anyway, how about a little window in the submenu position for that menu, but seperated from the menu box by a few pixels? -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
jimm@amiga.UUCP (Jim Mackraz) (06/27/88)
In article <138@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
)
)Speaking of pausing over menu items, the Xerox Lisp window system has a
)really nice feature that I haven't seen in any of its imitators: a
)message window. On that system, if you hold over a menu item for more
)than a second or so, a message is put into this window saying briefly
)what would happen if you selected this menu item. This is REALLY nice:
)self-documenting menus!
)-Peter Schachte
This is one of the things I like about Lotus 123. Talk about keyboard
mnemonics, by the way. And another benefit of the visicalc/lotus
UI is that it is easy to describe to someone how to select an action.
"You type /WOGY" (or whatever) as opposed to "From the Workstation menu,
select Options, select the Group option and click on "Yes" in the
confirmation dialogue box."
I mean, some people are in a hurry.
Followups to comp.sys.amiga, please.
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.mp1u+@andrew.cmu.edu (Michael Portuesi) (06/27/88)
cjp@antique.UUCP (Charles Poirier) writes: > I agree, this is annoying. How about delaying the submenu pop-down > until the mouse has been over the parent menu item for a minimum time, > like for instance, use the double-click delay time from Preferences? > Only when the mouse paused at an item, would you show the submenu. The Macintosh does exactly this with its submenus. --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "if you ain't ill it'll fix your car"