[Solved] Fullscreen window not to cover part of my screen


I’ve got a Lenovo notebook with resolution 1920x1200 and have just bought the following AOC “external display”: us.aoc.com/monitor_display/e2239fwt. The display has a large space below its screen which is meant to be filled with a fully open notebook - you insert notebook’s display below the monitor’s screen so that (basically) only notebook’s keyboard is visible. The display is 1920x1080 - full HD.

I switched notebook’s VGA output on using xrandr and placed the monitor’s screen area on top of the notebooks – the screens have equal horizontal resolution so the monitor displays first 1080 lines of notebook’s screen. I would love to use the remaining 120 lines for some “really always on top” area with pager, email notifications etc. The bottom lines could be visible even with notebook being inserted below monitor…

The question, finally. Is it possible to limit the behavior of windows being switched to full screen mode to not cover the last 120 lines of screen? Mplayer, Flash player etc.? They now cover whole 1920x1200 and while playing back 16:9 videos (for example 1920x1080), the leave two equal stripes of 60 lines on top and bottom of the screen. So a little stripe goes even off the area displayed by the external monitor… How can I prevent this? And what kind of Fvwm applet/panel would you recommend me to fill the last 120 lines with? FvwmButtons with other windows (pager etc.) swallowed?

TIA, Milan


– Thomas Adam

Will you elaborate on it a little bit, Thomas, please?

Who influences geometry of full screen windows? Is it WM’s task? Or do applications (as mplayer) bypass WM?

I’ve played with xrandr after your post. I tried to place VGA above LVDS gaining continuous screen of 1920x2280. The mplayer’s full screen window (mplayer -fs -vo xv) covers the particular monitor on which there is the mouse pointer in time of window creation. The same stays for simple xterm window mapping (TileCascadePlacement).

When I configure the two monitor areas to overlap (even partly), the full screen mplayer window appears always on LVDS (or, maybe, the largest monitor), but xterm is placed on the monitor under cursor.

Oh I am sorry a haven’t mentioned before: up-to-date Debian Squeeze, i686, FVWM 2.5.30.

Fullscreen is something the client asks for, and the WM respects it. In obeying the EWMH spec, if an application asks to go fullscreen then it does so to cover the whole screen.

What you’re describing without fullscreen can be achieved using Maximize with options, or setting EWMHBaseStruts instead, removing the window borders, maximizing the window and then coming out of maximize restores the window afterwards.

But you can’t do what you want with applications going fullscreen.

Use 2.6.2 from fvwm.org.

– Thomas Adam

So I did and found the FVWM source code quite simple. It would be easy for me to e. g. “adapt” EWMH behavior to my idea (violating the standard a bit, hope most applications use the EWMH way of going full screen and not the older ways mentioned in FVWM source code).

Or I might better end up with the special Maximize, which is much more universal. It could be also convenient to introduce this behavior to all windows being maximized (in my setup): I do not need the border on maximized windows (I move them with Alt + mouse and could have them unmaximized automatically as I start to move them). My desktop has been very minimalistic in this way for many years :slight_smile:

Thank you, Thomas, for the fast replies. I appreciate your work for FVWM.

No, it would be easier for you to not assume that there are “bits of standard” and instead consider two things:

  • There’s already a solution (I’ll spell it out for you, since you didn’t quite pick up on it from my previous post)
  • Changing the source code is the wrong thing to do.

You’re not asking for windows to be fullscreen anymore. Your definition of fullscreen is simply “maximized to an offset, without window decoration”. That does not imply in any way a code change to contradict the EWMH specification, just because in your head you’ve conflated two very separate things.

So, how might you do that? Here’s one way:

DestroyFunc FullscreenWithOffset
AddToFunc   FullscreenWithOffset
+ I ThisWindow (!Maximized, !State 1) MaximizeWithFS 100 -20p ewmhiwa
+ I TestRc (NoMatch) ThisWindow (Maximized, State 1) UnMaximizeWithFS

DestroyFunc MaximizeWithFS
AddToFunc   MaximizeWithFS
+ I WindowStyle !Borders, !Handles, BorderWidth 0, HandleWidth 0, !Title, ResizeHintOverride
+ I UpdateStyles
+ I State 1 on
+ I Maximize $*

DestroyFunc UnMaximizeWithFS
AddToFunc   UnMaximizeWithFS
+ I Maximize
+ I State 1 off
+ I DestroyWindowStyle
+ I UpdateStyles

Then you can use it thus:

Pick FullscreenWithOffset

Note this line:

MaximizeWithFS 100 -20p ewmhiwa

I’ve deliberately ignored any EWMHBaseStrut setting for a good reason. You can use this, or ResizeMoveMaximize. It’s up to you.

– Thomas Adam


It’s my first post here.
I really enjoy playing around with Fvwm that I discovered couple of weeks ago.

There’s however one thing so far that I was unsuccessfull to implement into my config.

I’d like to intercept a client application that goes full screen so that I could action it and send it to the top layer, say 6 (StaysOnTop).
At the moment all windows are on layer 4 but fvwmbuttons is on layer 5. Whenever the application like firefox or mplayer goes fullscreen it stays on layer 4 under the fvwmbuttons.

