On Tue, Nov 20, 2001 at 06:49:36PM +0100, Dominik Vogt wrote: > 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 ] > > > 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 > ... >
Yes, I think with fvwm-themes/wm-icons config scheme in head which defines wm-icons icons for most of the KDE application. We should fix the things in fvwm-themes/wm-icons by splitting the icon lists. > > > > > > * 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. > No, No, No. I propose to set an ewmh icon for app that does not provide one. There is nothing in the spec that forbid this. I do *not* propose the Override style I just say that maybe one day a user will ask such style. Anyway, this is technically possible (and implemented in fvwm-ewmh): if an application change or rest its ewmh icon it should send a _NET_WM_ICON Property Notify message, so we can reoverride it (but this may lead to unacceptable competition so again I do not propose this). Moreover, the spec ask to play with application data: some application properties (e.g., _NET_WM_STATE, _NET_WM_DESKTOP, _NET_WM_VISIBLE_NAME) must or should be set by the wm (as with some GNOME1 hint). Some others window properties must or should be set by the application (e.g., _NET_WM_NAME, _NET_WM_STRUT). For _NET_WM_ICON nothing is said about who should set it. Of course it is implicitly assumed that it is the app that should/may (?) set it. Anyway, for app which dose not provide one I do not see why the wm should not. Finally, I do not see why we should not implement a feature because it is not in the spec. The ewmh spec is far from being a bible. > > > > * 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. > I use the "ewmh spec" since 7 months now (with fvwm-ewmh). I never see an application which do a funny thing with its _NET_WM_STATE after mapping. But I am agree that this may happen one day. So we may have * EWMHIgnoreInitialWMStateHints / EWMHUseInitialWMStateHints * EWMHIgnoreRunningWMStateHints / EWMHUseRunningWMStateHints and this style may have args: a space separted list of states? Or a more general: * EWMHIgnoreInitialHints [args] / EWMHUseInitialHints [args] * EWMHIgnoreRunningHints [args] / EWMHUseRunningHints [args] where args is a space separated list of ewmh state and other hints as the Desktop, the strut, ..etc. > > > > 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 > No, this hint have noting to do with placement. Amor need to know the size of the border and title height of the windows to go arround it (e.g., to jump onto the title bar and not on the top of the "interior" of the window). Olivier -- 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]
