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").
> I'd strip these options down
> to not more than about five, e.g. enabling/disabling icon hints,
> ewmh placement, ewmh stacking, window type, etc. Being able to
> prevent fvwm from setting EWMH hints itself doesn't look much
> useful. I can't imagine a situation where this would hurt.
>
The only styles I propose which say to fvwm to prevent from setting
EWMH hints itself are:
DoNotSetMiniIcon / SetMiniIcon, DoNotSetIcon / SetIcon
I think that this is useful because SetMiniIcon and SetIcon may
dramatically slow down windows mapping on machine with a visual !=
DirectColor || TrueColor (in this case there are width*height call
to XAllocColor, but maybe one can fix this).
> Also, I suggest all EWMH related commands or styles start with the
> string "EWMH".
Ok.
> E.g.:
>
> EWMHUseHints/EWMH/IgnoreHints
> EWMHUseIconHint/EWMHIgnoreIconHint
> EWMHUsePlacementHint/EWMHPlacementHint
> EWMHUseStackingOrderHint/EWMHIgnoreStackingOrderHint
> EWMHUseDecorationHint/EWMHIgnoreDecorationHint
>
> > New styles:
> > ----------
> >
> > * RejectStayOnTopHints / AcceptStayOnTopHints
> > RejectStayOnTopHints causes fvwm to ignore initial (ewmh) hints which ask
> > to put an application into the default StaysOnTop Layer.
> > AcceptStayOnTopHints
> > which is the default causes fvwm to accept this hint.
> > (note: this hint is not a part of the ewmh spec but it is used by KDE).
> >
So EWMHUseStackingOrderHint/EWMHIgnoreStackingOrderHint ?
> > * 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.
> >
> > * 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)
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?).
> > * DoNotSetMiniIcon / SetMiniIcon
> > * DoNotSetIcon / SetIcon
EWMHDoNotSetMiniIcon / EWMHSetMiniIcon, EWMHDoNotSetIcon / EWMHSetIcon
or simply:
EWMHDoNotSetIcon / EWMHSetIcon ?
or EWMHDontSupplyIcon / EWMHSupplyIcon or EWMHDontDonateIcon / EWMHDonateIcon ?
"ok" again (but for others users?).
> > * NoEwmhAnimate / EwmhAnimate
> > If the NoIcon style is used and an ewmh compliant taskbar provide
> > an icon position hint, then fvwm2 ask FvwmAnimate to animate the
> > (de)iconification using this hint. NoEwmhAnimate disable this feature
> > and EwmhAnimate (the default) enable it.
> >
If we have no such style default should be EwmhAnimate. I've no objection
to remove this one.
> > * 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).
> > * IgnoreEwmhWindowTypeHints args
Forget this one should be considered with Window Type configuration.
> > * Note on working area:
> > Without ewmh support the working area is the full visible screen
> > (or all your screens if you have a multi head setup and you use Xinerama).
> > However, a compliant application as a panel can ask to reserve space
> > at the edge of the screen. If it is the case, the Working Area is your
> > full visible screen minus these reserved space. If the panel can be
> > hidden by clicking by a button the Working Area does not change (as
> > you can unhide the panel at any time), but the Dynamic Working Area
> > is updated so that the reserved space by the panel is removed (and readded
> > if you unhide the panel). Note that an autohide panel has a fixed reserved
> > space.
> >
> > * NoWorkingAreaPlacement/ DynamicWorkingAreaPlacement / WorkingAreaPlacement
> > DynamicWorkingAreaPlacement causes fvwm to use the Dynamic Working Area
> > for window placement as NoWorkingAreaPlacement causes fvwm to ignore
> > the concept of working area. The default WorkingAreaPlacement causes fvwm to
> > use the Working Area for window placement.
> >
So you suggest to have EWMHUsePlacementHint/EWMHIgnorePlacementHint only?
Ah no, I see, EWMHUsePlacementHint/EWMHIgnorePlacementHint replaces
IgnoreWMStut / UseWMStrut and we have no
WorkingAreaPlacement/ DynamicWorkingAreaPlacement / WorkingAreaPlacement
style and we use WorkingAreaPlacement as placement policy?
Yes this is ok (but if one want DynamicWorkingAreaPlacement).
> > * MaximizeIgnoreWorkingArea / MaximizeUseWorkingArea /
> > MaximizeUseDynamicWorkingArea
> > MaximizeUseWorkingArea causes fvwm to use the Working Area when you
> > maximize a window as MaximizeIgnoreWorkingArea causes fvwm to ignore
> > the concept of working area. The default MaximizeUseDynamicWorkingArea
> > cause to use the Dynamic Working Area when you maximize a window.
> >
> > * FixedMaximizing / DynamicMaximizing
> > If the MaximizeUseDynamicWorkingArea (respectively, MaximizeUseWorkingArea)
> > style is used then when the (Dynamic) Working Area change the maximized
> > window are maximized again to respect the new area. FixedMaximizing
> > disabled this feature as DynamicMaximizing reestablish the default
> >
So you suggest to use EWMHUsePlacementHint/EWMHIgnorePlacementHint for
computing the (dynamic) working area and to use "DynamicMaximizing"?
But maybe some users will do not like to see its window to be remaximized
when a panel is hidden/unhidden.
> > * IgnoreWMStut / UseWMStrut
> > IgnoreWMStut cause fvwm to ignore the reserved space that an application ask
> > to fvwm for computing the Working Area. UseWMStrut (the default) causes
> > fvwm2
> > to take in account this space in its computation.
> >
> > Command:
> > -------
> >
> > * EwmhNumberOfDesktop d
> > Where d is an integer > 0 and define the number of desktop you want to see
> > in a compliant pager. Note that this number is automatically updated
> > if you go to a Desk k > d. On the other hands, negative Desk are not
> > supported and can put some compliant pager and taskbar into big trouble.
> >
> > * EwmhActivateWindow [cmd]
> > Where cmd is a fvwm2 command (complex or builtin function) to be used
> > when a compliant application ask to activate a window. The default is
> > is to Iconify Off, Focus and Raise. If no argument is given the default
> > is reestablished.
> >
Ok for EwmhActivateWindowAction.
Mikhael, I think Iconify Off, Focus and Raise is better than the window
list function which warps to window (by default). Warping to the window
is natural for the window list as the window list disappear after you select
the window, but this is not the case with a taskbar.
> > * EwmhFvwmStrut left right top bottom
EWMHBasePlacementHint left right top bottom ?
> > Where left, right, top and bottom are positive or null integer which
> > represent an area in pixels from the left of the screen to left, from the
> > right of the screen to right, from the top of the screen to top and from
> > the bottom of the screen to bottom. Default is 0 0 0 0.
> > This area define an additional reserved space to the reserved space
> > defined by some applications.
> > You can override the Working area by using this command together
> > with the command "Style * IgnoreWmStrut"
> >
>
> > * EwmhKdeSupport [bool]
> > Disable/Enabled special support for kde (On by default).
> > Maybe a style?
> >
> > * EwmhGnomeSupport [bool]
> > Disable/Enabled special support for gnome (On by default)
> > Maybe a style?
>
> Yep, styles are better.
>
Yes but it depends on what these commands do. At the present time
EwmhGnomeSupport does nothing (have to wait for a true first
alpha release of GNOME2). But maybe we never need such command if
we want to be ewmh compliant as it is a gtk/gnome developer which
really decides what should go into the spec (at least at the present
time). 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)
(ii) Manage the KDE system tray (indicate which windows should be swallowed
by a panel)
(iii) Some workaround for ksmserver
Maybe a style is better?
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]
