pds@quintus.UUCP (Peter Schachte) (04/28/88)
I think I see a general problem with the X toolkit vis-a-vis window managers, and I wonder if anyone has any ideas about this, or can tell me why this isn't a problem. If I create an X window (whose parent is root), the window manager can jump in and put on title bars, close widgets, and whatever it wants, in order to create the desired look and feel. This is good. However, if my program puts a scrollbar in that window, the code to implement the scrollbar is part of my program's executable, so the window manager can't do anything to implement it's look and feel for scrollbars. Whoever's toolkit I use when compiling my program supplies the look and feel to my scrollbar, and no matter what window manager I run, the scrollbar will look the same. This seems to defeat the idea of allowing users to choose their window manager. Wouldn't it make more sense for the implementation of the widgets in the toolkit to live in the window manager? Or am I completely confused? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
jim@expo.lcs.mit.edu (Jim Fulton) (04/28/88)
> [description of creating a window that gets reparented by a window manager] > However, if my program puts a scrollbar in that > window, the code to implement the scrollbar is part of my program's > executable, so the window manager can't do anything to implement it's > look and feel for scrollbars. Whoever's toolkit I use when compiling > my program supplies the look and feel to my scrollbar, and no matter > what window manager I run, the scrollbar will look the same. This > seems to defeat the idea of allowing users to choose their window > manager. Wouldn't it make more sense for the implementation of the > widgets in the toolkit to live in the window manager? At which point, your window manager probably becomes a User Interface Management System as well. In a sense, a window manager is only responsible for the top most part of the tree; the subparts can be thought of as being managed in a hierarchal fashion by whatever toolkits, subsystems, etc. are built into the application. root / | | \ <------- manipulated by .-----------' / \ `--------. first window manager / / \ \ xclock xterm xmag nested top level window manager manipulated by ---> / \ top level toolkit / \ / \ <------ manipulated by scroll text / \ second window bar area xclock bitmap manager The first window manager determines the look and feel of interactions involving objects on the top row. The second window manager determines the look and feel for the subtree on the right (this is one way to debug window managers). The widgets choosed by the implementor determine the look and feel of the scrollbar and text area within the xterm. This gives a consistent interface for manipulating top level windows, and some small amount of visual similarity in the case of window managers that wrap title bars and such around application windows. The next step is to get cooperation, uniformity of interaction, and perhaps even visual coherence among the various applications. This can be done in several ways, two of which include: 1. Have all applications use a common high-level component set. Various vendors will undoubtedly create such sets that they will use in their own products as well as any third party developer that they can convince. 2. Have all applications use a User Interface Management System that handles the UI for them so they don't have to worry about choosing the right widget set. The UIMS can then take care of all of the common window trappings (e.g. scrollbars, titlebars, move and resize boxes, message areas, menus, buttons, palettes, sliders, radio buttons, dialogue boxes, control panels, etc.) so that the application doesn't have to. The UIMS and the client use a common protocol to communicate (e.g. "scroll up by 1 unit" or "clear current selection"), but the application doesn't have to worry about managing the presentation of the desired user interface. Many UIMS allow layout of various widgets graphically or through a descriptive (i.e. non-programming) language. The down side is that we don't currently know enough about them to try to define what a "standard" UIMS interface should be. There are already several UIMS's that run on top of X and there are others in the works. I personally think that UIMS's are the right way to build sophisticated, integrated graphical interfaces, but I will admit to being somewhat biased. Jim Fulton MIT X Consortium (617) 253-1428 jim@EXPO.LCS.MIT.EDU