Hmm, it seems to me that the relative location where a new window appears (left or right of the current window) should be a configuration parameter inside xmonad. Would this complicate matters severely? Mike David Roundy wrote:

On Mon, Aug 06, 2007 at 04:48:54PM -0700, Michael Vanier wrote:

...

I just installed the Tabbed extension, and it's great (thanks, David!). Now I can probably ditch ion for good. However, the tabs revealed to me something I hadn't noticed before: that a new window gets placed to the left of the currently selected window. Is there any way to make the new window come up to the right of the currently selected window, which I find more intuitive?

The trouble is that there are a few counterintuitive choices in xmonad's window ordering, and we'd actually have to make more than one change in order to get things right (i.e. one change outside of Tabbed). (Where "right" is defined by what makes intuitive sense to me with tabbed.)

The mod-tab rotation order also ought to go to the right (which it does). If we switched the mod-tab rotation order, then we could simply reverse the display relationship of windows, and everything would be intuitive.

If we kept the display the same (relative to xmonad's internal Stack structure), then we could modify xmonad to put new windows on the right instead of the left, but then we'd also need to modify filter so that when a window is closed the focus moves to teh left instead of to the right.

Without a change to the normal keybindings, I don't see a way to get things cycling like I'd like.

In defense of the normal xmonad rotation order, by default mod-tab brings you to a parent window from a just-popped-up window, which I think is quite reasonable. Mostly I'm ambivalent on the subject, but obviously verbosely so...

And you're welcome! :)

mvanier:

I would certainly vote for that.

BTW I'm getting more and more impressed with xmonad. I think it can become the most hackable window manager ever.

I agree. I'm amazed at the simple things done to the core, that have enabled such an explosion of extensions (the contrib repo is nearly 3x the size of the core now!) The big win was to stick to full Haskell for configuration and extension -- without that, we'd have crippled the project. -- Don

mvanier:

I agree with everything you say, but I can imagine a time down the road where it might be easier to allow users to compile xmonad outside of the xmonad source directory. That way, they would just need a Config.hs file and essentially nothing else (unless they also wanted to create their own local extensions). This would also make it easier if multiple users were all using the same xmonad installation. Not that this is in any way a priority.

We'd need to look at ghc-api support for this. Something for the longer term. -- Don

stefanor:

On Tue, Aug 07, 2007 at 12:34:28PM +1000, Donald Bruce Stewart wrote:

...

mvanier:

...

I agree with everything you say, but I can imagine a time down the road where it might be easier to allow users to compile xmonad outside of the xmonad source directory. That way, they would just need a Config.hs file and essentially nothing else (unless they also wanted to create their own local extensions). This would also make it easier if multiple users were all using the same xmonad installation. Not that this is in any way a priority.

We'd need to look at ghc-api support for this. Something for the longer term.

Not strictly necessary. You (?) proposed earlier inverting xmonad, such that Config.hs would contain main and depend on everything else. I note that if this were done, it would be possible to compile "Config.hs" `delete` xmonad as a Cabal library, and then running a standalone config file would be as easy as runghc.

Ah yes, I'd forgotten about this trick. -- Don