3 Different Scratchpad Implementations; 2 Scratchpad PRs

[colonelpanic8]

IMO, Scratchpads are in a sorry state in xmonad-contrib. For some reason, there are 3 different scratchpad implementations in the library that all use completely different code. There are also 2 outstanding PRs that attempt to extend the functionality of scratchpads that seem to have stagnated and probably will not get merged:

https://github.com/xmonad/xmonad-contrib/pull/169 https://github.com/xmonad/xmonad-contrib/pull/454

All of this indicates a few things to me:

• Scratchpads are a pretty widely used feature (There wouldn't be so much activity around them if that were not the case)
• People have pretty widely varying preferences about how scratchpads should behave (This explains the 3 different implementations as well as the PRs)
• None of the existing scratchpad implementations are very extensible or well thought out (no offense to the authors intended)

I think that what we should do is take a look at all of the different scratchpad implementations/prs and put some careful thought into how we might design a single scratchpad implementation that could support all of the behaviors that people seem to want.

The fragmentation that currently exists just makes things confusing for new users, and it makes it difficult for more sophisticated users to make contributions.

[slotThe]

It is true that we have different scratchpad implementation, but I don't think I have ever seen someone use anything but X.U.NamedScratchpads (plus the loggers). I'm sure these people exist, but one implementation clearly "won", more or less. Indeed, so many people seem to be using this that I think our efforts should rather be directed in the direction of improving that module, rather than trying to write yet another implementation. Even if something better comes along, there is a lot of inertia in old modules (not least because there are so many old configurations lying about)

[colonelpanic8]

Indeed, so many people seem to be using this that I think our efforts should rather be directed in the direction of improving that module, rather than trying to write yet another implementation.

Well I agree in the sense that I think it makes sense not to deprecate the module, but I do think an aggresive refactor is order. I believe that it should (mostly) be possible to preserve the existing interface, but implement it in terms of a new interface that is much more flexible (but perhaps exposed in the same module).

There are some issues with the NamedScratchpads implementation. Some examples are:

• It should be possible to control how the dimissal of scratchpads worked. ExclusiveScratchpads uses minimization rather than banishing to NSP. There is clearly a desire in the userbase to have support for this behavior (as indicated by #169). I don't think it would be hard to
• It does not interact well with minimization in general. even if minimization is not the dismissal behavior that is desired, it should not be the case that a minimized scratchpad is considered 'viewed'
• It should be easier to make exclusivity behavior (as implemented in exclusive scratchpads) possible

In general, what I think the implementation needs is to have function hooks to be added in several places, so that the exact behavior of certain parts of the implementation can be controlled more precisely.

[slotThe]

Well I agree in the sense that I think it makes sense not to deprecate the module, but I do think an aggresive refactor is order. I believe that it should (mostly) be possible to preserve the existing interface, but implement it in terms of a new interface that is much more flexible (but perhaps exposed in the same module).

Ah I see; so essentially what we did with the status bars a while ago. In that case I fully support this :+1:

• It should be possible to control how the dimissal of scratchpads worked. ExclusiveScratchpads uses minimization rather than banishing to NSP. There is clearly a desire in the userbase to have support for this behavior (as indicated by Use minimize in scratchpads #169). I don't think it would be hard to

The only reason why #169 seems to have stalled is a weird interaction with status bars (though this sounds solveable) and the fact that we now need to either keep track of the window that used to have focus or find a way for minimization to do this for us. Both of these seem like doable obectives. Do you think it's worth reviving that PR or should we start from scratch here?

In any case, having hot-swappable backends the user can choose sounds like a good thing.

[colonelpanic8]

should we start from scratch here?

Definitely start from scratch. #169 Changed NamedScratchpad to ONLY offer the minimization system. Personally I actually still prefer the NSP approach.

In any case, having hot-swappable backends the user can choose sounds like a good thing.

Right. I think there's an outside chance we can actually implement all 3 scratchpad implementations using the same code if we make it general enough.

[d3adb5]

Making a scratchpad implementation from scratch would likely eliminate concerns with picking one of the existing methods to push a scratchpad window to the background.

In any case, having hot-swappable backends the user can choose sounds like a good thing.

This sounds optimal, if it can be done easily and if there are use cases outside of edge ones. I used to use X.A.Minimize to make the master area into a queue of windows to cycle through. Out of fear #169 would be merged soon and for a couple other reasons I made my own layout + solution to hiding windows in the background. I don't see a new scratchpad implementation easily messing with a setup the same way I thought would happen were #169 to be merged.

Personally I actually still prefer the NSP approach.

Do you mean the NSP workspace? Or are you talking about the proposed X.A.Minimize solution?

The NSP workspace is pretty hacky, and can lead to issues with a multihead setup. I'm all for a centralized solution to scratchpads, but I wonder if they should truly be minimized windows instead of being pushed out of the stack into their own list contained within extensible state. Maybe I have the wrong idea for this, but since I don't use XMonad on top of a DE or task bar programs that detect active and minimized windows I can't tell for sure.

[slotThe]

I will close this for now, as the title of the issue ("3 Different Scratchpad Implementations; 2 Scratchpad PRs") has been dealt with. If we want to discuss the possibility of hot-swappable backends etc., I think it's worth opening another issue for this.