X.H.EwmhDesktops: Add remap argument to the custom log hook

[colonelpanic8]

One might wonder why the additional argument to ewmhDesktopsLogHookCustom that
is added in this pull request is necessary -- it seems that the existing
argument, that allows arbitrary transformations of the workspaces should be
enough to rename the existing workspaces with something like the following:

ewmhWorkspaceNamesLogHook = do
  WorkspaceNames namesMap <- XS.get
  ewmhDesktopsLogHookCustom $ map (addWorkspaceNamesToTag namesMap)

addWorkspaceNamesToTag namesMap ws@W.Workspace { W.tag = currentTag } =
   let currentName = M.findWithDefault "" (W.tag ws) namesMap in
        ws { W.tag = printf "%s: %s" currentTag currentName }

(If you wish to reproduce this error, you may wish to use a simpler function to
change the workspace tag; one that simply appends some character to the end of
the workspace name would do.)

The issue is that when this transformation is applied, the ewmh hooks do not
properly set the current active workspace. The reason for this is that the way
that the way that the current workspace is determined uses the current window
set which has the untransformed versions of the current workspaces
(relevant line is here).

I suspect that there is a more elegant way to handle this issue (perhaps by
using a version of the s (the WindowSet) that has the remapped WindowSpaces? Any
way, I just wanted to put this out there to see what other peoples thoughts
about this are.

[colonelpanic8]

@nomeata you seem to be the maintainer of this module. thoughts? @aavog you seem to have touched this most recently

[nomeata]

It’s been 9 years that I wrote that, and hardly less that touched it. I don’t claim any particular ownership here :-)

I also don’t think I created the generalized hook (what does it do?). So I officially have no opinion here :-)

[colonelpanic8]

@nomeata Ahh yeah, looks like @shepheb Is actually the original author of the custom log hook.

Any thoughts (I'm aware this was 8 years ago).

[f1u77y]

The reason for this is that the way
that the way that the current workspace is determined uses the current window
set which has the untransformed versions of the current workspaces

So, there should be W.tag (head . f $ [W.workspace . W.current $ s]) instead at that line.

[colonelpanic8]

So, there should be W.tag (head . f $ [W.workspace . W.current $ s]) instead at that line.

Yeah, I suppose that works, although it is a bit untidy.

It seems like a big part of the issue is that the custom function is a [WindowSpace] -> [WindowSpace]

Why not simply make it WindowSpace -> WindowSpace, unless someone wanted the ability to filter or otherwise add other windowspaces.

what if, for example, the function removes the current workspace... then the head function in your suggested change would blow up.

[f1u77y]

It seems like a big part of the issue is that the custom function is a [WindowSpace] -> [WindowSpace]

Is could be used for filtering out internal workspaces like "NSP" used for named scratchpads. I've created a discussion(#90) about getting rid of "NSP" which requires many hacks like this for compatibility(and still has some issues like clicking "minimized" scratchpad on a panel brings the NSP workspace).

If repo owners agree with my point about NSP, this and many other hacks will not be required. But as for now I still prefer not changing signature because there already exists a function for changing [WindowSpace] in arguments

[geekosaur]

Am I to understand that EWMH is now the only acceptable way to do anything?
Are you also redesigning xmonad's workspaces to fit the EWMH model, since
it is the only correct way to do anything now?

On Thu, Nov 3, 2016 at 10:51 PM, Bogdan Sinitsyn notifications@github.com
wrote:

It seems like a big part of the issue is that the custom function is a
[WindowSpace] -> [WindowSpace]
Is could be used for filtering out internal workspaces like "NSP" used for
named scratchpads. I've created a discussion(#90
#90) about getting rid
of "NSP" which requires many hacks like this for compatibility(and still
has some issues like clicking "minimized" scratchpad on a panel will bring
the NSP workspace).

If repo owners agree with my point about NSP, this and many other hacks
will not be required. But as for now I still prefer not changing signature
because there already exists a function for changing [WindowSpace] in
arguments

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB8SoFA4FKWsQeo5OdGi02m9UN0vwN2wks5q6p3LgaJpZM4Khymv
.

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

[f1u77y]

No, it's not the only acceptable way of course. But I think that using internal workspace isn't a good way because it requires many hacks in modules that are not related to NamedScratchpad and should know as less as possible about its existance.

The main idea of #90 is not to use EWMH but keep minimized scrathpads not in internal workspace but in some global state. This does not differ from (partially?)EWMH-compliant minimization, that's why I suggested to use minimization for scratchpads.

[colonelpanic8]

Closed in favor of #122