Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ncrlnk!wright!maize!adatta From: adatta@maize.wright.edu (Amitava Datta) Newsgroups: comp.windows.x Subject: Re: Window Managers and Client Menus Message-ID: <654@thor.wright.EDU> Date: 17 Sep 89 07:20:49 GMT References: <8909170306.AA16932@Larry.McRCIM.McGill.EDU> Sender: news@wright.EDU Lines: 65 This is in reply to > 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)