Recompiling on reinstallation

Don today in #xmonad linked http://braindump.dk/tech/2009/05/01/xmonad-upgrade/

The problem seems to be that the custom xmonad binary was not being
recompiled even when XMonad was upgraded/reinstalled. Fortunately, I
had seen a Yi technique which asked Cabal for the installed binary's
patch; then it could get the last-modified times of the installed
binary & the custom binary, and force a recompile if the former was
newer than the latter.

I coded this up for xmonad-core, but whenever I try it out, I get link
errors. This is not the first time I've seen such errors, so I do not
know whether my patch is flawed or my setup. If anyone wants to try it
themselves and perhaps fix it, I'm attaching it.

The changes:

hunk ./XMonad/Core.hs 55
+import System.FilePath.Posix ((</>))
hunk ./XMonad/Core.hs 60
+import Paths_xmonad (getBinDir)
+
hunk ./XMonad/Core.hs 399
+--      * the installed xmonad executable is more recent than the custom xmonad
+--
hunk ./XMonad/Core.hs 408
---
hunk ./XMonad/Core.hs 411
+    cabalBinDir <- getBinDir
+    let cabalBin = cabalBinDir </> "xmonad"
+    cabalBinT <- getModTime cabalBin

Turning emacs mini-buffer window into a strut

This is my first appearance in the xmonad community.  Those tracking
awesome may recognize this post as similar to one I posted earlier on
that mailing list.

Some backstory

As a longtime C++ programmer I had assumed that awesome's imperative
codebase (C++ and Lua) would present a gentler learning curve.  I made
some initial progress but ultimately found awesome still too immature
and undocumented to give me confidence of achieving my various goals
(of which possibly more in a subsequent posting).  On switching to
xmonad the greater maturity, generally good documentation, abundance
of contributed modules and availablity of example configurations
helped me greatly.  The only thing I miss from awesome is its somewhat
snappier performance.  My guess would be that that has nothing to do
with choice of implementation or scripting language, but rather with
the fact that awesome is built on xcb while xmonad is built on classic
xlib.

My current challenge

Years ago I loved Apollo workstations' DM (Display Manager).  Ever
since becoming an emacs user I have dreamed of recreating that
environment.  The emergence of robust tiling window managers and the
example of Drew Adams' OneOnOne package
(http://www.emacswiki.org/emacs/OneOnOneEmacs) leads me to believe
that after a couple decades the dream may now be close to realization.

For reference my environment is Ubuntu Jaunty, Gnome with a single top
panel on a 1920x1200 screen.  Under Gnome/Metacity I have

Re: Turning emacs mini-buffer window into a strut

John Yates <john@...> writes:
> For reference my environment is Ubuntu Jaunty, Gnome with a single top
> panel on a 1920x1200 screen.  Under Gnome/Metacity I have
> emacs-snapshot (23.0.93.1) more or less working in the the single
> mini-buffer for all windows mode.  (Here I use the term window to
> refer to what in the Emacs world would be called a frame.)  The
> mini-buffer window is positioned at the bottom of the screen and is
> full-screen wide.  Alternatively I can position the mini-buffer at the
> top of the screen just below the Gnome panel.
>
> Now I want to move this Emacs arrangement to xmonad.  Because I have
> arranged for the mini-buffer window to have a distinct resource type I
> can recognize it in a manage hook.  From the xmonad FAQ and some
> googling I believe that when that window appears I need to set its
> override-redirect attribute to true and define it as a strut.  Though
> I am working my way through Hal Daumé's "Yet Another Haskell Tutorial"
> I fear it may be a while before I can code such a doStrut function.
> Thus my appeal to the readers of this list.  My sense is that when the
> mini-buffer window appears it is properly sized and positioned.  Thus
> there should be no need to compute the strut components, they should
> be directly liftable from the window.

You might have luck using the XMonad.Layout.Gaps layout in contrib, and
by having a managehook that ignores the emacs minibuffer window (using
doIgnore). This wouldn't be dynamic (moving the emacs window would
require you to reconfigure it), but could work as a kludge until you
manage to do it properly.

