Windows are positioned behind Dash when Dash-to-dock is enabled in Activities Overview [screenshots included]

[ghost]

BEHAVIOR When you go into Activities Overview, the Windows on the left-side are overlapping the dash -- they're positioned behind it. When dash-to-dock is disabled, the windows don't show up behind the dash in Overview.

(Screenshot of windows on the left overlapping behind the dash.)

EXPECTED BEHAVIOR For the windows to not overlap or be behind the Dash. (Screenshot of window positions in activities overview with dash-to-dock disabled.)

BUG DISCOVERED USING Ubuntu (GNOME) 17.04 x64 GNOME 3.24.1 desktop environment Linux kernel 4.10.0-22-generic Dash-to-dock version 59

[micheleg]

Hi. From the screenshot it seems you are also running workspace to dock. Does the problem occurs also disabling that extension? Also, did the problem appear after an extension upgrade?

[ghost]

Hi micheleg. After disabling Workspaces to Dock, the issue disappeared: the windows positioned themselves normally and weren't underlapping the dash/dock on the left.

I'm honestly not certain if it was before or after an extension upgrade, sorry.

[micheleg]

@passingthru67: do you have any suggestion on this?

[franglais125]

@micheleg I've seen this issue many times when working on the multi-monitor code. The problem is the dashSpacer gets created for every dock instance, but the workspace code upstream doesn't use its geometry to properly calculate the space for the window spread except if in the primary screen). Here is the relevant code upstream: https://github.com/GNOME/gnome-shell/blob/033277b68f2910e54ce62f45fa92af2f5092a7ba/js/ui/workspacesView.js#L658

I tried to tackle this, but honestly just ran out of time. I'm leaving my work in this brancg in case somebody else wants to try and fix this: https://github.com/franglais125/dash-to-dock/tree/multimon_dash_spacer

The best part is that I managed to identify the part of the code that needs some tweaking. It "works", as in it almost solves the issue, but needs some polishing:

• I basically just forced a new injection, maybe there is a better way of doing it.
• For some reason, after injection, the fix does not apply immediately. It always takes me 3 opening/closing the overview before the geometry is recalculated.
• Code style and structure to be improved for sure.

Cheers

[passingthru67]

@franglais125: I believe the original issue stemmed from worskpaces-to-dock. To give some background, the only way to properly set the geometry of the overview workspace to accommodate larger thumbnails or multiple docks is to override it. This is essentially what I do in workspaces-to-dock. The original issue described arose when the multi-monitor option was introduced into dash-to-dock. I was no longer able to determine the width of dash-to-dock's dock element. A later version of workspaces-to-dock provided a fix for this that takes into account the presence of dash-to-dock on multiple monitors.

If dash-to-dock will be providing some type of functionality for adjusting the overview geometry, my concern is that there will be conflicting code, as both docks try to override the same geometry function. If possible, we need to find a solution that works for both docks.

[franglais125]

@passingthru67 Sorry, I posted in the wrong issue. I didn't realize this was specifically about d-t-d + workspaces-t-d. My wip branch, and comments above were intended for this issue: https://github.com/micheleg/dash-to-dock/issues/410.

But your comment now gives me more food for thought. In any case, the problem is that even without worksaces-to-dock enabled (like me) #410 is still a bug that affects d-t-d.

I just checked a few things in your extension, and I noticed that you are also injecting _updateWorkspacesActualGeometry. After injecting, how do you make the overview 'update' its geometry right away? I always have to wait for it to update at some point with the injected function, instead I'd like to do it manually.

[franglais125]

A later version of workspaces-to-dock provided a fix for this that takes into account the presence of dash-to-dock on multiple monitors.

This means this issue is then "fixed", or at least outdated? As it was fixed in w-t-d...

[passingthru67]

Yes, this issue is resolved.

As for the updating the work area geometry, I believe the Layout.LayoutManager._updateRegions function is responsible for that. I override this function to refresh the thumbnails when there's a change in the work area. But, _updateRegions doesn't get called directly. It's actually the Main.layoutManager._queueUpdateRegions function that gets called by the dock.

[passingthru67]

BTW, something else you may want to consider is the workspacesViews.setActualGeometry function. WorkspacesView.WorkspacesDisplay._updateWorkspacesActualGeometry calls this function to set & sync the workspace geometry. If I recall correctly, I had to inject my own code to keep from having to re-initialize the Main.overview.viewSelector._workspacesDisplay element which is indirectly bound to it. Anyway, I'm speaking off the top of my head. I'd have to dig through the code again to provide more detail.

[franglais125]

Thanks for your feedback! Very appreciated. Looking into it :)