Closed Pachin0 closed 2 years ago
There was a spot where I forgot to change <+> to <>. Ill fix that with next commit if this is desired.
[ Haven't looked too deeply yet ]
Part of what makes this so much bigger than the other functions is the sorting part since I don't know how to use the sort' that is already on the log hook of EwmhDesktops since it works with workspace sorting and I needed to sort tuples with workspaces.
Also the sorting that I put in does not follow the X WorkspaceSort that is provided by the user since you'd have to now ask for instead of a workspace sort, a more general X WorkspaceCompare, which then gets ran though the mkWsSort and mkViewPortSort to both use the same comparison. But that is a question I'd rather ask first. Generally this is more code than what the other ewmh stuff takes to add.
Seems to me, since you're ignoring the Position
s anyways and only sort on the WorkspaceId
, that you can make it work with the normal workspaceSort
. In mkViewPorts
you have the WindowSet
so you can certainly extract a list of WindowSpace
s (your vWs
and hWs
are already screens, so you'd just have to call workspace on them) and sort that with the users preferred sorting function before adding positions and the like.
The problem with sorting the workspaces first and then adding the position is that to add the positions I have to find the tag of the visible workspaces and then add the position. It is much more convenient to create the list of tuples with the respective positions, sort by the tags and then just discard the workspace id's. The solution to doing it the way you suggested would be by doing a Map and then just updating the keys, although I feel it is much more resource intensive than just the simple list and sort.
Well, you could also, instead of having a list of WorkspaceId
s, just have a list of WindowSpace
s and keep the current order of adding positions and sorting
Small detail. The reason why I didn't go all the way and just used the [WindowSpace] instead of the [WorkspaceId] is because WindowSpace is not a member of Ord and M.fromList wants it to have Ord. Probably the same after compilation. Don't know how Ord would be implemented for WindowSpace
This looks great. If you want go ahead.
Thanks!
Description
My implementation of _NET_DESKTOP_VIEWPORT. I don't know how spaghetti it may be since I am not a seasoned haskeller. Part of what makes this so much bigger than the other functions is the sorting part since I don't know how to use the sort' that is already on the log hook of EwmhDesktops since it works with workspace sorting and I needed to sort tuples with workspaces.
Also the sorting that I put in does not follow the X WorkspaceSort that is provided by the user since you'd have to now ask for instead of a workspace sort, a more general X WorkspaceCompare, which then gets ran though the mkWsSort and mkViewPortSort to both use the same comparison. But that is a question I'd rather ask first. Generally this is more code than what the other ewmh stuff takes to add.
Test this out with polybar, specifically with this commit.
https://github.com/polybar/polybar/commit/bc9dda266f57f7ae3a2300a9418d94c3fe62c466
Checklist
[X] I've read CONTRIBUTING.md
[] I've considered how to best test these changes (property, unit, manually, ...) and concluded: XXX
[] I updated the
CHANGES.md
file (Ill do this if this even goes through)