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:
> > > > Hello,
> > >
> > > Hm, it it really necessary to have a flood of new commands and
> > > styles to fine tune everything?
> >
> > I think that one thing the users like with fvwm is that they
> > can configure it the way they want ("Do it your way").
>
> Yes, but in some areas we should really take care that things
> don't get too complicated. I'm especially concerned about the
> icon selection. The code is very touchy right now and adding
> three more styles may well make it unmaintainable.
>
I just read the icons code it is not so complex (the bug I introduce
was a big mistake: I forget a break in a case switch; the bug does not
come because I was unable to read the code).
[ snip, snip ]
> > > > * MiniIconOverride / NoMiniIconOverride
> > > > MiniIconOverride causes fvwm to ignore the mini icon provided by the
> > > > application and to use the mini icon defined by the MiniIcon style.
> > > > NoMiniIconOverride reestablish the default which is to use the mini
> > > > icon provided by the application.
>
> See above.
>
> > > > * 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.
> > > > * 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).
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
EWMHDonateIcon / EWMHDontDonateIcon
>
> > > > * 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.
> > > > * Note on working area:
> [snip]
> > > > * NoWorkingAreaPlacement/ DynamicWorkingAreaPlacement /
> > > > WorkingAreaPlacement
> [snip]
> > > > * MaximizeIgnoreWorkingArea / MaximizeUseWorkingArea /
> > > > MaximizeUseDynamicWorkingArea
> [snip]
> > > > * FixedMaximizing / DynamicMaximizing
> [snip]
> > > > * IgnoreWMStut / UseWMStrut
> [snip]
>
> I'm not sure what to do about these. I wondoer if fvwm would ever
> be used *inside* Gnome or KDE. If not, we'd just have to deal
> properly with the hints the applications set. The philosophy
> behind a desktop environment and fvwm are a poor match. The fvwm
> user expects that applications 'do as I want' while the Gnome/KDE
> developers expect that applications 'do what the application
> programmer does'. My few attempts to get fvwm running under
> either failed utterly - they simply assume that the window manager
> does nothing else but draw windows.
>
At present time I use fvwm inside KDE2 (I know some users which
do that with fvwm-ewmh and which are happy). There are users which
use fvwm inside GNOME1 or which use the GNOME1 panel only.
Of course if we do not try to do so that fvwm can run inside
KDE2+ or GNOME2+ this will be always a mess.
Note that kwin is GUI configurable but absolutely not configurable
as fvwm. Moreover kpager is very weak (and the future GNOME2 pager
will be probably weak) compared to FvwmPager. So users which
like .fvwm2rc and want "a panel" (kicker) and/or a desktop
application (yes some users want such app!) and/or a session manager
and/or use certain KDE app which work better together with one of the
above app will use fvwm and not kwin.
What I propose is: use fvwm with GNOME/KDE and you will be able to do
"as you want".
>
> > 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)
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]
