Subject: FVWM: Frameless maximized windows

From: "Daniel Richard G." <[email-masked]>
Date: Thu, 11 Oct 2001 03:09:01 -0400

Hello all,

[Recent convert from Window Maker here! :D  Other window managers may be
prettier than Fvwm, but I've come to realize that *feel* is really what
counts. Kudos to everyone who's worked on this fine project; I think I'll
be sticking with it for a long time to come]

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 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!

Sincerely,

--Danny

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)

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!

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?

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?)

Daniel Richard G.
<[email-masked]>
MIT Computer Graphics Group

--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 12 Oct 2001 00:45:37 +0000

> 	+ 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).

> 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.

> 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.

> 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.

> 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.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 12 Oct 2001 01:03:23 +0000

On 12 Oct 2001 00:45:37 +0000, Mikhael Goikhman wrote:
> > bottom edges that is twice the normal BorderWidth.
> 
> for freely resizable windows.

I got your problem. For Style and TitleStyle commands to be applied in the
middle of function you should do UpdateStyles (between Style BorderWidth 0
and Maximize). Otherwise Maximize will indeed take into account borders.

Regards,
Mikhael.

---

From: "Daniel Richard G." <[email-masked]>
Date: Thu, 11 Oct 2001 22:56:44 -0400

> Fortunately or not, decors do not control border width; styles do.

I saw the warning. I should have been more clear; the contradiction was
that the man page implies that it is illegal to place a Style command
within an AddToDecor definition---and then proceeds to give two code
examples that do exactly that. To quote:

              AddToDecor is similar in usage to the AddToMenu and
              AddToFunc commands, except that menus and functions
              are   replaced   by   ButtonStyle,  AddButtonStyle,
              TitleStyle, AddTitleStyle and BorderStyle commands.

...versus...

              The  following  example creates a decor "FlatDecor"
              and style "FlatStyle".  They are distinct entities:

                   AddToDecor FlatDecor
                    + ButtonStyle All ActiveUp (-- flat) \
                      Inactive (-- flat)
                    + TitleStyle -- flat
                    + BorderStyle -- HiddenHandles NoInset
                    + Style FlatStyle UseDecor FlatDecor, \
                        Color white/grey40,HandleWidth 4

...and...

                   AddToDecor FlatDecor
                    + Style FlatStyle UseDecor FlatDecor, \
                        Color white/grey40,HandleWidth 4

Anyway, that's why I thought my StyleMaximized definition was valid at
first. Surely the above is a bug in the documentation, however small...?

> there will be an ability to apply Style to individual windows.

Understood. "Style $w" would kill this issue completely.

> initialize like it is suggested in the link I posted 2 days ago.

Found it in the archives ... ooh, that's not pretty. IMHO, dropping decors
in favor of [a more generalized form of] styles seems like a good idea.
Chalk up some definite newbie confusion to the separation (or lack
thereof) between the two.

> to 6 pixels at the right and up to 13 pixels at the bottom.

I got your other message on this, that an interposing UpdateStyles command
is needed. I should have mentioned that the above-mentioned gaps occurred
with XV as the test subject, but no matter now....

Thank you for your help! I look forward to making this work someday :)

Sincerely,

--Danny

Daniel Richard G.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 12 Oct 2001 12:05:01 +0000

> examples that do exactly that. To quote:

These 2 man page examples were fixed in 2.4.1.

Regards,
Mikhael.