On Tue, Nov 20, 2001 at 05:09:26PM +0100, Olivier Chapuis wrote: > On Tue, Nov 20, 2001 at 12:24:58PM +0100, Dominik Vogt wrote: > > On Tue, Nov 20, 2001 at 08:49:38AM +0100, Olivier Chapuis wrote: > > > On Mon, Nov 19, 2001 at 11:59:48AM +0100, Dominik Vogt wrote: > > > > On Fri, Nov 16, 2001 at 08:17:01PM +0100, Olivier Chapuis wrote: > > [ snip, snip, snip ] > > > > > * IgnoreEwmhIcon / ForceEwmhIcon / UseEwmhIcon > > > > > These styles extends the IconOverride / NoIconOverride / > > > > > NoActiveIconOverride styles. > > > > > ForceEwmhIcon causes fvwm to use the ewmh icon hint (if any) > > > > > in priority even if the IconOverride style is used or the application > > > > > have > > > > > an icon window (and NoIconOverride or NoActiveIconOverride is used). > > > > > IgnoreEwmhIcon causes fvwm to do as if the application has no ewmh > > > > > icon > > > > > hint at all. > > > > > UseEwmhIcon is the default and causes fvwm to use the ewmh icon hint > > > > > if the application have no icon window and the IconOverride style is > > > > > not used. > > > > > > > > > > > Why the ForceEwmhIcon? Because it is the style *I* want :o) > > > > I don't see why we need the ...Icon styles. The Ewmh icon is > > just another way to specify an icon. Currently there are three > > ways an application can have an icon: by fvwm style, by the > > application using a pixmap and by the application using a window. > > I'd just handle the Ewmh hint as a different way for the > > application to specify the pixmap (or window?) that is preferred > > to the normal icon hint. The existing icon options would still > > specify if the fvwm icon, or the application pixmap or window is > > used. > > > > > So EWMHMiniIconOverride / EWMHNoMiniIconOverride > > > and EWMHIgnoreEwmhIcon / EWMHForceEwmhIcon / EWMHUseEwmhIcon ??????? > > > > > > Or simply, > > > > > > EWMHUseIconHint/EWMHIgnoreIconHint > > > > > > with EWMHUseIconHint = EWMHNoMiniIconOverride + EWMHForceEwmhIcon > > > and EWMHIgnoreIconHint = EWMHMiniIconOverride + EWMHIgnoreEwmhIcon > > > > > > It is ok for me (but for other users?). > > > > These two styles provide the same functionality as the five above. > > It only really makes a difference if both, fvwm and the > > application provided a mini icon. In this case you can simply > > fine tune the style. The speed argument doesn't count here. > > > > I am not sure to understand. However note that the above styles > allow automatic config: I do not like most of the icon that are > provided by the "X" applications, as I like the KDE (ewmh) icon. > So I am happy with Style * IconOverride, EWMHForceEwmhIcon > and I do not want to type a never finished list of lines like: > > Style * IconOverride > Style "kapp1" NoIconOverride > Style "kapp2" NoIconOverride > ... > Style "gapp1" NoIconOverride > Style "gapp2" NoIconOverride > ... > > The same remark apply with mini icon.
Nope, you only have to override the ugly icons as always: Style * IconOverride Style app_with_ugly_icon1 Icon my_pretty_icon.xpm Style app_with_ugly_icon2 Icon my_pretty_icon.xpm ... > > > > > * DoNotSetMiniIcon / SetMiniIcon > > > > > * DoNotSetIcon / SetIcon > > > > > > EWMHDoNotSetMiniIcon / EWMHSetMiniIcon, EWMHDoNotSetIcon / EWMHSetIcon > > > > > > or simply: > > > > > > EWMHDoNotSetIcon / EWMHSetIcon ? > > > > > > or EWMHDontSupplyIcon / EWMHSupplyIcon or EWMHDontDonateIcon / > > > EWMHDonateIcon ? > > > > > > "ok" again (but for others users?). > > > > Hm, what is this functionality good anyway? Why would fvwm want > > to set the application's icon? Only the application should use > > the icon anyway. I see no real need for this. > > > > It is one of the most useful feature of *our* ewmh implementation. > Of course this is out of the spec. The point is that allows to have > the same mini icon in the menu, in the window list, in the various > modules *and* in any compliant application. The same apply to icon > (some compliant application prefer a big icon). But it's still only a hack if it's nor part of the spec. The application may reset that value at any time and void our efforts. > Maybe one day a user would want that complaints application do not > use the ewmh (mini) icon that provide the app but the one that > provide the Icon or/and MiniIcon style command. So here in fact we may > want to add an Override style! > Moreover, now I think it is not a good idea to have only > "one" style. Really I prefer: > > EWMHDontDonateMiniIcon / EWMHDonateMiniIcon Might work for mini icons, > EWMHDonateIcon / EWMHDontDonateIcon but for regular icons this is way too far off any spec. A decent window manager should really not fiddle with the application's data. > > > > > * IgnoreEwmhWMStateHints / UseEwmhWMStateHints > > > > > IgnoreEwmhWMStateHints causes fvwm to ignore the ewmh _NET_WM_STATE > > > > > when > > > > > an application is mapped. Such hints may ask to map the application > > > > > sticked, > > > > > shaded and/or maximized, to put the window in the window SkipList > > > > > and/or > > > > > to consider the application as a modal application. > > > > > UseEwmhWMStateHints > > > > > reestablish the default which is of course to use these hints > > > > > > > > > > > * EWMHIgnoreWMStateHints / EWMHUseWMStateHints > > > I think there is no objections for this one. I recall that WMState can > > > ask for: Maximize (Vertically and/or Horizontally), Shade, WindowListSkip, > > > stick, modal (I will come back on this state one day ...) and non standard > > > stacking states (not taken in account by the style). > > > > Hm, when is fvwm meant to honour this hint? Only when the window > > becomes mapped? > > > > fvwm should honor this hint at window mapping. Then, it must maintain > the _NET_WM_STATE to the *real* window state. Moreover, fvwm can receive > a _NET_WM_STATE Client Message (typically a compliant taskbar may ask > to shade a window) I do not think it is a good idea to reject such a > client message as it is probably the user that ask to put the window > in the asked states. In my experience it is far more often a funny application that sends these commands than a taskbar or whatever. If things continue to work our as they do at the moment, suppressing these requests (or just some of them) may very well become a reasonable default soon. [snip] > > > EwmhKdeSupport add support for > > > (i) the _KDE_NET_FRAME_STRUT hint (this hint should be set by the wm for > > > each windows, it gives the size of the decoration) > > > > Argh! So much about standards. In this case, I'd rather ignore > > Gnome/KDE specific hints altogether until is starts hurting ;-) > > > > For me the _KDE_NET_FRAME_STRUT is very important: I know only > one application which use it, it is amor, it is a small smiley which > go around the windows, my 22 months daughter like it a lot :o) :) But still, once we've improved the placement algorithms, you can just set the penalty high enough and get the same effect, but can still override it manually without digging obscure configuration menus: Style amor PlacementOverlapPenalty 1000000 Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
