Hi, I was like you ... I think I have the hack that you have need It's an expermental version ... Normaly it works for 2 screens In 2 or 3 months, I will finalize it and I will distribute it. Actually, it works with xmonad 0.4 For use this hacks : *In Config.hs import Hacks.SendWsToAllScreen --01 02 11 12 -- workspacesP = ["1","2","3","4"] workspacesP :: [WorkspaceId] workspacesP = map (\x -> "0"++(show x)) [1 .. nbWorkspacePerScreen :: Int] ++ map (\x -> "1"++(show x)) [1 .. nbWorkspacePerScreen :: Int] -- Le nombre de bureau par ecran nbWorkspacePerScreen :: Int nbWorkspacePerScreen = 9 In keys add: -- mod-[1..6] @@ Switch to workspace N and N+6 [((modMaskP, k),sendWsToAllScreen i) | (i,k) <- take (nbWorkspacePerScreen) (zip [1..] (take nbWorkspacePerScreen keyWorkspace))] *And add the module (SendWsToAllScreen.hs) in the sources path, I hope so that you will find your happiness... I can help you if you have some pb See you, Antoine Bárður Árantsson a écrit :
David Roundy wrote:
On Fri, Dec 14, 2007 at 07:47:36AM +0100, =?ISO-8859-1?Q?B=E1r=F0ur_=C1rantsson_ wrote:
Is there a way to force "consistency" such that I'll always end up with consistent pairs of workspaces on each of the screens? Say as in,
Alt-1:
Screen 1: Workspace 0 Screen 0: Workspace 1
Alt-2:
Screen 1: Workspace 2 Screen 0: Workspace 3
...
?
What you're descibing is the way other window managers work, in which you view just one workspace at a time, and each workspace includes the contents of both screens. I'm not sure why we do this differently. In a sense, it's a sort of crude "sticky window" approach that assumes you're actually only using one screen at a time.
Yup, I'm used to Ion and the current behavior just feels really weird to me.
This wouldn't be to hard to create keybindings for. Alternatively, you could disable xinerama support in xmonad, and construct your layout algorithms using *|* so that windows wouldn't be placed on the boundary between the two screens. This might be more or less successful, depending what layouts you want to use, but would definitely be the easiest and most internally-consistent solution. (Yes, this is a hack, but that's what's required to construct a semantics not implemented in xmonad.)
As an xmonad hacker do you have any idea how difficult it would be to implement this?
I'm not entirely foreign to Haskell, but I've never tried to modify the xmonad code. If I could get any hints as to what bits of code need tweaking, I'd happily have a whack at it. :)
Cheers,