Donald Bruce Stewart wrote:

...

So now I come to a question, I have a xinerama setup for my laptop that means I can plug into a monitor and have two screens. My usual usage involves me having to go hunting through workspaces to find where I left a particular client window open (a terminal, web browser window etc). What I'm finding at the moment is that as I move through the workspaces, at some point I select a workspace that's on the other screen to the one I'm working on, and by selecting that workspace I move to that other screen. Then as I continue looking through my workspaces, I pull them to that screen instead (I flick fast ;-) ).

So the question is, how do other people solve this problem (ie. how do you cycle workspaces to find something you want in xinerama without getting thrown around between screens) ?

And, is there a better way to find something on another workspace ?

I use the state logging facility, and xmonad-status.c to display a little status bar showing the current workspace, and those others with clients on them -- I'm actually addicted to this script now. It takes the logging output, and prints it as:

1 2 [3] 5 8

giving the indices of non-empty workspaces, and the focused one. Pipe that into dzen, and off you go. Examples in XMonadContrib/scripts/

I the darcs version, you enable this by setting logging = True, and having xmonad-status.c built and in your path.

We're just about to move this printing stuff into Config.hs too, so you can print your own formats to stdout.

-- Don

Hi Don, I recall the output feature not being in 0.2, at least definitely can't see any ouput flowing through the pipe that is setup on startup. So since I have a recollection of needing the latest src from the head, I tried to build the latest xmonad from darcs and hit this error, % runhaskell Setup.lhs configure Configuring xmonad-0.2... configure: Dependency base>=2.0: using base-2.0 configure: Dependency X11>=1.2.1: using X11-1.2.2 configure: Dependency X11-extras>=0.2: using X11-extras-0.2 configure: Dependency mtl>=1.0: using mtl-1.0 configure: Dependency unix>=1.0: using unix-1.0 configure: Using install prefix: /usr/local configure: Binaries installed in: /usr/local/bin configure: Libraries installed in: /usr/local/lib/xmonad-0.2/ghc-6.6 configure: Private binaries installed in: /usr/local/libexec configure: Data files installed in: /usr/local/share/xmonad-0.2 configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.6 configure: Using package tool: /usr/bin/ghc-pkg configure: Using ar found on system at: /usr/bin/ar configure: No haddock found configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /usr/bin/runghc configure: Using runhugs found on system at: /usr/bin/runhugs configure: No happy found configure: No alex found configure: Using hsc2hs: /usr/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found alana% runhaskell Setup.lhs build *** Exception: dist/build/autogen/Paths_xmonad.hs: openFile: permission denied (Permission denied) alana% sudo runhaskell Setup.lhs build Preprocessing executables for xmonad-0.2... Building xmonad-0.2... [3 of 6] Compiling Config[boot] ( Config.hs-boot, nothing ) [4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operations.o ) Operations.hs:199:9: Not in scope: `changeProperty32' Operations.hs:205:12: Not in scope: `unmapWindow' Operations.hs:509:15: Not in scope: `getWMNormalHints' Operations.hs:523:18: Not in scope: type constructor or class `SizeHints' Operations.hs:525:51: Not in scope: `sh_max_size' Operations.hs:526:51: Not in scope: `sh_base_size' Operations.hs:527:51: Not in scope: `sh_resize_inc' Operations.hs:528:51: Not in scope: `sh_aspect' Operations.hs:529:51: Not in scope: `sh_base_size'

Donald Bruce Stewart wrote:

dave:

...

Donald Bruce Stewart wrote:

...

...

So now I come to a question, I have a xinerama setup for my laptop that means I can plug into a monitor and have two screens. My usual usage involves me having to go hunting through workspaces to find where I left a particular client window open (a terminal, web browser window etc). What I'm finding at the moment is that as I move through the workspaces, at some point I select a workspace that's on the other screen to the one I'm working on, and by selecting that workspace I move to that other screen. Then as I continue looking through my workspaces, I pull them to that screen instead (I flick fast ;-) ).

So the question is, how do other people solve this problem (ie. how do you cycle workspaces to find something you want in xinerama without getting thrown around between screens) ?

And, is there a better way to find something on another workspace ? I use the state logging facility, and xmonad-status.c to display a little status bar showing the current workspace, and those others with clients on them -- I'm actually addicted to this script now. It takes the logging output, and prints it as:

1 2 [3] 5 8

giving the indices of non-empty workspaces, and the focused one. Pipe that into dzen, and off you go. Examples in XMonadContrib/scripts/

I the darcs version, you enable this by setting logging = True, and having xmonad-status.c built and in your path.

We're just about to move this printing stuff into Config.hs too, so you can print your own formats to stdout.

-- Don Hi Don,

I recall the output feature not being in 0.2, at least definitely can't see any ouput flowing through the pipe that is setup on startup.

Correct. Its in the darcs branch. *But* I'm actively working on it now, if you want to hold off for 30 mins or so.

lol, I'll try and resist ;-)

...

So since I have a recollection of needing the latest src from the head, I tried to build the latest xmonad from darcs and hit this error,

Yep, you need to update X11-extras first..

ah, will do

dave:

Dave Harrison wrote:

...

...

...

So since I have a recollection of needing the latest src from the head, I tried to build the latest xmonad from darcs and hit this error, Yep, you need to update X11-extras first..

ah, will do

Hi Don,

Having just updated from the latest of X11-extras and xmonad I've discovered my xinerama setup is now being treated as a single window ... any debugging I can do to try and work out why this is happening ?

Very likely you didn't autoreconf the X11-extras directory? Since you'd be using darcs X11-extras, which doesn't have a pre-generated ./configure, that would lead to ./configure not being generated, and Xinerama not being detected. Check the X11-extras README on "if you are building from darcs" Cheers, Don

dave:

Donald Bruce Stewart wrote:

...

dave:

...

Dave Harrison wrote:

...

...

...

So since I have a recollection of needing the latest src from the head, I tried to build the latest xmonad from darcs and hit this error, Yep, you need to update X11-extras first.. ah, will do Hi Don,

Having just updated from the latest of X11-extras and xmonad I've discovered my xinerama setup is now being treated as a single window ... any debugging I can do to try and work out why this is happening ?

Very likely you didn't autoreconf the X11-extras directory?

Since you'd be using darcs X11-extras, which doesn't have a pre-generated ./configure, that would lead to ./configure not being generated, and Xinerama not being detected.

Check the X11-extras README on "if you are building from darcs"

I went back and called autoreconf, then wiped out the contents of the dist/ dirs inside the repos (both for xmonad and X11-extras). The I configure, built, and installed X11-extras and xmonad. Same behaviour again, so I tried wiping out the install in /usr/local/lib/X11-extras and did it all again, still same "single workspace across two screens" thing going on ...

Just double check you're not linking against the wrong things.The process would be: darcs get --partial X11-extras autoreconf configure (check it finds Xinerama) build that install get an fresh xmonad from darcs configure ; build ; install See the mailing list recently for another case of Xinerama being lost due to linking against old versions of libs, http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/379 (Note that nothing's changed that would break Xinerama handling, so its alsmot certainly due to linking against the wrong version of the lib. runhaskell Setup.lhs clean is advised for any change in dependent libraries, like X11-extras). -- Don

On Sun, Jun 10, 2007 at 04:08:20PM +1000, Dave Harrison wrote:

Hi Don,

I recall the output feature not being in 0.2, at least definitely can't see any ouput flowing through the pipe that is setup on startup.

So since I have a recollection of needing the latest src from the head, I tried to build the latest xmonad from darcs and hit this error,

[...]

Operations.hs:529:51: Not in scope: `sh_base_size'

You need darcs x11-extras for darcs xmonad. (A notice was added to the readme only today, we aren't suprised you haven't noticed it yet.) Stefan

dave:

...

...

And, is there a better way to find something on another workspace ?

I use the state logging facility, and xmonad-status.c to display a little status bar showing the current workspace, and those others with clients on them -- I'm actually addicted to this script now. It takes the logging output, and prints it as:

1 2 [3] 5 8

giving the indices of non-empty workspaces, and the focused one. Pipe that into dzen, and off you go. Examples in XMonadContrib/scripts/

I the darcs version, you enable this by setting logging = True, and having xmonad-status.c built and in your path.

I've grep'd the code, and can't find where I'm meant to set logging = True ?

Right! I warned you I was working on that code :-) Rather than being a simple 'logging :: Bool' , the logging hook is now an arbitrary chunk of code to run on each state change. logHook :: X () An example, http://www.cse.unsw.edu.au/~dons/tmp/Config.hs (my config set up) So, given that state logging to stdout, my xinitrc now contains: dzen2 -e '' -ta l -fg $FG -bg $BG -fn $FONT < $PIPE & xmonad > $PIPE & where $PIPE is a fifo. In all its glory, http://darcs.haskell.org/~sjanssen/XMonadContrib/scripts/run-xmonad.sh See the mail earlier today about 'a new logging framework' :-) -- Don

Spencer Janssen wrote:

You should try GreedyView in XMonadContrib. Let me know how you like it -- I've been considering making this the default behavior for some time now.

...

And, is there a better way to find something on another workspace ?

Hmm, not sure about this one. Maybe write a little script for XMonadContrib that pipes window names to dmenu and gives the selected window focus?

Hi Spencer, I can't seem to find any doc in the code on how I should change the switching method over to use greedy view, I've imported it, where do I need to make the change ? Cheers Dave

Donald Bruce Stewart wrote:

dave:

...

Spencer Janssen wrote:

...

You should try GreedyView in XMonadContrib. Let me know how you like it -- I've been considering making this the default behavior for some time now.

...

And, is there a better way to find something on another workspace ? Hmm, not sure about this one. Maybe write a little script for XMonadContrib that pipes window names to dmenu and gives the selected window focus? Hi Spencer,

I can't seem to find any doc in the code on how I should change the switching method over to use greedy view, I've imported it, where do I need to make the change ?

You'd rebind the call to 'view' in Config.hs, to be greedyView, I think.

Something like:

[((m .|. modMask, k), f i) | (i, k) <- zip [0 .. fromIntegral workspaces - 1] [xK_1 ..] , (f, m) <- [(view, 0), (shift, shiftMask)]] ^^^^

would be replaced with greedyView, so that mod-1..n calls that instead.

If that's indeed the fix, can you submit a documentation patch to GreedyView.hs, illustrating how to call it?

-- Don

Hi Don, That did the trick. I've attached the patch to this email (having never generated a darcs patch before I'm not 100% if it's correct, but it seems to be :-) ) Cheers Dave

Spencer Janssen wrote:

On Sun, 10 Jun 2007 14:49:30 +1000 Dave Harrison wrote:

...

... snip ... So the question is, how do other people solve this problem (ie. how do you cycle workspaces to find something you want in xinerama without getting thrown around between screens) ?

You should try GreedyView in XMonadContrib. Let me know how you like it -- I've been considering making this the default behavior for some time now. ... snip ... Cheers, Spencer Janssen

Hi Spencer, I've been using the GreedyView module for about a day now and I find it makes alot more sense to me because it means that my active screen _stays_ my active screen. The concept of bringing the workspace to my active screen every time works really well. The one thing I'm trying to think my way around is how to handle this situation, - I'm trawling my workspaces to see where I left a particular window - I (unintentionally) pull the workspace on my other screen to my active screen - My active workspace then gets swapped to the 2nd screen - I move my active screen to another workspace Now the workspace I wanted to be on my 2nd screen is no longer visible and I have to fish it out and put it back where it was. But a big +1 on GreedyView. Cheers Dave

On Mon, Jun 11, 2007 at 02:40:57PM +0200, Kai Grossjohann wrote:

I think what I want is the following behavior:

Each workspace has a "home screen". Switching to other workspaces (at least via RotView, perhaps also via direct access Mod-1 .. Mod-9) refuses to display workspaces with the wrong "home screen". ... And I also find that I always want to show the web browser on screen 1 whereas my mail reader should be on screen 2. So it makes sense to me to set the home screen of the web workspace to 1, so that it is always shown there.

What do people think?

I don't use Xinerama, but this fits with a code reorganization I've been contemplating. The idea would be to treat screens in a manner that is symmetrical with ordinary windows. The motivation would be to make it easy to do things like combine TwoPane with Tabbed to present two windows on the screen, but have tabs for the rest. We'd have something like data NestedStack a = W a | S (Stack a) It'd have to be a bit more complicated, since we'd want to have a Layout associated with each stack, so maybe it'd be more like data NestedStack l a = Empty | Singleton a | Stack { layouts :: !(l,[l]) , focus :: !(NestedStack l a) , up :: [NestedStack l a] , down :: [NestedStack l a] } Then the idea would be that under Xinerama at the top level you'd have a single NestedStack holding one NestedStack per screen. Workspaces would live in those nested stacks--so each workspace would naturally have a "home" screen. And you could also create (with appropriate bindings) workspaces that have structure within them. Besides being useful for everyday use (close to ion3 in structure), this would mean that much of the Xinerama code is also useable by people with only one monitor, which among other things means that I'd be able to exercise and make use of (almost) all the code. -- David Roundy http://www.darcs.net