ellis@AUDI.SIEMENS.COM (Ellis Cohen) (02/11/88)
Jordan Hubbard (jkh@violet.berkeley.edu) writes > The REAL PROBLEM is a seemingly total lack of agreement on more > "standard" property types. There are all sorts of gadgets that window > managers are/will be creating in the near future (title bars, gadget boxes, > etc etc) that are completely unchangable as far as clients are > concerned. I can't even tell what a client chose for background > foreground and border colors, which is essential if the window manager > is to modify windows intelligently (who wants black and white gadgets on > a multi-colored window?). Then there are things like the preferred > title bar font, whether or not a title bar is even desired (a title bar > on a clock looks stupid) and all sorts of size/shape specifications. > > I'm sure that someone, somewhere, is thinking about this (Ellis? You out > there?), but they're not nearly public enough. I'd be more than happy > to propose a few property types, but if the applications folk don't adhere > to them (or if I've chosen conflicting names), it's for nothing. I'm out there, but just back from the Bahamas! I raised this issue at both the window manager developers meeting and the Xtk BOF at the X Conference. One way to handle your concern is by having applications post a property that indicated something about their choices for decorations. The window manager could read this property and use it as appropriate. This approach was rejected at the wm developers meeting for a number of reasons -- Partly because there is no agreed upon set of standard decorations. Most wm's will provide headers and borders, but even here there is a lot of diversity, not to mention gadgets. The point is, with such diversity, it is not possible at this time to agree upon what should be in such a property. However, a solution that works 99% of the time avoids these problems by using the resource database. In particular, to tell wm's that you want xterm to have purple headers, you can put in your defaults file Wm.xterm.HeaderBackground: purple I suppose that if your window manager believes that a window should have headers which are the same color as the window background color by default, then it might look for xterm.Background in the resource database if it didn't find the HeaderBackground entry. While it is expected that there will evolve a set of resource names that will be relevant to most window managers, there is no need for a priori agreement. A Window Manager that has FrobGadgets will be able to look for FrobGadgetBackground in the resource database. As for standardization ... I am collecting a list of resource names that would be useful to many (though not necessarily all) window managers. I believe that the maintenance of this list will eventually be one function of a Window Manager Consortium Committee. In the meantime, I am maintaining the list informally. If you send additional names to me, let me know if you think they are just a "good idea", or whether they are are actually going to be used by your specific window manager. Here is my current list. Both names and semantics are almost certain to change for many items, and I would welcome comments about either. There is no guarantee that any window manager will pay attention to any of these. I hope though, that we will be able to standardize on some of them, and put out a list of which wm pays attention to which name. << THIS LIST IS NOT OFFICIAL IN ANY WAY !!! >> ------------------------------------------------------------ GLOBAL WM RESOURCE NAMES ------------------------------------------------------------ FocusFollowsPointer: BOOL If on, then the wm is real-estate driven. If off, a click-to-type model is used. ------------------------------------------------------------ PER-WINDOW WM RESOURCE NAMES -- BEHAVIOR RELATED ------------------------------------------------------------ AlwaysDisplayIcon: BOOL If set, then the icon is always displayed (unless ShowIcon is false), even when the corresponding window is open. If the main window is also used as a client icon window, then the icon is displayed as a pixmap or wm default when the main window is mapped. ExpensiveToRedraw: BOOL If set, indicates that the window is expensive to redraw. The wm will try to avoid obscuring, resizing, or iconizing it. This is a weaker version of a combination of KeepVisible, LockedOpen, and FixedSize. FitOnMapping: BOOL If set, then when the window is mapped, its size and position are adjusted so that the window (including any wm-provided decorations) could potentially be completely visible (e.g. if no other windows were on the screen). FixedWidth: BOOL FixedHeight: BOOL FixedSize: BOOL FixedCompletely: BOOL These settings respectively tell the wm that it should not automatically (as a side effect of an a change to another window) change a window's (1) Width (2) Height (3) Size (4) Size and Location, though if allowed, it may iconize the window instead. IconizeWithTransients: BOOL If set, then if the wm automatically, or on behalf of the user iconifies or deiconifies this window, then any transient windows associated with it are also iconified or deiconified. (Clients who request that a window be iconified will need to explicitly request that transients be iconified). KeepVisible: BOOL If set, then the wm will avoid automatic actions that obscures the window, except by transient windows of its own (or in its own window group). Window managers may, for example, use this information in the placement of other transient windows. KeepVisibleForTransients: BOOL If set, then the wm will prevent a window from being obscured by its transient windows. LockedOpen: BOOL If set, then the wm will not automatically iconize the window. LockedOpenWhenListener: BOOL If set, then when the window is the listener, the wm prevents it from being iconized unless explicitly requested by the client or user (i.e. not as a side effect of another action by a client or user). The listener is the top-level window which last received (or contains the window which last received) input. ProtectWhenActiveListener: BOOL If set, then when this window is the active listener, the wm prevents it from being iconized or reconfigured unless the result of a user action, or unless explicitly requested by the client (i.e. not as a side effect of another action by a client). In addition, while it is the active listener, the wm acts as if KeepVisible is set (which attempts to prevent the window from being obscured). (A top-level window is the active listener when it is or contains the focus, and also is or contains the window to which input was last directed). SaveInLayout: BOOL Indicates whether information about the window will be saved by session management. ShowIcon: BOOL If not set, an icon is not displayed when this window is iconified. Wm's which support this will likely have another mechanism for deiconifying windows (e.g. a menu of iconized windows). ShowIconsForTransients: BOOL If set, then the wm will display icons for transients of the window even if a pixmap or client icon window for the transient itself has not been provided (assuming the wm displays icons for non-transients in such cases). ------------------------------------------------------------ PER-WINDOW WM RESOURCE NAMES -- APPEARANCE RELATED ------------------------------------------------------------ BorderColor: STRING8 BorderHighlightColor: STRING8 The name of the color to be used for the wm-provided border both under ordinary circumstances and when it is highlighted. BorderWidth: CARD16 The width of the wm-provided border for this window. HeaderBackground: STRING8 HeaderForeground: STRING8 HeaderHighlightBackground: STRING8 HeaderHighlightForeground: STRING8 The colors to be used for the header background and window title both under ordinary circumstances and when the header is highlighted. HeaderHeight: CARD16 The height of the header for this window. IconWindowName: STRING8 If provided, used instead of WM_ICON_NAME IconPixmapFile: STRING8 The name of a file containing the icon pixmap to be used for the window's icon (overrides the pixmap provided in WM_HINTS). IconBackground: STRING8 IconForeground: STRING8 IconHighlightBackground: STRING8 IconHighlightForeground: STRING8 For default icons. The color of the icon background and title both under ordinary circumstances and when the icon is highlighted. IconTitleFont: STRING8 The name of the titlefont that should be used for the icon title (assuming that it is compatible with the type of WM_ICON_NAME). IconWidth: CARD16 IconHeight: CARD16 The size of the window's icon. IgnoreIconPixmap: BOOL If set, the window manager should ignore the icon pixmap in WM_HINTS. IgnoreIconWindow: BOOL If set, the window manager should ignore the client icon window field in WM_HINTS. IncludeClientMachineInTitle: BOOL IncludeNameInTitle: BOOL IncludeResourceClassInTitle: BOOL IncludeResourceNameInTitle: BOOL Indicates if the wm should include the specified information in the window title. IncludeClientMachineInIcon: BOOL IncludeNameInIcon: BOOL IncludeResourceClassInIcon: BOOL IncludeResourceNameInIcon: BOOL Indicates if the wm should include the specified information in the icon. MainWindowCanBeIcon: BOOL If set, then the wm can use the main window as a client icon window. ProvideHeader: BOOL If set, the window manager should provide a window header ProvideBorders: BOOL If set, the window manager should provide borders for the window TitleFont: STRING8 The name of the titlefont that should be used for the window title (assuming that it is compatible with the type of WM_NAME). WindowName: STRING8 If provided, used instead of WM_NAME
diamant@hpfclp.HP.COM (John Diamant) (02/12/88)
> In particular, to tell wm's that you want xterm to have purple > headers, you can put in your defaults file > > Wm.xterm.HeaderBackground: purple The use of the "Wm" resource class for all window managers has always bothered me. I recognize this from the conventions manual David Rosenthal is writing. The problem is that the standard convention for res_class is the "name" of an application (typically argv[0]). Now, I understand that the name doesn't always have to be argv[0], but I believe it does have to be something that uniquely identifies one application from another (even another application which performs the same function). If you follow a consistent set of conventions, then the window manager res_class must be something like "uwm" or "wm" (that specific window manager) or whatever, but not "Wm." What this boils down to is the need for more than two levels of class structure in the resource database. We need: unique identifier of instance (res_name -- buffer1) unique identifier of application (res_class -- emacs) class of application (??? -- Editor) Both you (Ellis) and I raised mentioned this issue at the Toolkit BOF. You've come up with a way of doing this apparently by specifying the superclass in the .Xdefaults (app.Superclass or something, if I remember correctly), and we've proposed using an #ATTACH pseudo-op in the .Xdefaults file (#ATTACH Editor TO emacs). I don't care which method is used, though I believe a standard method would be much better than everyone coming up with their own. I think it is strongly indicative of the need for such an enhancement when a document designed to specify conventions must violate the very conventions it is documenting, in order to provide a piece of needed functionality. John Diamant SDE UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO