Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X.H.ManageDocks: Init strut cache on demand if necessary #406

Merged
merged 1 commit into from Jan 24, 2021

Conversation

liskin
Copy link
Member

@liskin liskin commented Nov 17, 2020

Description

This makes docksStartupHook unnecessary. That is desirable because we
didn't add a changelog entry about it being necessary, and 4 years after
its introduction we still have users grabbing old configs and reporting
(xmonad/xmonad#21 (comment)) that
ManageDocks doesn't work properly.

I would love to finally settle this.

More context

Full story follows:

xmonad-contrib 0.12 introduced (00be056, merged in April 2013)
caching to ManageDocks to avoid queryTree calls on every runLayout,
which brought in several bugs. Attempts to fix these bugs in
xmonad-contrib 0.13 introduced (28e9f8b, merged in February 2016) a
breaking change in ManageDocks that required users to add
docksStartupHook (or docks, after e38fb3b got merged in November
2016) to their configs for avoidStruts to still work after xmonad
restart. Unfortunately this was never mentioned in the changelog nor in
any compilation warning (which get discarded by xmonad --recompile
anyway !!!), so as of March 2020 we still have users being bitten by
this.

Back in September 2016 in a discussion about other bugs introduced in
28e9f8b I suggested that we use Maybe to indicate whether the cache
had been initialized and initialize it on demand when it had not.
Unfortunately I wasn't sufficiently clear about what I meant and Brandon
was going through some health issues, so we just got into a heated
argument and ended up merging a suboptimal solution. :-(

And since we're still getting complaints from users every now and
then, I believe it's worth dealing with even after all these years.
If nothing else, let this serve as a reminder that breaking users'
configs without any warning is wrong.

(Oh and we should probably stop hiding xmonad.hs compilation warnings,
otherwise we can't ever hope to provide smooth deprecation and upgrade
paths.)

Fixes: 00be056 ("Cache results from calcGap in ManageDocks")
Fixes: 28e9f8b ("add docksStartupHook for handling docks when restarted")
Fixes: e38fb3b ("Make usage of ManageDocks simpler and more robust")
Related: #118
Related: #30
Related: #80
Related: xmonad/xmonad#21

Checklist

  • I've read CONTRIBUTING.md

  • I tested my changes with xmonad-testing

  • I updated the CHANGES.md file

  • (n/a) I updated the XMonad.Doc.Extending file (if appropriate)

@liskin
Copy link
Member Author

liskin commented Nov 17, 2020

@geekosaur We had a heated argument about this in 2016 so I thought I'd just show you the code instead. I still believe this is a good solution and I still don't understand what your objections were. Users are still getting bitten by this, because they're still using configs with just a docksEventHook and no docksStartupHook. And I still think the cache can be completely transparent.

Would you mind taking a look one last time?

This makes docksStartupHook unnecessary. That is desirable because we
didn't add a changelog entry about it being necessary, and 4 years after
its introduction we still have users grabbing old configs and reporting
(xmonad/xmonad#21 (comment)) that
ManageDocks doesn't work properly.

I would love to finally settle this.

Full story follows:

xmonad-contrib 0.12 introduced (00be056, merged in April 2013)
caching to ManageDocks to avoid queryTree calls on every runLayout,
which brought in several bugs. Attempts to fix these bugs in
xmonad-contrib 0.13 introduced (28e9f8b, merged in February 2016) a
breaking change in ManageDocks that required users to add
docksStartupHook (or docks, after e38fb3b got merged in November
2016) to their configs for avoidStruts to still work after xmonad
restart. Unfortunately this was never mentioned in the changelog nor in
any compilation warning (which get discarded by xmonad --recompile
anyway !!!), so as of March 2020 we still have users being bitten by
this.

Back in September 2016 in a discussion about other bugs introduced in
28e9f8b I suggested that we use Maybe to indicate whether the cache
had been initialized and initialize it on demand when it had not.
Unfortunately I wasn't sufficiently clear about what I meant and Brandon
was going through some health issues, so we just got into a heated
argument and ended up merging a suboptimal solution. :-(

And since we're _still_ getting complaints from users every now and
then, I believe it's worth dealing with even after all these years.
If nothing else, let this serve as a reminder that breaking users'
configs without any warning is wrong.

(Oh and we should probably stop hiding xmonad.hs compilation warnings,
otherwise we can't ever hope to provide smooth deprecation and upgrade
paths.)

Fixes: 00be056 ("Cache results from calcGap in ManageDocks")
Fixes: 28e9f8b ("add docksStartupHook for handling docks when restarted")
Fixes: e38fb3b ("Make usage of ManageDocks simpler and more robust")
Related: xmonad#118
Related: xmonad#30
Related: xmonad#80
Related: xmonad/xmonad#21
@liskin
Copy link
Member Author

liskin commented Jan 23, 2021

There were objections to this in the past, but I believe those were due to misunderstanding what I was about to implement, so I don't think they're relevant. Still, I'm setting the merge timer on this one to two weeks, just to be sure. @geekosaur, please take a look, thanks!

@geekosaur
Copy link
Contributor

geekosaur commented Jan 23, 2021 via email

@liskin
Copy link
Member Author

liskin commented Jan 23, 2021

Can you point me at the argument?

#30 (comment) and #30 (comment), but these links don't really work any more (which is especially ironic, as this exact thread is where I mentioned that only using github numbers in commits messages is bad for future references), so here's a screenshot to help you find it:

2021-01-23-174720_746x1078_scrot

I think we also continued the discussion on IRC and somehow still couldn't agree on how many times I'm suggesting to call queryTree. (The answer has always been: once.)

@liskin
Copy link
Member Author

liskin commented Jan 23, 2021

I'm not seeing anything in particular wrong with this implementation aside from some misgivings about doing a potentially expensive XQueryTree in quasi-random places.

Yeah, obviously we need to be careful. But let's not forget the fact that the current implementation is in reality more "quasi-random", as the layout runs at least once before the startupHook: https://github.com/xmonad/xmonad/blob/master/src/XMonad/Main.hs#L252-L263
So this PR possibly removes some flicker as well, for people who don't restart xmobars on xmonad restart.

@liskin liskin merged commit 3e6f0f9 into xmonad:master Jan 24, 2021
@liskin liskin deleted the managedocks-cache-on-demand branch January 24, 2021 15:44
liskin added a commit to liskin/xmonad-contrib that referenced this pull request Mar 23, 2021
This is primarily a cleanup to make it easier to use `setDocksMask` from
the on-demand cache init (see further commits), but it makes the code
nicer:

- the logic to refresh and cache a strut is now concentrated in
  `updateStrut` instead of being spread over `updateStrutCache` and
  `docksEventHook`

- the logic to initialize the cache if not yet initialized is now
  concentrated in `maybeInitStrutCache` instead of being spread over
  `initStrutCache` and `getStrutCache`, so the dual-purpose return type
  of `getStrutCache` is no more

- the logic to detect changes and refresh is now always handled by
  `XS.modifiedM` instead of an additional `||`

Related: xmonad#406
liskin added a commit to liskin/xmonad-contrib that referenced this pull request Mar 23, 2021
This is primarily a cleanup to make it easier to use `setDocksMask` from
the on-demand cache init (see further commits), but it makes the code
nicer:

- the logic to refresh and cache a strut is now concentrated in
  `updateStrut` instead of being spread over `updateStrutCache` and
  `docksEventHook`

- the logic to initialize the cache if not yet initialized is now
  concentrated in `maybeInitStrutCache` instead of being spread over
  `initStrutCache` and `getStrutCache`, so the dual-purpose return type
  of `getStrutCache` is no more

- the logic to detect changes and refresh is now always handled by
  `XS.modifiedM` instead of an additional `||`

Related: xmonad#406
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants