ImpredicativeTypes is practically unsupported extension
on it's way to be removed from GHC:
https://mail.haskell.org/pipermail/ghc-devs/2016-September/012826.html
GHC-8.0.2-rc1 already fails to build xmonad-contrib as:
XMonad/Layout/Groups/Helpers.hs:181:22: error:
• Couldn't match type ‘G.WithID l0 Window
-> XMonad.Util.Stack.Zipper (G.Group l0 Window)
-> XMonad.Util.Stack.Zipper (G.Group l0 Window)’
with ‘G.ModifySpec’
Expected type: (G.WithID l0 Window
-> XMonad.Util.Stack.Zipper (G.Group l0 Window)
-> XMonad.Util.Stack.Zipper (G.Group l0 Window))
-> G.GroupsMessage
Actual type: G.ModifySpec -> G.GroupsMessage
• In the second argument of ‘(.)’, namely ‘G.Modify’
In the expression: sendMessage . G.Modify
In an equation for ‘wrap’: wrap = sendMessage . G.Modify
The workaround is simple: add explicit types to applications
or open-code direct application (this change).
Bug: https://github.com/xmonad/xmonad-contrib/issues/123
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
X.L.LayoutBuilderP is nearly identical to X.L.LayoutBuilder. Originally
I wanted to add the ability to dynamically resize the layout boxes so it
make a lot of sense to join these two modules together so I wouldn't
have to do it in both. Even though I never got around to that I still
think it's a good idea to merge these two modules into one.
I believe I was able to merge these without creating any
backward-compatibility issues. I've been sitting on these changes since
2015 and they work for me without having to change older parts of my
config (relating to X.L.LayoutBuilder).
If anyone wants to work on dynamically resizing layout boxes the issue I
created for it is #36.
Commits d638dc8b and a5e87e38 introduced a per-AvoidStruts-instance
strut cache that
a) didn't get initialized at startup,
b) didn't get reinitialized after layout reset and
c) didn't get updates if it wasn't the active layout, for example when
layoutHook = avoidStruts tall ||| avoidStruts (mirror tall)
a) + b) could be fixed by using the docksStartupHook introduced in
28e9f8bc, although this wasn't documented and having to call
docksStartupHook after setLayout is far from obvious.
By moving the strut cache from AvoidStruts instances to a global state,
b) and c) are fixed. One still has to invoke the docksStartupHook for
a), and this will be addressed in the next commit.
This is a fix I have applied locally to make sure that when I use decorated layouts like tabbed in groups, XMonad does not leave bogus decoration windows lying around.
I think that the issue fixed is that the set of groups to send `Hide` to is determined by subtracting the extant groups from `l`, but `l` has already been put through `readapt` and so some groups may have been removed (if they are empty), so they don't get the Hide message.
The comparison should therefore be between `_l` and the new groups.
A layout modifer that is meant to work with the BinarySpacePartition
layout. By removing windows from the window set and adding them back
at a later time, you can move windows to a different branch of the BSP
tree.
This adds three layouts: Spiral is a reimplementation of X.L.Spiral.spiral
with a (to me) more intuitive splitting policy. Dwindle is similar but pushes
the smaller windows into a corner rather than into the center. Squeeze just
stacks windows vertically or horizontally using geometrically decreasing sizes.
Changed default settings with the simple layout modifier. Instead of asking for a bool indicating if all windows should be avoided, no such bool is asked for. No windows are avoided by default. I think this will be a more useful default setting since it would be annoying if dialogue windows are avoided. The same functionality is possible with the advanced constructor. This will be easier for new users.
This will break configurations using the old module, but this will not be much of an issue since the module has not been added to the repo as of this writing.
Checks for floating windows within the layout area and finds a maximum area
rectangle within that does not overlap with any of the floating windows.
This rectangle is used for all non-floating windows.
This new functionality introduced problems with the recommended configuration
of one of my other modules (X.A.FloatSnap.) A new and more reliable method of
distinguishing between clicks and drags where therefore introduced in the new
module X.A.AfterDrag.
This does not break any prior use of FloatSnap, but will require changes in
configuration if used together with AvoidFloats. (This is mentioned in the
docs for AvoidFloats and I recommend using the new configuration method even if
AvoidFloats is not in use.)
Pulled in changes from my repo for this layout on github (https://github.com/benweitzman/BinarySpacePartition)
Includes a new mode for resizing windows in a more intuitive way, also contains a bug fix that was preventing users from
resiving a window up.
Includes changes from github users egasimus (Adam Avramov) and SolitaryCipher (Nick)
This layout modifier is useful for the case if you desire to add a master
pane that has fixed width (it's fixed even if there is just one window
opened). Especially nice feature if you don't want to have too wide
terminal in a master pane.
The layout is implemented as an addition to Master layout, so it reuses
most of the code.
Layout.Spacing applies a customizable amount of space around the outside of each
window. At window edges where two windows meet, the total distance between them
is therefore twice the customized value (one space value from each window). At
the edge of the screen, however, the spacing is only applied once. This results
in uneven amounts of spacing and differently-sized gaps on the screen.
This patch extends the Spacing layout to include a further gap all around the
edge of the screen, thus making all spaces around windows equal in size.
The module implements a proper way of finding out whether the window is
remote or local.
Just checking for a hostname and WM_CLIENT_MACHINE being equal is often
not enough because the hostname is a changing subject (without any
established notification mechanisms), and thus WM_CLIENT_MACHINE and the
hostname can diverge even for a local window.
This module solves the problem. As soon as there is a new window created,
we check the hostname and WM_CLIENT_MACHINE, and then we cache the result
into the XMONAD_REMOTE property.
Notice that XMonad itself does not know anything about hostnames, nor does
it have any dependency on Network.* modules. For this module it is not a
problem: you can provide a mean to get the hostname through your config
file (see usage). Or, if you don't like the hassle of handling dynamic
hostnames (suppose your hostname never changes), it is also fine: this
module will fallback to using environment variables.
This module implements a special kind of layout modifier, which when
applied to a layout, causes xmonad to stop all non-visible processes. In a
way, this is a sledge-hammer for applications that drain power. For
example, given a web browser on a stoppable workspace, once the workspace
is hidden the web browser will be stopped.
Note that the stopped application won't be able to communicate with X11
clipboard. For this, the module actually stops applications after a
certain delay, giving a chance for a user to complete copy-paste sequence.
By default, the delay equals to 15 seconds, it is configurable via
'Stoppable' constructor.
The stoppable modifier prepends a mark (by default equals to "Stoppable")
to the layout description (alternatively, you can choose your own mark and
use it with 'Stoppable' constructor). The stoppable layout (identified by
a mark) spans to multiple workspaces, letting you to create groups of
stoppable workspaces that only stop processes when none of the workspaces
are visible, and conversely, unfreezing all processes even if one of the
stoppable workspaces are visible.
To stop the process we use signals, which works for most cases. For
processes that tinker with signal handling (debuggers), another
(Linux-centric) approach may be used. See
https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt
Note that the use of RebindableSyntax is because of the need to vary the
layoutHook type throughout the config. The alternative, using the existential
Layout type, was rejected because it required TemplateHaskell in order to look
nice, and TemplateHaskell is not portable.
I've tried to make a version of (>>) that also worked on normal monads, but
have had no luck as of yet. Maybe some intrepid soul can add it later.