Re: Turning emacs mini-buffer window into a strut

John Yates <john@...> writes:

[...]

> From the xmonad FAQ and some googling I believe that when that
> window appears I need to set its override-redirect attribute to true
> and define it as a strut.  Though I am working my way through Hal
> Daumé's "Yet Another Haskell Tutorial" I fear it may be a while
> before I can code such a doStrut function.  Thus my appeal to the
> readers of this list.  My sense is that when the mini-buffer window
> appears it is properly sized and positioned.  Thus there should be
> no need to compute the strut components, they should be directly
> liftable from the window.

I don't know whether this is the best approach, but it occurs to me
that having the mini-buffer frame declare itself as a strut (by
setting _NET_WM_STRUT_PARTIAL) might be a good way to do it?

There's an xmonad extension to handle struts, and presumably other
window managers could make use of it, too.  (I don't know whether this
could be done in elisp.  Hmm, I guess it's not, but that feels like a
logical thing for Emacs to be able to do, so maybe add a frame
parameter to do that?)

darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...

Sat May  2 14:26:31 EDT 2009  gwern0@...
  * Config.hs, Operations.hs: +unfloat, unfloatFocused functions
  'unfloat' is the obvious inverse of the existing 'float' function, and so makes
  the API a little more rational.
  'unfloatFocused' is easy once you have unfloat, and more importantly, is defined in
  >20 user configs; so obviously there's a need!

Sat May  2 14:26:31 EDT 2009  gwern0@...
  * Config.hs, Operations.hs: +unfloat, unfloatFocused functions
  'unfloat' is the obvious inverse of the existing 'float' function, and so makes
  the API a little more rational.
  'unfloatFocused' is easy once you have unfloat, and more importantly, is defined in
  >20 user configs; so obviously there's a need!

Re: darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...

Isn't 'unfloat' the same as 'sink'?

unfloatFocused seems useful. Do you have some examples of how people are
using it?

gwern0:
> Sat May  2 14:26:31 EDT 2009  gwern0@...
>   * Config.hs, Operations.hs: +unfloat, unfloatFocused functions
>   'unfloat' is the obvious inverse of the existing 'float' function, and so makes
>   the API a little more rational.
>   'unfloatFocused' is easy once you have unfloat, and more importantly, is defined in
>   >20 user configs; so obviously there's a need!

Content-Description: A darcs patch for your repository!
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> 
> New patches:
> 
> [Config.hs, Operations.hs: +unfloat, unfloatFocused functions
> gwern0@...**20090502182631
>  Ignore-this: 782418b6bdeaf3b9890a43b44651dbe5
>  'unfloat' is the obvious inverse of the existing 'float' function, and so makes
>  the API a little more rational.
>  'unfloatFocused' is easy once you have unfloat, and more importantly, is defined in
>  >20 user configs; so obviously there's a need!
> ] {
> hunk ./XMonad/Config.hs 210
>      , ((modMask,               xK_l     ), sendMessage Expand) -- %! Expand the master area

Re: darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...

On Sat, May 2, 2009 at 3:11 PM, Don Stewart  wrote:
> Isn't 'unfloat' the same as 'sink'?

If it is, I don't see how defining unfloat as 'windows . W.sink' would work.

> unfloatFocused seems useful. Do you have some examples of how people are
> using it?

Sure. Using my downloader tool to get the config archive, here are 20
copy-pastes of the unfloat function in people's configs (and
presumably there are more in configs not included in the archive):

