Why is there a difference between 'Maximize True' and 'Maximize Fullscreen True' and 'ResizeMove 100 100 0 0'?

Configuration General Questions
1

I have the following minimal config to show the problem I am facing.

EwmhBaseStruts 0 0 0 0
DesktopSize 1x1

Style * MaxWindowSize $[vp.width]p $[vp.height]p
Style * ResizeHintOverride

Key G   A   M   FuncLaunchGeeqie

DestroyFunc FuncLaunchGeeqie
AddToFunc   FuncLaunchGeeqie
+ I None (Geeqie) Exec exec geeqie
+ I TestRc (Match) Wait Geeqie
+ I Next (Geeqie) Focus
+ I Current Raise
+ I Current WindowStyle !Borders, !Handles
#+ I Current Maximize Fullscreen True
#+ I Current Maximize True
+ I Current ResizeMove 100 100 0 0

This function should check to see if Geeqie is running first. If it isn’t, start running Geeqie and wait for it to load. Then grab the ‘Next’ Geeqie window, as it should be the only instance (regardless of it was already running or had to be started). Then focus it, causing the Geeqie window to now be referenced with ‘Current’. Then ‘Raise’ the window, in case it was already running but was hidden under other windows. Then strip all borders and handles and maximize the window.

If I run the command with ‘Maximize True’ or ‘ResizeMove 100 100 0 0’, it loads Geeqie, waits for it, gives it focus, raises and maximizes it with a gap in the lower right corner. Coordinate x is short by 14p and coordinate y is short by 33p.

When you run the ‘Maximize Fullscreen True’, it maximizes Geeqie properly.

The problem is, this is not just for Geeqie, it will be used for other applications like Firefox. With Firefox, ‘Maximize Fullscreen true’, doesn’t maximize the window, but puts it in fullscreen mode (equivalent to F11 in Firefox).

Is ‘Maximize True’ and ‘Resize 100 100 0 0’ broken, am I using them wrong or is this their desired effect?

I’m not sure what I could be doing wrong with such a small configuration. The weird thing is the latter part of the function just focuses, raises and maximizes the application properly. It is just the first run of the command the shorts ‘Maximize’.

Does this mean I will have to run the ‘Maximize/ResizeMove’ command twice when first loading Geeqie?

EDIT: Just tested it and running the ‘Maximize/ResizeMove’ command twice doesn’t fix the problem.

EDIT 2: I just added removing the title along with the handles and border to see what happens. The gap at the bottom, on first load is bigger. So it looks like on first ‘Maximize’ that is thinks the border, handles and title are still active and that’s why there’s a gap? And the second run with the command fixes the gap?

EDIT 3: For some reason, when there is a gap after the initial loading, if you restart fvwm3, the gap disappears without running the function again. I don’t know if this helps anybody.

EDIT 4: Ok, when the gap is there on first load, both $[cw.height] and $[w.height] list the same value and I don’t think they should be, from what I read.

2

Do you have any base struts configured, these give reserved area at the edge of screen for panels. Some panels set this by default too. Maximize and Resize options include an ewmhiwa option that can be used to have them ignore the working area. The working area is a combination of anything set with EwmhBaseStruts and any struts set by running applications.

3

It is literally the config I posted above and nothing more. The first line:

4

I also mentioned that apps themselves can set struts that fvwm honors due to EWMH hints. The only reason Maximize True 100 100 won’t be the full screen is if that is the case, so try Maximize ewmhiwa True 100 100 to ignore any working area set by either fvwm or apps.

5

Makes no difference. The weird thing is, why would the gap disappear after a “Restart”?

6

Some apps like to misbehave and resize/position themselves, because some developers don’t think the window manager should be in charge. Anyways, is it only this app that has this strange behavior?

7

Nope, all programs have this problem. Geeqie was just a simple one to keep testing while it was sorted out. Hence my statement:

When you run the ‘Maximize Fullscreen True’, it maximizes Geeqie properly.

The problem is, this is not just for Geeqie, it will be used for other applications like Firefox. With Firefox, ‘Maximize Fullscreen true’, doesn’t maximize the window, but puts it in fullscreen mode (equivalent to F11 in Firefox).

But yes, other programs have this problem. I also mentioned:

EDIT 4: Ok, when the gap is there on first load, both $[cw.height] and $[w.height] list the same value and I don’t think they should be, from what I read.

Am I correct about this? That when a window has just a title bar, that $[cw.height] and $[w.height] should not be the same value. $[cw.height] should be equal to ‘$[w.height] - title-bar-size’, shouldn’t it be? And you feel this is the programs fault?

This is killing me…

EDIT: This is the updated function for all programs:

DestroyFunc FuncLaunchProgram
AddToFunc   FuncLaunchProgram
+ I None ($0) Exec exec $0
+ I TestRc (Match) Wait $0
+ I Next ($0) Focus
+ I Current WarpToWindow Raise 50 50
+ I Current WindowStyle !Borders, !Handles
+ I Current ResizeMove $[vp.width]p $[vp.height]p 0 0

EDIT 2: I just noticed when I load Firefox with the ‘Maximize Fullscreen True’ and then hit F11 in Firefox to get out of fullscreen mode, it changes the size of Firefox window and shows the gap. The gap appears to be the size of the handles/border. And starting Firefox with the title removed, and then hitting F11 shows a bigger gap (like that of handles/border and title missing).

8

Is it possible for someone to chime in and say if this is my problem or FVWM3’s problem?

Or suggest a better place to receive help regarding FVWM?

9

So nobody knows? Or does nobody want to say?

10

I should probably keep bumping it until someone chimes in, right?

11

I tested your function on Geeqie. It does what it says.

Maximize Fullscreen true
maximize the window, strips all border and handles.
Maximize True
maximize the window, doesn’t strip the border and handles.
Resize 100 100 0 0
maximize the window, doesn’t strip the border and handles. Without the Style, the bottom part goes below the screen equivalent to the height of the title bar.

Fvwm3 version 1.1.2 (1.1.1-2-gefef84cf)

12

The above was tested using my own config. Did another test using the default config.
Maximize True and Resize 100 100 0 0 have gaps at the bottom and right sides. It looks like there is no problem with Geeqie, but it depends on the overall config settings.

13

Ty Ivar, I appreciate your effort to cover for Thomas Adams. I should have realized if Thomas wasn’t responding, saying it was my bad understanding, then it was probably buggy FVWM3 software.

I’ll remember this in the future.

14

I was not aware of Thomas Adams. I am new on this forum… 1 year in 10 days. :slight_smile: I am curious why default config has a 15px gap which is not part of FVWM system but for users to edit and make changes.

15

@pohboyjones, Check latest Fvwm3 update version 1.1.1-11.

16

Fvwm honors lots of different things set by windows, it honors size hints, base struts, and other EWMH specifications. One would need to enable specific styles to avoid this. Though the user in question is disabling the hints, so unsure why a gap is showing. But I have not been able to reproduce this with any software I use and haven’t wanted to check the software in question as to what it is doing. Though if you want some detailed info, please provide the output of xprop from the window so we can see what sort of hints are being set.

One thing I notice about the original configuration is setting a max size along with disabling size hits with ResizeHintOverride – that style will make fvwm ignore any maximum size or resize hints.