Re: WM_CLASS purpose?
Wed, 31 Oct 2012 20:05:22 +0100 от Thomas Lübking thomas.luebk...@gmail.com: On Mittwoch, 31. Oktober 2012 18:19:02 CEST, Vladimir A. Pavlov wrote: One more question: would it be correct to set only WM_WINDOW_ROLE and not to set WM_CLASS, WM_CLIENT_LEADER, SM_CLIENT_ID? No. It does *not* substitute any of those. I understand it does not substitute them. But if I have a proper WM_WINDOW_ROLE value I don't need WM_CLASS/etc at all. I'm just searching a way to distinguish between taskbar and menu. AFAIU I should set WM_CLASS to somebox/SomeBox (not, for example, somebox/Menu or someboxmenu/SomeBox) for it so WM_CLASS wouldn't help me here. So I see no reason to set WM_CLASS since the only property that would help me is WM_WINDOW_ROLE. I'd like to only set WM_WINDOW_ROLE and leave WM_CLASS/WM_CLIENT_LEADER/etc empty to have as little code as possible since I don't use those. In general you should provide the info you have to allow the WM to classify the client as good as possible, but this of course heavily depends on what you're doing there (ie. if i write me some testing X11 code to fire a window and do sth. with it, i won't set any of those properties.) WM_CLASS and WM_NAME are kind of mandatory for regular clients, esp. WM_CLASS allows WMs to autogroup clients on one VD, in a tab stack, navigate only inside this class etc. The SM_CLIENT_ID is required on the window that is set as WM_CLIENT_LEADER by itself or other clients and this information is requried if you want to preserve window states across sessions (logout, login, autostart former present clients) That's what I'm asking about. If I set WM_CLIENT_LEADER for a window I _must_ set SM_CLIENT_ID for it. But must I set anything for a window I set WM_WINDOW_ROLE for? IOW is it an allowable situation when a window only have WM_WINDOW_ROLE property and nothing else? Whether you want this depends on what client you write but should provided by a toolkit (in case you're writing such) and is supported by the major ones (Qt Gtk+) I'm working on a window manager, not a regular client. It can distinguish between its windows (taskbar, menu, etc). And if I set menu role to somebox-menu then external apps could detect window manager menu as well and there would be no need in WM_CLASS/WM_NAME/etc. My goal is to allow other applications to distinguish between windows created by somebox by as little code as possible. I thought about setting WM_CLASS but it appeared to be incorrect. Not I think about using WM_WINDOW_ROLE so WM_CLASS is unnecessary for my task. But what do the standards say about this? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: WM_CLASS purpose?
For example, let's suppose I have a window manager somebox that has taskbar, dock, menus for starting applications/switching workspaces and configuration dialogs. What should be res_name/res_class for each of them? An X client should have a single name and class. You shouldn't use different values for different windows within a single client (however, it's possible for a single process to contain multiple clients by calling XtOpenApplication() multiple times; each client has a separate X connection and XtAppContext). So, if _you_ write a window manager somebox what values would you use for res_name and res_class in the above example? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: WM_CLASS purpose?
Vladimir A. Pavlov wrote: I'm working on a window manager and I got a few questions concerning WM_CLASS property. The questions are: 1. What is WM_CLASS's purpose? I thought it's to find X resources set by xrdb but Xrm* functions doesn't seem to depend on it. Is there any specific purpose, or does WM_CLASS have no specific purpose and just stores the info that other apps/users decide on how to use it? The application class is more general than the name. E.g. a user may run multiple instances of an application with different names, but they will normally all have the same class. The class is used for locating resource files (and other files located via via XtResolvePathname), and for specifying most resources in e.g. ~/.Xdefaults. You can provide custom resource settings for specific instances by using the name in the resource setting instead of the class. The WM_NAME and WM_CLASS properties make this information available to other clients, e.g. the window manager and editres. The application will set these properties to the same values which it passes to Xt. 2. Are there rules (recommendation) that an application should follow when setting res_name and res_class? Normally, the class is hard-coded while the name will be set to the base name of the executable (determined from argv[0]). These can normally be overridden with the -class and -name switches. For example, let's suppose I have a window manager somebox that has taskbar, dock, menus for starting applications/switching workspaces and configuration dialogs. What should be res_name/res_class for each of them? An X client should have a single name and class. You shouldn't use different values for different windows within a single client (however, it's possible for a single process to contain multiple clients by calling XtOpenApplication() multiple times; each client has a separate X connection and XtAppContext). -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