12.hs:        , ((mod4Mask              , xK_t     ), withFocused $
windows . W.sink) -- %! Push window back into tiling
13.hs:          , ((m,              xK_z), withFocused $ windows .
W.sink) -- unfloat
15.hs:              , ("M-r", withFocused $ windows . W.sink)
19.hs:                , ("M-t",          withFocused $ windows . W.sink)
1.hs:    , ((modm,               xK_t     ), withFocused $ windows . W.sink)
21.hs:    , ((modMask,                xK_t     ), withFocused $
windows . W.sink)
24.hs:           , ("M-t",          withFocused $ windows . W.sink)
25.hs:                , ("M-d", withFocused $ windows . W.sink)
28.hs:    , ("M-t"         ,  withFocused $ windows . W.sink)  -- put
window back on tiling layer
2.hs:    , ((modm,               xK_t     ), withFocused $ windows . W.sink)
34.hs:    , ((modMask,               xK_t     ), withFocused $ windows . W.sink)
38.hs:    , ((modMask,               xK_v     ), withFocused $ windows . W.sink)
3.hs:    , ((modMask,               xK_s     ), withFocused $ windows . W.sink)

Re: darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...

Ah, they're not copy-paste though -- they're in the default Config.

-- Don

gwern0:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On Sat, May 2, 2009 at 3:11 PM, Don Stewart  wrote:
> > Isn't 'unfloat' the same as 'sink'?
> 
> If it is, I don't see how defining unfloat as 'windows . W.sink' would work.
> 
> > unfloatFocused seems useful. Do you have some examples of how people are
> > using it?
> 
> Sure. Using my downloader tool to get the config archive, here are 20
> copy-pastes of the unfloat function in people's configs (and
> presumably there are more in configs not included in the archive):
> 
> 12.hs:        , ((mod4Mask              , xK_t     ), withFocused $
> windows . W.sink) -- %! Push window back into tiling
> 13.hs:          , ((m,              xK_z), withFocused $ windows .
> W.sink) -- unfloat
> 15.hs:              , ("M-r", withFocused $ windows . W.sink)
> 19.hs:                , ("M-t",          withFocused $ windows . W.sink)
> 1.hs:    , ((modm,               xK_t     ), withFocused $ windows . W.sink)
> 21.hs:    , ((modMask,                xK_t     ), withFocused $
> windows . W.sink)
> 24.hs:           , ("M-t",          withFocused $ windows . W.sink)

Re: darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...

Perhaps an alternative would be to make it easier to refer to actions by 
the keys that call them in the default config, which is sort of awkward 
currently. The goal would be remapping sort of like in vim. Here's a 
sketch:

> fromDefaultConfig   :: (ButtonMask, KeySym) -> (X ())
> fromDefaultConfig k = fromMaybe (return ()) $ Map.lookup k $ keys dcl dcl
>   where
>     dcl = defaultConfig { layoutHook = Layout $ layoutHook defaultConfig }

I can't see myself using this, but it could simplify rearranging keys as those
configs do.

Adam

Window manager replacement (--replace flag)

Hi there!

I have looked a little bit into enabling XMonad to replace an existing
window manager when starting. I think it's a useful feature to help a
new user to try out the window manager (e.g. from a running
Gnome-Session with Metacity).

I also found a corresponding 'issue' on the bug tracker
(http://code.google.com/p/xmonad/issues/detail?id=99), which however has
been closed as 'WontFix'.

I have a rough version of the feature ready, which is good enough for my
needs for now. It's not in a shape to go into the repository though, I'm
only posting this here in case someone wants to continue working on it
and for reference.

The current version of the patch is attached. It's also available at my
repository (http://tuvok.home.dyndns.org/xmonad-dev/xmonad/). I had a
look at http://tronche.com/gui/x/icccm/sec-2.html#s-2.8 for reference,
but mostly followed the code of other window managers. Namely XFWM4,
Compiz and Metacity. If someone wants to look into it, here are the
relevant parts:

  apt-get source xfwm4 -> edit screen.c -> search for myScreenSetWMAtom
  apt-get source compiz -> edit display.c -> search for replaceCurrentWm
  apt-get source metacity -> core/screen.c -> search for replace_current_wm

My code does not everything these window managers do for this feature.
The steps that I have skipped out of laziness and/or limited
understanding of X11 programming, are marked with 'SKIPPED' in the code.