On 11 Oct 2001 03:09:01 -0400, Daniel Richard G. wrote:
>
> I'm building my own perfect .fvwm2rc file, and would like to have windows
> lose their borders/handles when they are maximized. (Both to disable
> resizing in an obvious way, and to free up a tad more screen space)
>
> So, as far as I could grok the man page, the way to do this would be with
> a decor. The maximize function is thus:
>
> DestroyFunc FuncMaximize
> AddToFunc FuncMaximize
> + I Current (!Maximized) ChangeDecor DecorMaximized
> + I Current (Maximized) ChangeDecor Default
> + I Maximize
>
> But then, I run into trouble declaring the decor. Below is the code I have
> so far:
>
> # Maximized windows will have no borders or handles
> #
> DestroyDecor DecorMaximized
> AddToDecor DecorMaximized
> + Style StyleMaximized UseDecor Default, BorderWidth 0, NoHandles
This is not legal, Style like any other command can't appear in decor.
Currently it has the same effect as without "+" and you get a warning.
So, you defined an empty decor (it is not even Default).
> This fails in at least four ways, which are detailed below. If anyone
> knows what I'm doing wrong above, or perhaps can think of a better way of
> doing this altogether, I'd greatly appreciate hearing from you!
> 1. BorderWidth and NoHandles are accessible only in a Style command, and
> Style is not permitted in a decor definition. (The man page says this,
> somewhat indirectly, in the AddToDecor section---but the example given
> contradicts that. Bug?). Fvwm complains, and effectively executes the
> Style command immediately. (If I replace "StyleMaximized" with "*" then
> all windows, maximized or not, lose their borders)
There is no contradiction, please read a warning on the standard error.
Fortunately or not, decors do not control border width; styles do.
So, your idea of changing decor for a given window dynamically is good,
but does not help in this specific case.
> 2. "Style" appears to be a bad way of implementing the "borderless
> maximize" functionality, because its scope can only be specified by a
> window name/class/resource---it cannot be applied to *one specific window*
> and no other. If I maximize an XV window, say, and start up another XV
> instance elsewhere, the second XV window should have borders!
Yes, Style as we know it now does not help in 100% of cases. In the future
there will be an ability to apply Style to individual windows.
> 3. DecorMaximized, as given above, doesn't seem to inherit the effects of
> the large number of "Style *" and other ____Style commands that precede
> it. Right now, when I maximize a window, the window decorations take on a
> distinctly uncustomized look. How do I make DecorMaximized inherit
> everything from the Default decor?
You can't inherit decors, you should recreate them from scratch or
initialize like it is suggested in the link I posted 2 days ago.
> 4. Even if I jury-rig the first snippet of code to use "Style $n" to
> assign "BorderWidth 0 ..." to the maximized window, the borderless window
> does not fill the entire screen---it leaves a space at the right and
> bottom edges that is twice the normal BorderWidth. Fvwm doesn't seem to be
> taking into account the changed dimensions of the window. (Would some
> invocation of Recapture do the trick here? How?)
If you first remove borders and then Maximize, there should be no any gap
for freely resizable windows. But you can't remove a gap for grid-like
resizable windows like xterm, if you use font 7x14 you may have a gap up
to 6 pixels at the right and up to 13 pixels at the bottom.
Regards,
Mikhael.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Thu Oct 11 2001 - 19:45:47 BST