First question: How can I change the Focus using Buttons? (Preferably only windows on the current page)
Second question: I have a titlebar with Style StaysOnTop. Normaly I don’t want any window to overlay that bar. But it’s quite annoying when I want to play fullscreen in wine or look at pictures with gqview. How can I tell the titlebar to allow certain applications to overlay it.
Regarding the staysontop question: you could use layers instead.
Can you be more specific? You can bind an action to a button such that it invokes something like:
DestroyFunc FocusSomeWindow
AddToFunc FocusSomeWindow
+ I Next (CurrentPage, SomeWindowName) FlipFocusIf I am understanding you correctly you want:
Maximize ewmhiwaAlthough again, you’ll need to be clearer about what it is you’re after.
– Thomas Adam
I want to switch through all the windows that are currently on the Page using my Scrollwheel on a certain Button I defined, forward and backward.
For example: I have Firefox, Gaim and X-Chat on Page one and 3 Terminals on Page 2. When I use the scrollwheel on the button on page 1 the focus swithces through Firefox, Gaim and X-Chat. When I’m through all windows on the page the focus flips back to the first window on that Page, and the other way round if i move the scrollwheel in the other direction.
The same sould be true with the 3 Terminals on Page 2.
The other problem is: When I’m playing Warcraft 3 or Far Cry with wine in Fullscreen mode I still see that bar at the top of the screen. That is a bit annoying
I hope that was clear enough, if not I could post some screenshots.
OK – you probably want something like this then (note that I hardly ever test any of the functions I post here, so YMMV. :P):
Let’s assume your button config looks like this:
*FvwmButtons: (12x12, ...., Action (Mouse 4) 'Function ScrollThroughWindows 4', Action (Mouse 5) 'Function ScrollThroughWindows 5')This will call both functions passing the mouse button number as a parameter to the function in which case you might define the function as:
DestroyFunc ScrollThroughWindows
AddToFunc ScrollThroughWindows
+ I PipeRead `[ $0 -eq 4 ] && echo "Prev (CurrentPage, AcceptsFocus) Focus" || echo "Next (CurrentPage, AcceptsFocus) Focus"`I’m deliberately using ‘Focus’ here since that won’t affect the window ring. FlipFocus would have places the focused window at the start which would have tainted the results going in the other direction.
You’re going to have to take a screenshot – I have no idea what this “bar” is you speak of.
HTH,
– Thomas Adam
Your Function works like a charme, if it now also would Raise the Focused window it would be perfect 
And now the Screenshots
Here is my desktop as it looks normaly
And here I am using gqview in fullscreen mode (wine would look the same)
That “bar” at the top of the screen should have been overlayed by gqview in that case (xine in fact does this. I don’t see that bar in xine fullscreen videos)
How can I tell certain programms to overlay that bar?
Then change the command “Focus” to the name of a function, say “FocusAndRaise”, such that:
DestroyFunc FocusAndRaise
AddToFunc FocusAndRaise
+ I Focus
+ I RaiseSee the EWMHMaximizeIgnoreWorkingArea style option – assuming you’re using EWMHBaseStruts.
– Thomas Adam
Thank you, the first problem is perfectly solved now.
I have already added EWMHMaximizeIgnoreWorkingArea to the gqview Style and it does not help at all. It just maximizes under the bar, the bar is still visible over the window. Actualy the picture of that mess you can see on the second screenshot is not complete. The bar overlays the first 24 pixles at the top. The Problem is not the working area but that the Bar has StaysOnTop as an option defined. Normally I don’t want any window to be over the bar. Just a few handpicked ones. Like wine and gqview.
Then for those windows that you do wish to raise over the bar assign them a ridiculously high layer. You have two ways you can do this:
Style some_app Layer 10or:
I suspect you want option 2 in the specific circumstance that you’re only going to want to apply it to a maximised window (I’m assuming). Again, and in that case, you have some options open to you.
I would go with using FvwmEvent to keep a track of such windows as in the following:
DestroyModuleConfig FE:*
*FE: Cmd Function
*FE: configure_window SomeFunction
Module FvwmEvent FE
DestroyFunc SomeFunction
AddToFunc SomeFunction
+ I ThisWindow(!"SomeApp|SomeOtherApp", !Maximized) Break
+ I Layer 0 10
+ I Raise
+ I Maximize What the above is doing is asking FvwmEvent to listen out on the configure_window event (actually in strict Xlib parlance that’s ConfigureNotify). Window receive this event for all sorts of reasons, and as such, tracking that event does induce a high network tolerance, but it’s about the only reliable way I can think of to ensure that when you maximize these few windows you get the results you want.
The calling function does a few things. The first line looks at the operand window (the one you’re maximising, say) and says something like this:
“If the window I’m looking at is not called SomeApp or SomeOtherApp AND it’s not maximised, then quit running this function.”
Hence in this way, you can add the program names for those windows you do want to track there – since anything else will be discarded.
The other lines then put the correct window into a high layer (layer 10 will be above anything most apps are placed in – ensuring it’s very much on top of anything else) and then the window is raised before being maximised.
That’s all there is to it.
Now, you could have forgotten about FvwmEvent entirely, but the problem I can see here is that it’s not likely to always be the case that you’re going to start these applications you want raised over your bar in a maximized state each time. So using pure functions to do this is inefficient. Not to mention of course the addage that controlling the execution of the said programs in order for those functions to work would have to result from the programs being started by those functions.
HTH,
– Thomas Adam
Style blah Layer 10 is just fine for all the games. But with gqview it is generating an even greater mess that before. I cannot describe it tough because you wouldn’t understand any word of what i’d be saying I will go to sleep now and post some screenshots tomorrow.
I will just let the picture speak for itself
This is what happens if I switch to fullscreen viewing (this is NOT maximizing, but just pressing f).
OK, I see what’s happening. Aside from there being a lot of EWMH XAtoms most likely not supported by FVWM yet – one of the big things that GQView does when you press ‘f’ is that it’s not the window you’re looking at which gets fullscreened but rather a different window.
Using xprop on this, I note the WM_CLASS XAtom is set to the following:
“GQview”, “fullscreen”
The former name is the Class name and hence you could use:
Style GQview Layer 10… for instance. Although this has an issue in that it’s going to apply to ALL GQview windows (most likely) which has the class name set. This may or may not be what you want, I can’t say (the choice is yours. :P) If it isn’t – and you just want the style to apply to the fullscreened instance of gqview, then use its resource name:
Style fullscreen Layer 10For instance.
HTH,
– Thomas Adam
While this works very well, using PipeRead is not the best thing todo. I recommend the following instead:
button config
*FvwmButtons: (12x12, ...., Action (Mouse 4) 'Function ScrollThroughWindows Prev', Action (Mouse 5) 'Function ScrollThroughWindows Next')with the function
DestroyFunc ScrollThroughWindows
AddToFunc ScrollThroughWindows
+ I $0 (CurrentPage, AcceptsFocus) Focuswell it defenitly looks more simple and since it works as well i will stick to this because it is more likely that i can reproduce something like this in the future without having to bother you people