[xmonad] Re: Trouble with multiple screens and Nvidia drivers
kg2007.kg at gmail.com
Sat Dec 15 05:56:47 EST 2007
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 :
--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
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,
>>> Screen 1: Workspace 0
>>> Screen 0: Workspace 1
>>> 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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2139 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20071215/33051858/SendWsToAllScreen.bin
More information about the xmonad