search

pop-os / cosmic-osd

GNU General Public License v3.0
28 stars 27 forks source link

Autohide dock space not considered #26

Open WatchMkr opened 7 months ago

WatchMkr commented 7 months ago

To reproduce:

I think the best solution is to add space if the dock is present rather than always adding space as thought it's there. Same bug applies to the Launcher and App Library. I'll create additional issues.

ryanabx commented 6 months ago

Is there a way for clients to see what space an autohide dock would take up if it were open? I know it all uses layer-shell exclusive zones (correct me if I'm wrong) and the autohide dock probably doesn't have an exclusive zone.

Slightly tangential but related issue: https://github.com/pop-os/cosmic-panel/issues/158

wash2 commented 5 months ago

Is there a way for clients to see what space an autohide dock would take up if it were open?

Yes, but it involves reading the panel config to check which size it is configured as, and it still needs to know if the panel is hidden or not. I'm thinking that the panel and dock could update a state file with their effective height after completing a transition to hidden or visible on the bottom edge. Alternatively, I guess the panel could expose its effective height on the bottom edge as a property on dbus.

ryanabx commented 5 months ago

Alternatively, I guess the panel could expose its effective height on the bottom edge as a property on dbus.

I like this better, because I think there could additionally be a dbus method to show/hide an auto hide panel that's currently hidden

Drakulix commented 5 months ago

@wash2 how does this error manifest technically with wlr-layer-shell?

I would expect the OSDs to use the bottom edge as an anchor and set a margin, is that the case?

I guess the issue is, that the auto-hiding dock isn't setting an exclusive-zone, even if it is visible? We could change that, but it might cause some janky animations with new tiled windows, before the dock has hidden itself, I guess?

wash2 commented 5 months ago

@wash2 how does this error manifest technically with wlr-layer-shell?

I would expect the OSDs to use the bottom edge as an anchor and set a margin, is that the case?

I guess the issue is, that the auto-hiding dock isn't setting an exclusive-zone, even if it is visible? We could change that, but it might cause some janky animations with new tiled windows, before the dock has hidden itself, I guess?

Ya, exactly. I remember we decided against exclusive zones for auto-hide panels because of how it would force tiled windows to resize.

Drakulix commented 5 months ago

@wash2 how does this error manifest technically with wlr-layer-shell? I would expect the OSDs to use the bottom edge as an anchor and set a margin, is that the case? I guess the issue is, that the auto-hiding dock isn't setting an exclusive-zone, even if it is visible? We could change that, but it might cause some janky animations with new tiled windows, before the dock has hidden itself, I guess?

Ya, exactly. I remember we decided against exclusive zones for auto-hide panels because of how it would force tiled windows to resize.

So we kinda need an exclusive + an "occupied" zone? That would be something to bring up in the ext-layer-shell discussion.

We might be able to fix that today in the compositor though, if we take the surface size into account for placement instead of just zones (assuming the dock changes the surface size between being visible and non-visible).

I wonder if that might mess with some of our other clients though (thinking of notifications), as ideally this behaviour would be opt-in for surfaces (like the dock).

I really would like to fix that in the compositor, but I guess at that point a dbus-interface isn't any worse, than a private protocol extension. Both can reasonably be implemented by other compositors/panels and we can make them optional (and default to assuming 0, if they are not available).

Long-term we could maybe bring up this use-case for ext-layer-shell.

wash2 commented 5 months ago

Ya, I feel like it could be implemented in the compositor specifically for the OSD and panel using the namespace actually, but I don't know, because that might disappear in a later version.

So we kinda need an exclusive + an "occupied" zone? That would be something to bring up in the ext-layer-shell discussion.

Ya, a setting that allows a surface to be exclusive on a set of specific layers would probably be good for this.

Drakulix commented 5 months ago

Ya, I feel like it could be implemented in the compositor specifically for the OSD and panel using the namespace actually, but I don't know, because that might disappear in a later version.

It will likely be replaced by the app-id though, so we still could special case the panel, if needed. I like the idea to use the namespace for this, but then we have to fix smithay to allow compositors to override LayerMap::arrange (urgh) or otherwise influence how that algorithm works (potentially adding an additional offset to layer-surfaces?).

So we kinda need an exclusive + an "occupied" zone? That would be something to bring up in the ext-layer-shell discussion.

Ya, a setting that allows a surface to be exclusive on a set of specific layers would probably be good for this.

Well the panel can't really know, what clients on what layers should be affected, I think. Other compositors might handle this differently, but I think it would be reasonable for a client to tell the compositor what parts it draws on in addition to the exclusive zone. Something similar to the toplevel geometry of xdg-shell. I think that topic has already come up.