Open fossfreedom opened 5 years ago
I don't know if there's any way to detect/query where Plank is or how much space it's taking up without looking at it's gschema settings.
If there's no better way, these are probably the settings we'd need:
$ gsettings get net.launchpad.plank.dock.settings:/ position
'bottom'
$ gsettings get net.launchpad.plank.dock.settings:/ icon-size
48
@Jacob-Vlijm has calculated screen working area's for another project we have called window shuffler
https://github.com/UbuntuBudgie/window-shuffler/blob/master/shuffler_geo.py#L101
Basically docks have a concept of "struts" ... plank also does but it's "special"
The link above returns a working area ... obviously this is in python ... and I know nothing more than what I have just written above!
Jacob - what is a strut? ... and how does it get involved with changing a working area?
@aljelly To avoid windows to overlap a panel's space, the panel normally tells the window manager what space and size it claims. To get these values, run xprop -id <window_id>
with the panel's window id. The output shows, a.o. lines like:
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 34, 0, 0, 0, 0, 0, 0, 1679, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 34, 0
showing exactly the size and space the panel claims. This info also includes possible x- and y offset of the monitor it is on. I didn't check yet how desktop folders behaves on a multimonitor setup, but at least these strut values are not taken into account at the moment, looking at the overlap.
This stuff gets more complicated on Plank however, since it does not return these values in the correct way, especially when on the right and/or multi monitor. See this one: https://bugs.launchpad.net/plank/+bug/1755731
Other relevant reference might be our window shuffler, where we had to deal with these values on window placement, and also fix Plank's bug: https://github.com/UbuntuBudgie/window-shuffler
Just tried it. It might be worth noting that when dock hiding is enabled Plank returns:
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 0
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
So icons would be behind the panel when any sort of hiding is enabled. On elementary at least this may not be too much of a concern as Plank is always at the bottom center.
When off it returns more expected values:
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 55
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 55, 0, 0, 0, 0, 0, 0, 0, 1919
That would be expected - plank is popping out to say hello - so no need to worry about the overlap with the icons - when plank says goodbye - everything looks ok. On Tue, 4 Dec 2018 at 14:36, aljelly notifications@github.com wrote:
Just tried it. It might be worth noting that when dock hiding is enabled Plank returns:
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
So icons would be behind the panel when any sort of hiding is enabled. On elementary at least this may not be too much of a concern as Plank is always at the bottom center.
When off it returns more expected values:
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 55 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 55, 0, 0, 0, 0, 0, 0, 0, 1919
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
The problem is that Plank has modes where it only hides when a window is overlapping it, otherwise it stays out. It reports all 0
s for the STRUT
variables for any hiding mode. In these modes that would mean that Plank would be showing over the icons as long as there's no windows in the way of it. Don't know how many people would use the hiding modes and have Plank on the left or top, but probably someone will.
hmm - sounds like there isnt much we can do unless we add some-sort of "border" size setting in DesktopFolder where icons cannot be placed.
On Tue, 4 Dec 2018 at 15:06, aljelly notifications@github.com<mailto:notifications@github.com> wrote:
The problem is that Plank has modes where it only hides when a window is overlapping it, otherwise it stays out. It reports all 0s for the STRUT variables for any hiding mode. In these modes that would mean that Plank would be showing over the icons as long as there's no windows in the way of it. Don't know how many people would use the hiding modes and have Plank on the left or top, but probably someone will.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/spheras/desktopfolder/issues/211#issuecomment-444132639, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA8zkKBn7wIrAmfkGohy7oRuLosWkeHVks5u1o-PgaJpZM4Y9par.
regarding the border setting, it will be problematic in the case of multimonitor. Currently the multimonitor is solved with one big panel sized calculating the bounding box of all monitors. Depending on the monitor's configurations (resolutions, main monitor, positions, ...), the border panel is not in the same position as the main monitor border. We would need to add a grid by monitor logic and margins for the grids to solve all the possible situations.
Same issue with unity launcher. Icons are appearing under launcher. But it can be solved for unity as other desktops (ex: caja-desktop) works perfectly with unity and calculate the working area well regardless of the state of the launcher. Not sure if plank problem is still valid unity launcher.
I did some improvements to avoid problems with left/top docks (plank, and so). In case of multimonitor, right and bottom positions are problematics, but I will try to take into account also (hope left/top are the most important)
Feedback from the UB Community: