When the view's visibility is "Always visible" and there is a maximized window, the view should remove its margin with the screen edge. Because in that case, the user is wanting to focus on the maximized window, the gap now becomes a wasted space and doesn't look nice.
Screenshot:

I don't think we can easily make assumptions for user preferences. Unfortunately we probably need a new option in order to enable/disable dynamically the screen edge margin. But you also know how difficult it is to accept additions in the configuration pages of they don't look right 🙂

BTW your screenshots shows a shadow error drawing etc
.. Can you please open a bug report, including the Latte layout that produces this and the plasma theme used?

In T12437#215445, @mvourlakos wrote:

I don't think we can easily make assumptions for user preferences. Unfortunately we probably need a new option in order to enable/disable dynamically the screen edge margin. But you also know how difficult it is to accept additions in the configuration pages of they don't look right 🙂

Could we add a new option right below the Screen slider?

              Dynamic Visibility
[x] Disable the gap when having maximized windows

BTW your screenshots shows a shadow error drawing etc
.. Can you please open a bug report, including the Latte layout that produces this and the plasma theme used?

Maybe a bug, but I can't reproduce it now. I will report it when I can.

Add VDG in case someone wants to give their idea.

In T12437#215450, @trmdi wrote:

Could we add a new option right below the Screen slider?

              Dynamic Visibility
[x] Disable the gap when having maximized windows

...or maybe add new modes in Behavior > Visibility, e.g. combine with the Always Visible button. (similar to the new Windows Go Below one)

New Visibility modes could be "Auto Float" and "Always Float" ?

Another thing, could we combine "Auto Hide", "Dodge *" together? Because I think they have a common behavior (auto hide in some conditions).

Finally we have different groups:
1, Alway Visible/Always Float/Auto float (docks always visible in this group)
2, Auto Hide/ Dodge Active/ Dodge *... (docks could hide/show depending on conditions)
3, Windows Can Cover/...

Sorry I don't agree visually grouping any more. I was thinking to group Dodge modes but in that way we end up to break visual balance of the settings. The visibility modes are used too often are too important to narrow their visibility foot print.

In T12437#215503, @mvourlakos wrote:

Sorry I don't agree visually grouping any more. I was thinking to group Dodge modes but in that way we end up to break visual balance of the settings. The visibility modes are used too often are too important to narrow their visibility foot print.

So you would agree with adding the option right below the Screen slider?

A never conclude for adding options before I see the final visual result. You can try to send a screenshot about how it would look.

does not look right and Appearance settings are now out of balance...

how about?

In T12437#215585, @mvourlakos wrote:

how about?

LGTM.

Much cleverer. :)
But is it possible to make it move smoother? Apply some animation for example. Similar to the AutoHide's effect.

In T12437#215614, @trmdi wrote:

Much cleverer. :)
But is it possible to make it move smoother? Apply some animation for example. Similar to the AutoHide's effect.

Too complicated without increasing cpu usage very much... Feel free to apply patches for review.

Can we detect when the maximum effect finnishes? We could try removing the gap after that time?

I can not even remember...

When changing the window's maximized state, there is a glitch with the black region, see the video:

(the video has the animation, but it also happens without it)

I feel like there is a redundant operation here.

In T12437#215712, @trmdi wrote:

When changing the window's maximized state, there is a glitch with the black region, see the video:

(the video has the animation, but it also happens without it)

I feel like there is a redundant operation here.

That points to Qt and X11, if you find any fix or workaround, it would be more than welcome

When watching the video more carefully, I notice this, for example, when you maximize a window, the dock will jump to the bottom of the screen first (1), then it jumps back, and the animation start. I think (1) is redundant and that could be some code in Latte.

In T12437#215727, @trmdi wrote:

When watching the video more carefully, I notice this, for example, when you maximize a window, the dock will jump to the bottom of the screen first (1), then it jumps back, and the animation start. I think (1) is redundant and that could be some code in Latte.

the animation [1] is another thing and the black bar glitch is another [2]...

for [2] is the well known https://bugs.kde.org/show_bug.cgi?id=398257 , I have nothing more to say about this...
for [1] no idea if it can be orchestrated any better... personally I will make one two tweaks and that is all from me playing with screen edge margin... my interests are very limited concerning Floating docks/panels, for my personal workflow I find them just fine already, if anyone wants improvemets I will wait for commits to review.

@zzag

Because you're a KWin master, and I've just seen you commented on the Latte page on KDE Store, I guess you use Latte, so may I ask you to give some insight on the bug @mvourlakos mentioned above as well as the bug I descibed in the video above? (in order to fix/workaround it)

Sorry if I bother you.

It seems that the black region is caused by calling QQuickWindow::resize()
Do you have any suggestion?

Absolutely none, the window has been set to be transparent, Qt should handle the case and not draw any black areas.

@trmdi I tried to animate a bit the screenEdgeMargin for Views that do not behave as plasma panels, meaning that they dont draw their panel shadows externally... You can activate Behavior->Floating->Always use screen gap for user interaction | in order for behaveAsPlasmaPanel to not be activated for floating windows.

https://commits.kde.org/latte-dock/07a10653200613b2dbeeadd67e3c1ebb3a6de914

In T12437#215934, @mvourlakos wrote:

@trmdi I tried to animate a bit the screenEdgeMargin for Views that do not behave as plasma panels, meaning that they dont draw their panel shadows externally... You can activate Behavior->Floating->Always use screen gap for user interaction | in order for behaveAsPlasmaPanel to not be activated for floating windows.

https://commits.kde.org/latte-dock/07a10653200613b2dbeeadd67e3c1ebb3a6de914

Much smoother.
But I'm confused by the option. Isn't that used for the panel case? It sounds a bit unclear in this case.

That option is used from real panels and from an other future case that can be needed. From user point of view the screen gap belongs to Latte at all cases and is not a way to access underneath desktop.

In T12437#215797, @trmdi wrote:

and I've just seen you commented on the Latte page on KDE Store, I guess you use Latte,

Yes, I love it.

so may I ask you to give some insight on the bug @mvourlakos mentioned above as well as the bug I descibed in the video above? (in order to fix/workaround it)

Sorry for the late response. If a client resizes itself, then KWin will render it un-synchronized, i.e. it won't wait until latte-dock finishes rendering. I guess the only way to fix this would be to use extended frame counters [1], but KWin doesn't support it.

If latte-dock doesn't resize itself, then it's most likely an application bug.

[1] https://fishsoup.net/misc/wm-spec-synchronization.html