Revert avoidStruts Caching

[pjones]

When we released v0.12 it included a bug caused by the new avoidStruts caching code. This is still a problem even though several commits were made in PR #30. (One example: creating a new dynamic workspace and then opening a window will obscure any task bars.)

@geekosaur has suggested that we pull all code related to caching into a separate branch and then revert all these changes out of master. (He also recommends the same for the _NET_WORKAREA changes.)

This issue is for us to discuss a solution before releasing v0.13. Please let us know what you think and if you'd be willing to help.

/cc @byorgey @aavogt @f1u77y

[thomasf]

As a user I prefer to deal with workarounds rather than losing the cache
performance gains.

Inserting a few docksStartupHook calls in my config resolved all the issues I
had with the cache. I have also removed the setWorkarea in AvoidStruts (in my
own xm-contrib fork) to resolve my multi display qt/chrome menu issues. From
what I understand this causes issues with some applications but doesnt seem to
affect anything for me..

Even if I prefer to muck around a bit to get things working as I want to it's
probably not a default. If it's possible it would maybe be better to include
the cache stuff as an optional thing with a disclaimer about issues.

[geekosaur]

I'm actually thinking along the lines of a different fix that would let us
use something like the older code, but get an even greater speed-up.
Specifically, we would cache window properties and update the cache in the
handleEventHook, avoidStruts would be able to operate via that cache
without making X11 calls itself or needing to enumerate windows; just scan
the cache for the strut properties. This would also provide noticeable
speedups for manageHook and likely at least some EWMH behaviors. The
biggest problem is that any code that looks up properties directly using
X11 bindings would need to be rewritten to use the cache; but in most cases
this would be a net simplification.

On Mon, Nov 14, 2016 at 7:29 PM, Thomas Frössman notifications@github.com
wrote:

As a user I prefer to deal with workarounds rather than losing the cache
performance gains.

Inserting a few dockssStartupHook calls in my config resolved all the
issues I
had with the cache. I have also removed the setWorkarea in AvoidStruts to
resolve my multi display qt/chrome menu issues. From what I understand this
causes issues with some applications but doesnt seem to affect anything for
me..

Even if I prefer to muck around a bit to get things working as I want to
it's
probably not a default. If it's possible it would maybe be better to
include
the cache stuff as an optional thing with it's own disclaimer about issues.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#118 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB8SoAsSd_6V_JZYwLbCKLqDksnwfkedks5q-Pz-gaJpZM4Kx2a0
.

brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[f1u77y]

(One example: creating a new dynamic workspace and then opening a window will obscure any task bars.)

I've just tried doing that, and my status bar did not get obscured. But that behaviour could take place when using xmonad-contrib without #80(messages for cache updating are not sent to the newly created workspace).

(also agreed with @geekosaur about caching all window properties)

[pjones]

@f1u77y: I created an example configuration using ManageDocks and it doesn't seem to have any issues.

It did help me see that XMonad.Config.Desktop uses avoidStruts but not docksEventHook or manageDocks. We need to fix that.

My configuration still has an issue where taffybar is obscured on new workspaces. I'm going to have to try to figure it out. (BTW, I'm on master so I have #80).

[pjones]

Never mind about X.C.Desktop, I see that it already uses the docks function.

[colonelpanic8]

@pjones Have you made any progress on figuring out taffybar issue. I've been seeing the same thing for a while now and was thinking about trying to look in to it.

[pjones]

@IvanMalison I tracked down the issue I was having to a bug in DynamicProjects which I fixed in commit 217abc3.

Based on my testing with xmonad-testing and locally with my build, I don't think avoidStruts is an issue anymore. As such, unless I hear otherwise, I'm going to close this issue.

[colonelpanic8]

@pjones I must have a different issue then, because I am running xmonad-contrib with that commit and it is still occurring for me.

I should clarify that the issue I'm seeing actually occurs when I recompile my config/restart xmonad.

Ah, Looks like I simply wasn't applying the docks startup hook -- nevermind.