[vjr]

Fixes #2560

Depends on (blocked by) elementary/wingpanel#725
Depends on (blocked by) elementary/dock#613

• Windows are centered based on monitor/screen dimensions.
• The wingpanel height and dock height are different, dock being thicker than wingpanel.
• This makes the centered windows appear positioned closer to the dock and farther away from the panel.
• This proposes to shift centered windows closer towards the wingpanel so that the gaps look even.
• This does not affect user repositioned windows whos coordinates are stored in sqlite db for later restoration.

[leolost2605]

Hmm I agree with what @lenemter said in #2560 (comment) that if the dock is set to auto hide IMO we shouldn't take it into consideration when centering windows. And if it isn't set to autohide it's already taken into consideration automatically...

[vjr]

Hmm I agree with what @lenemter said in #2560 (comment) that if the dock is set to auto hide IMO we shouldn't take it into consideration when centering windows. And if it isn't set to autohide it's already taken into consideration automatically...

OK I see I can add a condition to actually shift the new centered window downwards instead of upwards if the Dock is hidden so that the centering appears more evenly spaced.

What do you mean it's already taken into consideration? Currently windows are centered based on monitor/screen geometry/dimensions and they look a bit "off center" which is the whole point of the issue and these PRs. Something I'm missing here?

In the mean time I'll address the review from @danirabbit to use dbus instead of glib.settings and add the check for dock visible or not.

[leolost2605]

What do you mean it's already taken into consideration? Currently windows are centered based on monitor/screen geometry/dimensions and they look a bit "off center" which is the whole point of the issue and these PRs. Something I'm missing here?

Windows are centered based on the workarea of a monitor and not the actual monitor dimensions. The workarea is the area of the monitor that is not covered by struts. Struts are the areas that e.g. the wingpanel requests where it is exclusive. Basically the workarea is the area a maximized window covers. Now what I meant is that if you set the dock hide mode to never it will also add a strut at the bottom so that no maximized window occludes the dock. In this configuration windows take the dock automatically into consideration when being placed and they will be placed further up.

[leolost2605]

In the mean time I'll address the review from @danirabbit to use dbus instead of glib.settings and add the check for dock visible or not.

I wouldn't use IPC at all, you can get the size of the windows in gala directly. However let's maybe wait for some input from @elementary/ux because like I said IMO if the dock has the ability to hide it shouldn't be taken into consideration when placing windows.

[vjr]

What do you mean it's already taken into consideration? Currently windows are centered based on monitor/screen geometry/dimensions and they look a bit "off center" which is the whole point of the issue and these PRs. Something I'm missing here?

Windows are centered based on the workarea of a monitor and not the actual monitor dimensions. The workarea is the area of the monitor that is not covered by struts. Struts are the areas that e.g. the wingpanel requests where it is exclusive. Basically the workarea is the area a maximized window covers. Now what I meant is that if you set the dock hide mode to never it will also add a strut at the bottom so that no maximized window occludes the dock. In this configuration windows take the dock automatically into consideration when being placed and they will be placed further up.

OMG I think I see what you mean. I'm unfamiliar with the workarea/struts terminology but looks like it (only if dock is set to never hide) is working as expected.

Now, if the dock is set to one of the autohide options, it looks like the strut(s) are not added? So the issue again shows up, new centered windows again appear too close to the dock UNLESS its size is large enough to trigger the dock hide OR it's already hidden due to option "hide when any window overlaps it".

So, if I'm explaining and thinking clearly, is it worth me trying to dynamically add/remove strut(s) based on whether the dock is currently (before the animation) in a hidden state?

Some place in the code to add+update the strut AFTER a new app window is opened BUT BEFORE it is centered so that it's automatically placed at a lower or higher position?

Might be too messy to even attempt.

[vjr]

@leolost2605 @lenemter @danirabbit

It appears the default/current window centering/positioning looks good (works as expected) only if the dock autohide is set to NEVER or ALWAYS? If the autohide is one of the other modes (some window focus option) then the issue manifests - meaning the window appears closer to the dock than the wingpanel.

I was trying to read the gala code after Leo/Leonhard mentioned something about struts and mutter centering windows based on them so thought to try to get gala to update struts for the dock even if the autohide mode is not set to ALWAYS or NEVER and also delay/defer the window "on_map" so that the dock animates (hides or reveals) before the window maps/positions so that it addresses any of the focus based autohide modes.

If I'm explaining clearly, is this a feasible approach, seems like only a few lines of code to change but I'm unable to nail it at the moment - do any of you have any pointers to how/where I can do this change?

The wingpanel is not showing up, apparently even without any of my changes in the current updated os9 daily so that's another hiccup (temporary?) for me to check whether my changes are working.

Thanks.