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?
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.
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
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.
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.
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
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’.
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;
fi;’
[/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
[/code]
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.
