maximization possibly broken a bit in recent patches

[Yury]

Hi all,

Only the shortest and plainest messages seem to
be accepted from me by the list. Are you guys
sure there's no blocklists or something? I've
never posted from this address to this list before.
Maybe THIS post comes through eventually. I'm
removing a link to the screenshot, maybe it's that?

I'm having issues with the recent changes in WM.
When switching between different kinds of
maximisation (in my case fullmax, left hand and
right hand) I now sometimes get wrong drawing in
the application window. Not always

This is an example of my desktop after going
from left-half maximization to full maximization
in OpenOffice.
The application works, but everything is still
limited to the left half of the window. And the
geometry is off.

It never did that before I rebuilt with changes
from February and later.
The build is from March 20 sources, the config
is my usual for years, the system is from July 2025.

-Yury

[Yury]

And the screenshot is at the following
obfuscated link, add one point and three slashes
where applicable.

8upload
com
uploaded
b0353699d65ea3b9
37760079.php

-Yury

[Carlos R. Mafra]

Thanks for the report.

Since you said that you never did that before, how can you know that
this OpenOffice behavior is due to recent patches?

Do you get the same behavior with an application other than OpenOffice?

For me, OpenOffice/LibreOffice always had a strange behavior under maximization,
I usually need to close them after a maximization cycle.

I never had problems with other programs though. I suspect your problems
are not related to the recent patches.


>
> -Yury
>
> --
> You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/wmaker-dev/a06c0b95-15c2-4cdd-9001-9dc9abfa2ed0%40mail.grodno.by.

[Yury]

What I meant was I never posted _to that list
from that email_ before, so I don't know maybe I
am in some domain-based blacklist or whatever.
E.g., my posts seem to not be able to go through
if they contain a clear link, while I see other
people posting with links in the list.

***

Now, as for me maybe misinterpreting things.

The OpenOffice build I use is built from sources
on 2024-12-30. Never any trouble of that nature
or similar.
In fact, I've set keyboard shortcuts a long time
ago in WindowMaker for LH- and RH- maximising
specifically for placing OpenOffice instances
side-by-side.

WM built from Git 20231102 checkout is okay
(these sources were up-to-date yet on
2025-08-01). Just reinstalled it and tested it.

WM built from git 20260202 checkout already is
NOT okay.

I couldn't catch other applications with that
sort of misbehaviour but then again I don't have
much of big stuff.
What I can think of is my OpenOffice is built
with Xorg VCL. That I think help to expose the
issue. It MIGHT feel a bit like race condition
but don't take my word for it. Small ones seems
to be okay.


-Yury

[Roman Dobosz]

On Thu, 26 Mar 2026 15:53:58 +0300
"'Yury' via Window Maker Development" <wmake...@googlegroups.com> wrote:

> Now, as for me maybe misinterpreting things.
>
> The OpenOffice build I use is built from sources
> on 2024-12-30. Never any trouble of that nature
> or similar.
> In fact, I've set keyboard shortcuts a long time
> ago in WindowMaker for LH- and RH- maximising
> specifically for placing OpenOffice instances
> side-by-side.
>
> WM built from Git 20231102 checkout is okay
> (these sources were up-to-date yet on
> 2025-08-01). Just reinstalled it and tested it.
>
> WM built from git 20260202 checkout already is
> NOT okay.
>
> I couldn't catch other applications with that
> sort of misbehaviour but then again I don't have
> much of big stuff.
> What I can think of is my OpenOffice is built
> with Xorg VCL. That I think help to expose the
> issue. It MIGHT feel a bit like race condition
> but don't take my word for it. Small ones seems
> to be okay.

Perhaps you could bisect which particular commit has spoiled OO for
you. I'm not using OO and I didn't bump on such behaviour on different
apps, while running wmaker compiled with the latest commit right now.

--
-^- _ enjoying the silence
_ /O)_\//
(_(|__(_(_) grf.

[david.m...@gmail.com]

Not sure if it would be easier for you, but alternatively you can open an issue (and attach your screenshots) at https://github.com/window-maker/wmaker/issues 

[Yury]

It was commit
c82e6dad5cd2b9813f5df982fe9710429c24e81e
put in on 'Fri Jan 23 23:38:32 2026 -0500'
that broke things.

Its predecessor is okay:
95c68fe26d53f8ebddd046f4c1e3995f24477fa9
Author: David Maciejak <david.m...@gmail.com>
Date: Fri Jan 23 23:10:08 2026 -0500

[david.m...@gmail.com]

Indeed, that's weird. That patch is not supposed to modify anything on the maximization behavior side.

Can you explain step by step how we can reproduce the issue ?

Like what commands are you running to launch openoffice, I guess you are running it twice to get 2 instances ?

Then, from the window menu, if you re choosing maximization left half for one and right half for the other, what's the result ?

Are you experiencing that issue every time ? 

[Yury]

I have Apache OpenOffice (AOO) built with Xorg VCL.
I don't see that behaviour in LibreOffice built
with GTK (but then it's perceptibly sluggish,
see below why it matters). And I have nothing
else big/biggish readily available and built
with Xorg visual libs.

I start one instance of AOO (no need to open
files) and switch it between various
maximisation modes. It's easy to see when it
misbehaves - the navigation panel in the center
of the app's window stops recentering or window
stops redrawing.

So there MIGHT exist two code execution paths
that get broken I suppose. Not a developer, me,
though.

It doesn't matter if the switching is done with
mouse menu clicks or keyboard. I have long ago
defined keyboard shortcuts for fullmax, LH-max
and RH-max - M1+F10, M1+F11, M1+F12.

The behaviour can break on the very start of
AOO, if WM was remembering AOO's window being
set to half-screen.
But usually the broken behaviour is achievable
on at least the first maximisation mode change,
and sometimes it starts on the second or third
max mode change (I don't think I remember it
getting up later than that).

Could it be dependent on timings/race conditions
just a little?

P.S. Doing mode changes quickly does not cause
misbehaviour in the well-behaving snapshot of WM.

On 28/03/2026 00:35, david.m...@gmail.com wrote:
> On Friday, 27 March 2026 at 10:40:51 UTC-4 Yury wrote:
> It was commit
> c82e6dad5cd2b9813f5df982fe9710429c24e81e
> put in on 'Fri Jan 23 23:38:32 2026 -0500'
> that broke things.

[Yury]

On 28/03/2026 00:35, david.m...@gmail.com wrote:

> Indeed, that's weird. That patch is not supposed to modify anything on the
> maximization behavior side.

I've looked into the related diff, and it's a
160K beast. And there is some stuff inside which
LOOKS to my noob's eye as if it COULD affect
geometry calculations.

There are
* `get_corner` changes
* `getSize` changes
* _NET_WM* support changes

I have no idea, of course, whether those are
really relevant. Only I'm sure that in its
entirety the diff breaks maximisation for me.

-Yury

[david.m...@gmail.com]

I downloaded latest openoffice and I believe was able to reproduce the issue (which appears to be new to me) where seems like the inner frame was not refreshing properly when the window is maximized  with the maximization menu (that issue does not appear when using the resizebar for resizing).

Please try the patch enclosed on top of the latest git code.

[Yury]

Hi,

The patch seems to works, thank you very much!

[david.m...@gmail.com]

On Sunday, 29 March 2026 at 01:06:28 UTC-4 Yury wrote:

Hi,

The patch seems to works, thank you very much!

That's great, thank you for your report.