adatta@odin.wright.edu (Amitava Datta) (09/15/89)
If you are building an X client and don't quite like the Xt support
for creating popup menus you may want to consider the following:
Why not have the X window manager display and manage menus for clients?
(Of course, the window manager would need to inform the X client when
a menu item gets selected)
First, why would anybody want to do this?
------------------------------------------
1. One of the reasons (most probably) why we choose a particular window
manager is because we like the way it manages its menus.
2. Popup menus using Xt widgets (if you can get them to work
correctly) don't look (or feel) as good as the menus used by the
window manager.
3. A lot of code is duplicated in all X clients to handle menus. I
have seen enough questions being asked in this news group about how to
get pop up menus to work to safely assume that it does take some time
to understand the Xt popup support. We could save a lot of time in
bringing up a client.
4. The user interface is not as uniform as we would like them to be
since every X client is probably going to come up with its own
way of dealing with its menus. If window placement, decoration and
basic window manipulation (moving, resizing, iconifying, etc.) are
to be handled by the window manager to provide a ``uniform''
interface so should the management of menus since it is such a
basic operation in a windowing environment.
5. No X client will be tied down to one way of displaying and managing
menus. Assuming that all window managers provide this facility,
X client menus will look and feel different when using different
window managers.
One such implementation:
------------------------
We (Shane Dawalt and I) have modified TWM to provide this facility
(and call it TWM+). The following is a brief description of how it
works.
1. Client menus and mouse button bindings are specified in a separate
file. Menus are defined the way they are in the .twmrc file
(so that we could use the same parser).
2. The client hangs a CLIENT_MENU property on its toplevel window
specifying the filename from where the client's menus can be read
in by TWM+.
3. TWM+ grabs buttons in client's toplevel window which binds to client
menus just the way it used to when handling button binds with the window
context.
4. Client menus are displayed when the proper button event is received
by TWM+. If an item is selected TWM+ performs the corresponding
action. A new TWM+ builtin function `f.clientsend' was added which
can be used to send a ClientMessage event to the client with the
data field containing a string which can be used (in the client) to
determine which item was selected. An sample client menu defn. in
TWM+ is shown below.
menu "menu2"
{
"Menu 2" f.title
"Selection 1" f.clientsend "menu2:1"
"Selection 2" f.clientsend "menu2:2"
"Selection 3" f.clientsend "menu2:3"
"Pull-right" f.menu "menu1"
"Move" f.move
}
The whole interaction with X client and the WM seems to work quite
well. We did not notice any delay in getting an X client to respond to
menu selections.
There are currently some limitations, e.g. since only toplevel windows
are seen by the WM, client menus can only work when defined for such
toplevel windows. For a number of implementations I have found that
this is not too much of a limitation.
I would like to know what the WM designers (or anybody else) think
about this idea. Can such a facility be made a standard for all X WMs?
Of course, we would have to come up with a standard way of defining menus.
This should not be too much of a problem.
If you need diffs for TWM+, I would be happy to provide them.
++adatta
email: adatta@cs.wright.edu
==================================
Amitava Datta
Email: adatta@cs.wright.edu
Phone: (513)-259-1391 (Office)mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (09/17/89)
> If you are building an X client and don't quite like the Xt support > for creating popup menus you may want to consider the following: > Why not have the X window manager display and manage menus for > clients? (Of course, the window manager would need to inform the X > client when a menu item gets selected) This is a reasonable idea. But I have a few nits to pick with your implementation (surprise surprise :-). > 1. Client menus and mouse button bindings are specified in a separate > file. Menus are defined the way they are in the .twmrc file (so > that we could use the same parser). > 2. The client hangs a CLIENT_MENU property on its toplevel window > specifying the filename from where the client's menus can be read > in by TWM+. You're requiring that a file exist on the WM's machine's filesystem in order to make the client's menus work? This seems ugly. If I, here at McGill, want to try out a program cooked up by someone at UdeM, I shouldn't have to copy a file from there to here just to get its menus working. One of X's really neat features is its network transparency; let's not lose that just yet. > 3. TWM+ grabs buttons in client's toplevel window which binds to > client menus just the way it used to when handling button binds > with the window context. You're assuming all menus pop up in direct and uniform response to mouse clicks. This seems unnecessarily restricting. Example: a menu which is invoked by a keystroke. Example: a menu invoked by clicking on something on the screen. Example: a mouse click which sometimes pops up a menu and sometimes does something else. I don't know whether twm already does this, but I would also want the potential for menu items that do different things depending on how they're selected (left, right, control-left, shift-middle, etc). > I would like to know what the WM designers (or anybody else) think > about this idea. I like the idea but I think it needs more hashing-out. Perhaps a separate menu-manager client, with a defined C interface (which is actually a set of wrappers around ClientMessage sends and receives)? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
adatta@maize.wright.edu (Amitava Datta) (09/17/89)
This is in reply to <mouse@larry.mcrcim.mcgill.edu> > You're requiring that a file exist on the WM's machine's filesystem in > order to make the client's menus work? This seems ugly. If I, here at > McGill, want to try out a program cooked up by someone at UdeM, I > shouldn't have to copy a file from there to here just to get its menus > working. > One of X's really neat features is its network transparency; let's not > lose that just yet. Loading menus from files was just a quick way to get twm+ up and running with the client menus support. How about if we load the menu defns. and bindings as the data of CLIENT_MENU property instead of the filename? No files need be involved here. > You're assuming all menus pop up in direct and uniform response to > mouse clicks. This seems unnecessarily restricting. Example: a menu > which is invoked by a keystroke. Yes, keys can be bound to TWM built-in functions - popingup a client menu in this case. TWM already supports that. (I have never seen any application poping up a menu on a key press. But I agree. We must not restrict people from doing that - we aren't). > Example: a menu invoked by clicking > on something on the screen. That ``something on the screen'' has to be some window. CLIENT_MENU can be defined for that window to popup a menu on the specific mouse click or key. Right now we don't have an easy way of supporting client menus on windows which are not ``top-level''. X WMs don't manage sub windows. A kludged up version exists. Should be able to find a cleaner solution for that. > Example: a mouse click which sometimes > pops up a menu and sometimes does something else. Menu bindings can be changed dynamically by changing CLIENT_MENU property. Same applies to having different menus loaded at different times. All WMs get notified (by the X server) whenever there is a change of property. At this point TWM+ reloads client menus from the property data preserving old defns. but redefines any menus with the same name. New bindings replace old ones. The clients that we have load all of the possible menus that they would ever want during startup and keep changing mouse bindings dynamically. > I don't know whether twm already does this, but I would also want the > potential for menu items that do different things depending on how > they're selected (left, right, control-left, shift-middle, etc). Yes, twm will let you have any combination to bind to a twm function. Poping up a menu (in this case for the client) is just another builtin function. > ....separate menu-manager client Anything that can be done from another menu manager client can be done by the window manager client. Why add another process? Thank you for your comments. Amitava Datta (adatta@cs.wright.edu)
toml@Solbourne.COM (Tom LaStrange) (09/18/89)
>> You're assuming all menus pop up in direct and uniform response to >> mouse clicks. This seems unnecessarily restricting. Example: a menu >> which is invoked by a keystroke. > >Yes, keys can be bound to TWM built-in functions - popingup a client >menu in this case. TWM already supports that. (I have never seen any >application poping up a menu on a key press. But I agree. We must not >restrict people from doing that - we aren't). Have you tried this? I don't think you can pop up a menu from the keyboard. >> Example: a menu invoked by clicking >> on something on the screen. > >That ``something on the screen'' has to be some window. CLIENT_MENU >can be defined for that window to popup a menu on the specific mouse >click or key. Right now we don't have an easy way of supporting client >menus on windows which are not ``top-level''. X WMs don't manage sub >windows. A kludged up version exists. Should be able to find a cleaner >solution for that. Window managers will look at inner windows in R4 if told to do so. I'm referring to the WM_COLORMAP_WINDOWS property which lists child windows that have their own colormaps. Something similar could be done with a WM_CLIENT_MENU_WINDOWS property. I like the idea. -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,nbires,sun}!stan!toml Longmont, CO 80501
MAP@LCS.MIT.EDU (Michael A. Patton) (09/19/89)
Date: 17 Sep 89 07:20:49 GMT From: ncrlnk!wright!maize!adatta@uunet.uu.net (Amitava Datta) > Example: a menu invoked by clicking > on something on the screen. That ``something on the screen'' has to be some window. WRONG! In the application I have, the right mouse button gets a menu, which menu it gets depends where in the master window you are, but this is NOT done with sub-windows (for various reasons that don't matter here). This means that your scheme is inadequate for my application to use. I would really like to have some commonality in menu operation (My application supports the type of menu *I* like, but others want something else :-). Unfortunately your suggestion so far is not general enough for me to use. The program maintains a window with a bunch of stuff drawn on it. Some of this stuff is dynamic, it comes and goes or changes size and/or position depending on all sorts of mouse input and typed commands, eventually some of these changes will even be based on non-X initiated activities. Some of these things may be quite small and I don't want to require the user to get an exact hit. When the user clicks the mouse, the application looks over what's displayed now to "guess" what the user was pointing at and responds. In the case of the right mouse button (by default), this response generates a menu which depends on what "kind" of thing the user had selected. There is no practical way to even maintain a list of areas where different menus might come up, it really has to be figured out on a per-menu basis. What I would want is some way to register the various menus with the WM (or MM) and then have my application trigger them on whatever IT decides is the right criteria. This could be a Client message to my top-level window (which the WM is watching for because of the property), or something else. In fact a Client message to initiate the menu and another (logically from the WM to the App) to describe what was selected seems like the most general solution to this. -Mike Patton P.S. As a separate point, I like the idea of distinct Window Manager and Menu Manager. There is presently no window manager I have tried for which I really like both the way it handles windows and the way it does its menus. If I could mix and match, this would give me a much wider range of options. As it is I compromise I one where neither is done in a way I HATE.
don@BRILLIG.UMD.EDU (Don Hopkins) (09/19/89)
I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process. I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching. Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-) c(-; Once were done forging the menu manager standard, how about we do text editors, huh?) -Don Date: Mon, 23 Feb 87 18:31:00 EST From: Don Hopkins <brillig.umd.edu!don@harvard> Message-Id: <8702232331.AA08434@brillig.umd.edu> To: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu Cc: xpert@athena.mit.edu In-Reply-To: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu's message of 23 Feb 87 19:44:43 GMT Subject: Uwm extensions, perhaps? Date: 23 Feb 87 19:44:43 GMT From: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu (Rusty Wright) In article <8702211303.AA01735@gjetost.wisc.edu> solomon@GJETOST.WISC.EDU (Marvin Solomon) writes: >... > >What's the solution? I think it is to get rid of the idea of window >manager as a separate process, and build "window-manager" functions >into all windows. That scares me. Wouldn't we then have the problem that suntools has where the suntool binaries are huge? On my sun 3/50 the suntools program itself is 728 blocks and the various other tools that run under suntools are 952 blocks. Yuck. How about setting up some sort of standard? For example, all window managers must use control+shift when the mouse is in a window or an icon, and when it's in the background the control+shift is optional. -------------------------------------- rusty c. wright rusty@weyl.berkeley.edu ucbvax!weyl!rusty I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to configure. The big question is how do your clients communicate with it? Are the facilities in X11 sufficient? Or would it be a good idea to adopt some other standard for communication between clients? At the X conference, it was said that the X11 server should be used by clients to rendezvous with each other, but not as a primary means of communication. Why is that? Setting a standard on any kind of key or mouse bindings would be evil. The window manager should be as transparent as possible. It solves lots of problems for it to be able to send any event to the clients. For example, how about function to quote an event that the window manager would normally intercept, and send it on? Perhaps the window manager is the place to put the ToolKit? -Don
adatta@odin.wright.edu (Amitava Datta) (09/20/89)
Reply to map@lcs.mit.edu: > In the application I have, the right mouse button gets a menu, > which menu it gets depends where in the master window you are Yes. I can see where our scheme can run into problems. The condition that invokes a menu need not just be X events. Going by your suggestion, let me revise our scheme: 1. X client posts all the menu defns. via WM_CLIENT_MENUS. No bindings needs to be specified. 2. Client decides *when* to popup *which* menu. This is done by setting WM_CLIENT_MENU_POP to have the name of the menu to popup on the top level window. 3. On a property change of WM_CLIENT_MENU_POP on a client window, the WM pops up the specified menu at the current pointer location. When a selection is done the WM executes the WM builtin function -- which can be "f.clientsend <item-id>" to send an X Client Message to the client giving it the item-id that was selected. It then unmaps the Menu. 4. The client can wait for the Client Message to determine which item was selected and whatever it wants to do. Using this scheme we don't need to have window managers look at client sub windows. I have not implemented the above yet but I don't see any problems in the implementation. Is this general enough now? Amitava Datta (adatta@cs.wright.edu)
klee@gilroy.pa.dec.com (Ken Lee) (09/20/89)
In article <663@thor.wright.EDU>, adatta@odin.wright.edu (Amitava Datta) writes: > Going by your suggestion, let me revise our scheme: > > 1. X client posts all the menu defns. via WM_CLIENT_MENUS. No bindings > needs to be specified. > > 2. Client decides *when* to popup *which* menu. This is done by > setting WM_CLIENT_MENU_POP to have the name of the menu to popup on > the top level window. I think this kind of generality removes the last advantage of a "menu manager" client. Potential advantages I see are: 1. Centralized code makes clients smaller and improves performance. But, many systems now have shared libraries which do the same thing more gracefully. Shared libraries should be available on most or all workstations within the next year or two. 2. Menus are difficult to write. Yes, but the big widget sets (DECwindows, Motif, HP, OpenLook) all have menu widgets that make menu handling easy. 3. User interface consistancy. A common widget set or style guide is probably a better place for this. Besides, you want the whole user interface to be consistent, not just the menus. 4. Response time. A client involved in a detailed calculation may not get back to event polling for awhile. A separate menu management client and your operating system's scheduler allow the to popup anyway. The client won't be able to act on the menu selection immediately, but the user gets better feedback. Unfortunately, the scheme outlined above requires client intervention before the menu can be displayed, removing this advantage. Your scheme also adds a number of disadvantages, such as complexity, lots more round trips to the X server, greater operating system context switching, and requiring a particular window manager look & feel. Plus, the client is dead in the water if the window manager dies. A particular client, or group of clients, may want to use a menu manager to work around particular problems (I have done this with some success), but I think that a general solution at this level has too many of it's own problems. (If you want to talk about a general user interface server, rather than just a menu server, however, I might be interested.) By the way, the Motif window manager has minimal support for client defined menus. This is about as far as I'd want to go for menu management. These menus are integrated with the window manager look & feel, but the client should be able to operate without them. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
janssen@holmes (Bill Janssen) (09/21/89)
I'm not sure I understand the usefulness of putting the menus in the window manager (aside from being able to switch entire toolkit styles by switching window managers, which might be thought of as an advantage). The client program would presumably link against some menu library, which would handle defining the window properties with the menu definitions in them (or a filename, but the menu defs right in the properties was a better idea). What is the difference to the client or the developer whether the library communicates with some menu manager to have the menus presented, or does it directly? Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
marbru@auto-trol.UUCP (Martin Brunecky) (09/22/89)
In article <653@thor.wright.EDU> adatta@odin.wright.edu (Amitava Datta) writes: >If you are building an X client and don't quite like the Xt support >for creating popup menus you may want to consider the following: > > Why not have the X window manager display and manage menus for clients? > (Of course, the window manager would need to inform the X client when > a menu item gets selected) I vote NO ! Pretty soon, somebody else would like the Window Manager to do this, taht and even more. After a little while we'll have Window Managers that do everything in the world, but nothing RIGHT. Let the Window Manager do it's job, and don't try it to do more than that. And if you are having problems with creating cascaded menus of your own, just wait till the toolkits mature to make it easy. For example, DECwindows approach is not quite clear nor easy. In our widget set, we have come up with a PopupButton(s) that implement about 8 different cascade styles, and do everything.... Wasn't easy, but also not that difficult. So I expect other toolkits to get to the same "ease of use" sooner or later. -- ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru
don@BRILLIG.UMD.EDU (Don Hopkins) (09/23/89)
Date: 21 Sep 89 22:30:38 GMT From: usc!cs.utexas.edu!ico!auto-trol!marbru@bloom-beacon.mit.edu (Martin Brunecky) In article <653@thor.wright.EDU> adatta@odin.wright.edu (Amitava Datta) writes: >If you are building an X client and don't quite like the Xt support >for creating popup menus you may want to consider the following: > > Why not have the X window manager display and manage menus for clients? > (Of course, the window manager would need to inform the X client when > a menu item gets selected) I vote NO ! Pretty soon, somebody else would like the Window Manager to do this, taht and even more. After a little while we'll have Window Managers that do everything in the world, but nothing RIGHT. Oh, come on, that's what extension languages are for! Emacs does everything in the world, but there sure are a lot of people who would flame you to a cinder if you said "Emacs does nothing right!" (But let's not go into that subject on /this/ news group.) Anyway, there's no reason the window manager and the menu/toolkit manager have to be the same program. There's also no reason they couldn't all run in the address space of the window server (i.e. X11/NeWS). A good solution should support both possibilities. -Don
adatta@odin.wright.edu (Amitava Datta) (09/25/89)
klee@gilroy.pa.dec.com (Ken Lee) writes .... > ..... Potential advantages [to WMs handling client menus] I see are: > 1. Centralized code makes clients smaller and improves performance. > But, many systems now have shared libraries which do the same thing > more gracefully. Shared libraries should be available on most or all > workstations within the next year or two. But how will you get all clients to have the same kind of menus to pop up regardless of which WM is being used? This is the primary goal. > 2. Menus are difficult to write. Yes, but the big widget sets > (DECwindows, Motif, HP, OpenLook) all have menu widgets that make menu > handling easy. Again, different clients will still use different kinds of menus making the user interface non-uniform. > 3. User interface consistancy. A common widget set or style guide is > probably a better place for this. Besides, you want the whole user > interface to be consistent, not just the menus. You can never force one ``common widget set'' on all clients and WMs. > 4. Response time. A client involved in a detailed calculation may not > get back to event polling for awhile. A separate menu management > client and your operating system's scheduler allow the to popup > anyway. The client won't be able to act on the menu selection > immediately, but the user gets better feedback. Unfortunately, the > scheme outlined above requires client intervention before the menu can > be displayed, removing this advantage. The way I have it implemented now, client menus can be invoked even without client intervention. Just specify the key or mouse button binding that the client wishes to bind to a menu popup just as you would using the WM's startup file for the WM menus. The scheme to have the user specify the popup will be an addition and can be used when the client wants to popup menus based on non-X "events". > Your scheme also adds a number of disadvantages, such as complexity, If you don't find setting size hints and having the WM respond to those requests complex, I don't see how you find my scheme of poping up a window via hints more complex . It uses the same mechanisms in X. Believe me, it is not even close to being complex. > lots more round trips to the X server, greater operating system context > switching, There's enough of that going on in an X environment. That's not my doing. I am trying to add a missing functionality using whatever's available in X. I have implemented this (not the revised scheme) and I don't see any increase in response time. > and requiring a particular window manager look & feel. If you mean one that supports Client Menus, yes. But if people feel this is an essential feature to have then this could be made a standard. I know a few who would like it as a ICCCM standard. > Plus, the client is dead in the water if the window manager dies. Why should it be "deep in the water"? The user would do just what we do today -- go to a shell and run the window manager again and send a bug report to the window manager writers. When the WM comes up it can read in all menu defs from the WM_CLIENT_MENUS property. All WMs do that to read in current geometry related and name hints associated to each window. > A particular client, or group of clients, may want to use a menu manager > to work around particular problems (I have done this with some > success), but I think that a general solution at this level has too > many of it's own problems. (If you want to talk about a general user > interface server, rather than just a menu server, however, I might be > interested.) Instead of having a home grown solution known only to a few clients what I am suggesting is more general and can be made a standard without having the WM writers too much of a hassle to implement. I have just done this with TWM and find that it is really a very simple extension. > By the way, the Motif window manager has minimal support for client > defined menus. This is about as far as I'd want to go for menu > management. These menus are integrated with the window manager look & > feel, but the client should be able to operate without them. I have not used MWM. If this WM has anything special that other WMs do not provide then you will have clients tied down to MWM. This shouldn't happen and if MWM provides a better (or simpler) scheme to handle client menus then we should try and make THAT a standard. The way I see it, there should be some mechanism in the X environment by which the user can be provided with a way to get the same kind of menus when one is requested regardless of which client the user is interacting with. Currently there isn't a way to do that in X. Once we have them we should discourage clients to pop up their "own" menus and have them use the WMs menus since, most likely, the user likes the way those menus look and feel. At least we will have a uniform interface to all menu. Amitava Datta (adatta@cs.wright.edu)
adatta@odin.wright.edu (Amitava Datta) (09/25/89)
marbru@auto-trol.UUCP (Martin Brunecky) writes... >>If you are building an X client and don't quite like the Xt support >>for creating popup menus you may want to consider the following: >> >> Why not have the X window manager display and manage menus for clients? >> (Of course, the window manager would need to inform the X client when >> a menu item gets selected) > I vote NO ! > Pretty soon, somebody else would like the Window Manager to do this, > taht and even more. Seriously, I don't think that's a reasonable arguement against any extension to software in general. If there are deficiencies in a system we must always be ready to extend the functionality by some means. I have suggested one way of making all menus look and feel the same regardless of which WM and client you are using using mechanisms available in X. If anybody comes up with a better solution to this problem we should go for that. (Please don't ask everybody to use the same toolkit since that most likely will not be accepted). > After a little while we'll have Window Managers > that do everything in the world, but nothing RIGHT. In such user interface issues what is RIGHT for you may be DEAD WRONG for another user. That is precisely the reason why you can choose from a wide variety of X WMs. And of course if you don't like any of them you can write one on your own (or get GWM and program it in lisp). What I have suggested is a "mechanism" not a "policy". > Let the Window Manager do it's job, and don't try it to do more than > that. And if you are having problems with creating cascaded menus > of your own, just wait till the toolkits mature to make it easy. You missed the point completely. I don't have any problems in creating menus. Amitava Datta (adatta@cs.wright.edu)
adatta@odin.wright.edu (Amitava Datta) (09/25/89)
janssen@holmes (Bill Janssen) writes > I'm not sure I understand the usefulness of putting the menus in the > window manager (aside from being able to switch entire toolkit styles > by switching window managers, which might be thought of as an advantage). Correct. You can have a more uniform user interface this way. > The client program would presumably link against some menu library, which > would handle defining the window properties with the menu definitions > in them (or a filename, but the menu defs right in the properties was > a better idea). What is the difference to the client or the developer > whether the library communicates with some menu manager to have the > menus presented, or does it directly? No difference at all. Right now we don't have such a facility in X. It is not a standard yet among WMs. Amitava Datta (adatta@cs.wright.edu)
janssen@holmes (Bill Janssen) (09/26/89)
In article <671@thor.wright.EDU>, adatta@odin (Amitava Datta) writes: >... At least we will have a uniform interface to all menu. Well, not really. Only to those clients that use *your* menu package, which is built into a window manager. Clients that use the Motif or Open Look packages will present their menus themselves, and will look different from your menus. You really can't win. Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
marbru@auto-trol.UUCP (Martin Brunecky) (09/26/89)
In article <671@thor.wright.EDU> adatta@odin.wright.edu (Amitava Datta) writes: >klee@gilroy.pa.dec.com (Ken Lee) writes .... > >But how will you get all clients to have the same kind of menus to pop >up regardless of which WM is being used? This is the primary goal. >Again, different clients will still use different kinds of menus >making the user interface non-uniform. > 1. To me, menus are just one, small part of the user interface. Though, even when you make this part 1000% uniform and "standard", the main goal - user interface consistency - is still miles away. >You can never force one ``common widget set'' on all clients and WMs. > 2. Yes. That would be stupid, and would kill any inovation and creativity. But we are at the beginning of the user interface evolution, which, in my opinion, will result in commonly accepted "feel" - such as a standard typewriter keyboard. The "look" does NOT matter that much to me... And what ever that "feel" is, it will be adopted by any toolkit that wants to survive. And I, as a user-interface programmer, will have the option to pick the toolkit which suits to my needs (such as ease of use, my favorite "look", performance, portability...) without having to worry about the "feel". > >The way I have it implemented now, client menus can be invoked even >without client intervention. Just specify the key or mouse button >binding that the client wishes to bind to a menu popup just as you > .......in short menus in WM are simple .... 3. Yeeeeh. As long as we talk few simplistic applications, everything is simple. When you go into applications with HUNDREDS of menu options (I happen to work on such), simlicity suddenly turns into a nightmare. You can not define everything statically. You must add dynamicsi - such as deffered sub-tree definitions. So while initially there was a limited overhead of setting up WM properties and addtional "menu selection" events going from WM to SERVER and then to the APPLICATION, in a real world we may end up with even unaccptable performnce degradation. > -- ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru
adatta@odin.wright.edu (Amitava Datta) (09/27/89)
In article <3198@arisia.Xerox.COM>, janssen@holmes (Bill Janssen) writes: > In article <671@thor.wright.EDU>, adatta@odin (Amitava Datta) writes: > >... At least we will have a uniform interface to all menu. > > Well, not really. Only to those clients that use *your* menu package, > which is built into a window manager. Clients that use the Motif or > Open Look packages will present their menus themselves, and will > look different from your menus. You really can't win. > X WMs try to stick to the ICCCM specification. What I am hoping to get out of this discussion in comp.windows.x is a good reason why the Client Menu Handling shouldn't be part of the ICCCM spec. for X WMs. If it is made part of the standard interface then all clients can be "encouraged" to use this so that the user (the guys that we write programs for) will enjoy the "uniform interface to all menus"; just the way we encourage clients not to use the `override_redirect' attribute. Amitava Datta (adatta@cs.wright.edu)
adatta@maize.wright.edu (Amitava Datta) (09/27/89)
In article <296@auto-trol.UUCP>, marbru@auto-trol.UUCP (Martin Brunecky) writes: > ............. And I, as a user-interface programmer, > will have the option to pick the toolkit which suits to my needs > (such as ease of use, my favorite "look", performance, portability...) > without having to worry about the "feel". > The user interface SHOULD NOT be designed to suit the needs of the "user-interface programmer" but that of the USER. Your "favorite look" and "ease of use" is really of no concern to the user of your program. That's the reason why we leave things like window decoration to the WM and let the user choose which decoration to have on the windows (by selecting one of the many WMs) instead of providing a window decoration in the client program that we (as programmers) like around our windows. > > 3. Yeeeeh. As long as we talk few simplistic applications, everything > is simple. When you go into applications with HUNDREDS of menu > options (I happen to work on such), simlicity suddenly turns into > a nightmare. You can not define everything statically. You must > add dynamicsi - such as deffered sub-tree definitions. Our scheme allows dynamic menu definitions. If you have a particular way of handling menus that our scheme does not support please email me the details. We'll look into it. Amitava Datta (adatta@cs.wright.edu)
pop@linus.UUCP (Paul Perry) (09/28/89)
To: ncrlnk!wright!odin!adatta@uunet.uu.net (Amitava Datta) In-reply-to: ncrlnk!wright!odin!adatta@uunet.uu.net's message of 26 Sep 89 21:36:18 GMT On the topic of client menus, having written an application that supports multiple users, I would like to support the user interface portion AT the server so that the user gets better response and the application client isn't bogged down 'timesharing' for users. The way I do it now is to have a separate client that just handles certain menus. So I think the important point for me is not menus that conform to a window manager's look and feel but the ability to distribute the 'input' user interface portion of the client. When OSF was making a decision on their user interface RFT, it was clear that NeWS did have some nice things that X did not support. Among them, the fact that the NeWS server is a programmable server, in that, as I am told, an application can download code to the server. Could someone shed some light if X could or is not intended to incorporate such a mechanism ? If it can, then I would prefer this mechanism because it can do more that just menus (rubber-banding being a common reference). Otherwise, I would be interested in knowing why the X designers chose not to incorporate such a mechanism. (Or maybe I am just misinformed about the NeWS capabilities) Paul O. Perry Phone: (617) 271-5641 MITRE Corporation ARPA: pop@mbunix.mitre.org -- Paul O. Perry Phone: (617) 271-5641 MITRE Corporation ARPA: pop@mbunix.mitre.org Burlington Road Bedford, MA 01730
yost@esquire.UUCP (David A. Yost) (09/28/89)
In article <296@auto-trol.UUCP> ncar!ico!auto-trol!marbru (Martin Brunecky) writes: > But we are at the beginning of the user interface > evolution, which, in my opinion, will result in commonly > accepted "feel" - such as a standard typewriter keyboard. The bitmap screen/mouse "user interface evolution" has been going on for many years before X. X, by providing tools for implementing user interfaces, while refraining from imposing any specific user interface policy, has brought user interface tinkering to the masses, as well as to a new group of competing large forces (OFS, AT&T-Sun, DEC, HP, ...) This will lead to a commonly accepted "feel"? Is there a commonly accepted "feel" in the giant, anarchic, PC market? (What a great straight line for jokes!) The standard typewriter keyboard is an interesting example. The standard was set by the first vendor. It remained for a mob of computer terminal manufacturers to experiment endlessly with the position of return, backspace, caps lock, control, ESC, and other keys, much to the delight of fascinated computer users. A standard is generally set by a single well-promoted initial offering in a new area. Standard, not in the sense of a well-defined specification, but in the sense of de facto standard, the dominant way of doing things. Think of all the standards have been imprinted by an initial offering: CP/M on most 8080s, DOS (originally named the Q and D Operating System before Microsoft bought it) on most 8086s, C on all UNIXes, TCP/IP, NFS, etc. I think the lesson is that the ideal kind of standardization results from a well-promoted initial offering which is also well-thought-out and complete enough that workarounds for errors and omissions are not rampant, and which preferably is supported, controlled, and improved on a timely, regular basis by the originators thereafter so as to forestall the acceptance of diverging non-standard extensions and workarounds by others. The Mac comes very close to being a really good example of this form of standardization, and DOS a nearly perfect nonexample. Standard user interfaces on X? Let's see how it turns out. --dave yost
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/02/89)
Could someone shed some light if X could or is not intended to
incorporate [programmability] ?
It certainly could. Display PostScript as an X extension is one
example of (output-oriented) programmability. But whether a standard
will ever emerge for general programmability, I have no idea.