Issue 433 in xmonad: Alternative Implementation of WorkspaceDir
Status: New Owner: ---- New issue 433 by que...@gmail.com: Alternative Implementation of WorkspaceDir http://code.google.com/p/xmonad/issues/detail?id=433 Hey, I just extracted an alternative implementation of WorkspaceDir from my configuration and was wondering what the opinion on this is. Could it go into contrib as alternative? Is it better or worse than the original? It's using ExtensibleState to map WorkspaceIds to directories. It also provides a method to execute action that get the current directory as parameter to access the information. There is no need to modify any layouts with this version. Regards, Jan Attachments: WorkspaceDir.hs 3.1 KB
Hey, I came across some issues recently with DynamicWorkspaces and WorkspaceDir. When i create a new workspace, WD seems to sometimes forget which dir the other workspaces were using. I was considering implementing exactly this solution :D. I'm all for this. +1. -Yaakov On Fri, Feb 11, 2011 at 07:53:22AM +0000, codesite-noreply@google.com wrote:
Status: New Owner: ----
New issue 433 by que...@gmail.com: Alternative Implementation of WorkspaceDir http://code.google.com/p/xmonad/issues/detail?id=433
Hey, I just extracted an alternative implementation of WorkspaceDir from my configuration and was wondering what the opinion on this is. Could it go into contrib as alternative? Is it better or worse than the original?
It's using ExtensibleState to map WorkspaceIds to directories. It also provides a method to execute action that get the current directory as parameter to access the information. There is no need to modify any layouts with this version.
Regards, Jan
Attachments: WorkspaceDir.hs 3.1 KB
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
Updates: Status: Patch Owner: vogt.a...@gmail.com Comment #1 on issue 433 by vogt.a...@gmail.com: Alternative Implementation of WorkspaceDir http://code.google.com/p/xmonad/issues/detail?id=433 The "method to execute action that get the current directory as parameter to access the information" isn't as straightforward to implement as the one in Jan's patch. But it should be possible by doing something like the attached patch. The "There is no need to modify any layouts with this version." is probably a good enough reason to replace the exsting WorkspaceDir with the ExtensibleState version. That'll make it harder to write a config that typechecks but doesn't do the right thing. Attachments: l_workspacedir-function-to-run-actions-with-directory.dpatch 3.3 KB
Comment #2 on issue 433 by liskni...@gmail.com: Alternative Implementation of WorkspaceDir http://code.google.com/p/xmonad/issues/detail?id=433 Hey, is there any progress with this? I think it might solve a problem of mine: In addition to a global xmobar with workspaces, battery info, time, date and so on I have one xmobar on each screen with a workspace name and a list of windows (just like a hardstatus line in GNU screen). I'd love these per-screen xmobars to show me the workspace directory as well. I solved this by adding modifierDescription that prints the directory to instance LayoutModifier WorkspaceDir, but that lacks any configurability whatsoever, and adding a function field to data WorkspaceDir is prohibited by the Read/Show instances. Therefore, this is definitely not something I could possibly submit as a patch. Now I found this and it seems it may be a cleaner solution. :-) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings
https://github.com/joe9/xmonad-task/blob/master/XMonad/Actions/Task.hs -- This module allows to organize your workspaces on a precise task -- basis. So instead of having a workspace called `work' you can -- setup one workspace per task. Here we call these workspaces, -- tasks. The great thing with tasks is that one can attach a -- directory, starting layout and ScreenId that makes sense to each -- particular task. One can also attach an action which will be -- triggered when switching to a topic that does not have any windows -- in it. So you can attach your mail client to the mail task, some -- terminals in the right directory to the xmonad task... This package -- also provides a nice way to display your tasks in an historical -- way using a custom `pprWindowSet' function. You can also easily -- switch to recent tasks using this history of last focused tasks. codesite-noreply@google.com wrote:
Comment #2 on issue 433 by liskni...@gmail.com: Alternative Implementation of WorkspaceDir http://code.google.com/p/xmonad/issues/detail?id=433
Hey, is there any progress with this? I think it might solve a problem of mine:
In addition to a global xmobar with workspaces, battery info, time, date and so on I have one xmobar on each screen with a workspace name and a list of windows (just like a hardstatus line in GNU screen). I'd love these per-screen xmobars to show me the workspace directory as well.
I solved this by adding modifierDescription that prints the directory to instance LayoutModifier WorkspaceDir, but that lacks any configurability whatsoever, and adding a function field to data WorkspaceDir is prohibited by the Read/Show instances. Therefore, this is definitely not something I could possibly submit as a patch.
Now I found this and it seems it may be a cleaner solution. :-)
-- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
participants (3)
-
codesite-noreply＠google.com -
Joe M -
Yaakov M Nemoy