There is probably a better way around this problem. I’m sure someone must have coma across it before.

I am completely stuck and just need a helping hand.

I post the question under this thread because I think it’s a relevant topic.

Thanks for great windows manager!


There are different versions of ‘Fullscreen’ - Window will maximize to the complete screen with or without titlebar.

Without titlebar]#-----------------------------------------------------------------------

This function maximize a window to fullscreen and back - no title, no buttons, no border

DestroyFunc FuncMaximizeFullScreen
AddToFunc FuncMaximizeFullScreen

  • I ThisWindow (Maximized) WindowStyle Title, Borders
  • I TestRc (!Match) WindowStyle !Title, !Borders
  • I TestRc (!Match) Raise
  • I TestRc (!Match) UpdateStyles
  • I Maximize ewmhiwa
    The needed key binding]#-----------------------------------------------------------------------

Alt-F11 maximize active window to fullscreen and back


Keyname Context Modifier Function

Key F11 A M Pick FuncMaximizeFullScreen

With titlebar
You can bind a special Maximize command to a key like[code]

Keyname Context Modifier Function

Key F10 A M Pick Maximize growonlayers $[w.layer] -1 grow grow[/code]or something else :wink:

You have to define the layer for your FvwmButton like Style fvwmbuttons StaysOnBottom Btw. For ‘fvwmbuttons’ you have to use your alias defined for this FvwmButton. See your Module call in the StartFunction]

  • I Module FvwmButtons
    [/code]If you haven’t an alias use ‘FvwmButtons’ instead of ‘fvwmbuttons’.
  • Thomas -

Hello Thomas,

Thanks for a quick response!!
I think I have not made myself clear enough.
My apologies.

What I need is to keep Fvwmbuttons on Layer 5 and dynamically switch windows that goes fullscreen from layer 4 to layer 6 in order to keep them above Fvwmbuttons.

The problem is that I can’t use mouse/key bindings with Fvwm functions like “FuncMaximizeFullScreen” or “FvwmMaximize” because the applications like firefox or mplayer do not use them!
They just go fullscreen using different function, probably from EWMH or something that I am not aware of.
This is the reason why I wish to intercept this event and switch the windows into different layer.

Also, I would prefer not use Styles that are linked to windows titles as I wish to have the method to be universal and applicable to any window that go fullscreen by itself (non-fvwm method).

Can you guide me towards the best solution for such an issue?
Thanks once again.


Why is your Fvwmbuttons on Layer 5? Would you use the complete screen for maximized windows but FvwmButtons should stay in the foreground? Do you know about EwmhBaseStruts to define a working area?

Hmm, not so easy because there exists no event for window maximize or fullscreen…

Try this below. It works on my system but perhaps not on yours.

First we define an event handler]#-----------------------------------------------------------------------

Event Handler

DestroyModuleConfig FvwmEventTestem: *
*FvwmEventTestem: focus_change FE-FocusChange
[/code]Every time focus is changing the function FE-FocusChange will be called.

Now the function]DestroyFunc FE-FocusChange
AddToFunc FE-FocusChange

  • I Any (Maximized, CurrentPage, Visible)
    PipeRead ‘if [ xprop -id $[w.id] |grep -c _NET_WM_STATE_FULLSCREEN = 1 ]; then
    echo WindowId $[w.id] Layer 0 6;
    [/code]It matches on any window which is maximized, on the current page and if visible.

In the PipeRead command we check with xprop whether the window is in fullscreen. If so it will be moved on layer 6.

The last step is to start the event handler in the StartFunction]
+I Module FvwmEvent FvwmEventTestem

If it doesn’t work check the Conditional Commands and their Conditions.
Perhaps you can test other FvwmEvents

  • Thomas -

Hello Thomas,

Once again thanks for your reply.

I need it to be above other windows. I am aware of EwmhBaseStruts but it does not work for me as it does not prevent windows from hovering over a Fvwmbuttons.

FvwmEvent is an interesting approach, however it is unfortunately poorly documented. I couldn’t find anywhere a description of availbe events. The focus_change event unfortunately works as it should, i.e. when there is a focus change among windows. As you correctly stated there seem to be no “window_maximize” event. It would be very useful.

To summarize the problem is not solved for me and hopefully there is a solution to it.




I succesfully managed to find a solution to this problem.

The meaning of the following events is:

  • FvwmEvent configure_window - occurs when a windows moves or changes size,
  • FvwmEvent change_focus - occurs when a window changes focus, also applies when a new window is created
  • FvwmEvent enter_window - I think this occurs only when a new window is created.

Please correct me if I’m wrong.

So the following code did the trick:

DestroyFunc StartFunction
AddToFunc StartFunction

  • I Module FvwmEvent FvwmEventMax

DestroyModuleConfig FvwmEventMax: *
*FvwmEventMax: configure_window FE-Max
*FvwmEventMax: enter_window FE-Max

DestroyFunc FE-Max
AddToFunc FE-Max

  • I ThisWindow (Maximized, !HasHandles, CurrentPage, Visible, Layer 4) Layer 0 6
  • I ThisWindow (HasHandles, Layer 6) Layer 0 4[/code]

Thanks for the help and for a great Window Manager!!!