System menu accessability and other frame parts

Windows and OS/2 allow the system menu to be reached when when a menubar
is focused. In the loop of menus, it's after the last menubar item and before
the first one. This makes it easier to reach the system menu by keyboard and
to go to the menubar. Is there interest in specifying a mechanism for this?
Something similar to the XEMBED focus handling would probably suffice.

Motif (or MWM, or CDE?) and OS/2 allow programs to place additional items
in the system menu. (Perhaps Windows does too?) On OS/2 3.0, the system menu
for any window was similar to the popup menu for an object's icon. Folders
didn't use a menubar because the few items they needed were in the system
menu. (4.0 folders have a menubar). Is there any interest in this?

MacOS (at least pre-X) doesn't have a system menu, but it has window proxy
icons and window path popup menus. Window proxy icons represent the document
being viewed and can be dragged as such; this could be used as part of an
XDS interface. Windows has this for IE, but apparently nowhere else. The
window path pop-up menu can be used in Finder to move through a folder
hierarchy. Documentation for these can be found at these sites:

Programs can almost implement this now if the window manager places the
icon window within the frame as the menu button. The ICCCM does not, afaict,
forbid mapping the icon window when the window is not Iconic. That may not
be the best way to handle it; it's just one of the options. Is there any
interest in either of these features?

I suspect it is possible to afford all of these features simultaneously,
though I'm not sure if that's desirable. Another option is to shrug off
legacy apps and maybe interopability and leave window framing (but not
management) to the programs.

Greg Merchan

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]