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'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,
Okay, I see no way to achieve this otherwise. But keep in mind
that the user can change this style at any time and that fvwm must
then immediately change to the new behaviour. This probably means
that the ewmh mini icon has to be stored at a different place than
the normal mini icon. Remember that update.c and the related
function at the end of style.c has to be adapted.
> 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).
See below.
[snip]
> > > 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 ?
Yes.
> > > * 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.
> > > * 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.
> > > * 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.
I'd prefer to remove this one. If you don't want animation, don't
use FvwmAnimate.
> > > * 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?
> > > * 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.
> > > Command:
> > > -------
> > >
> > > * EwmhNumberOfDesktop d
> > > Where d is an integer > 0 and define the number of desktop you want to see
> > > in a compliant pager.
I think we can't get around this one.
> > > Note that this number is automatically updated
> > > if you go to a Desk k > d.
I wouldn't do that. Our own pager doesn't react to new desks
either.
> > > On the other hands, negative Desk are not
> > > supported and can put some compliant pager and taskbar into big trouble.
Yeah, I can remember the discussion about negative desks. The
majority of the wm-spec list thought them to be useless and so
made an unnecessary limitation :-(
> > > * 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.
Yes, a function in the style of WindowListFunc should do. I'd
call it EwmhActivateWindowFunc.
^^^^
> > > * EwmhFvwmStrut left right top bottom
>
> EWMHBasePlacementHint left right top bottom ?
If you ask me: let's ignore struts altogether and focus on
enhancing the placement algorithms in fvwm. Or maybe the struts
could be used as an area with a higher placement penalty. Then
the EwmhUse/IgnorePlacemntHint styles could be used.
> > > 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)
Argh! So much about standards. In this case, I'd rather ignore
Gnome/KDE specific hints altogether until is starts hurting ;-)
> (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?
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]
