The current DynamicWorkspaces module only supports adding new workspaces
at the start of the list of workspaces. This means when binding workspaces
to keys based on the position in the list, key bindings can change
as workspaces are added in removed in a far more destructive way than
necessary. Instead, supporting appending and arbitrary insertion allows
the user to determine where the new workspace should be added.
This patch is a straight generalization of the addHiddenWorkspace' function.
Rather than always using `(:)` to insert the new workspace into the list
of workspaces, this patches causes it to use an arbitrary list insertion
function instead. A few new functions are added to prevent breakage of
external code while exported functions are left unchanged.
List of new functions:
appendWorkspace
appendWorkspacePrompt
addWorkspaceAt
addHiddenWorkspaceAt
Existing functions were modified to call their generalized brethren where possible
without changing functionality. This patch should not change behavior for any
existing users of this module.
1. Added 'additionalNav2DKeys' which adds keybindings for the cartesian product
of direction keys and (modifier, action) pairs given.
2. Added 'navigation2D' which combines that with 'withNavigation2DConfig'.
3. Added 'additionalNav2DKeysP' and 'navigation2DP' which do the same, but use
the 'additionalKeysP' syntax.
This module provides a way to link certain workspaces in a multihead setup.
That way, when switching to the first one the other heads display the linked
workspaces.
This moves the function to help clean up the `Spawner' to the ManageHook
rather than in functions like spawnOn. Probably it makes no difference, the
reason is because there's one manageSpawn function but many different so this
way there are less functions to write.
The base that comes with ghc-7.6.1 no longer includes Prelude.catch;
so these modules were changed so that there is no warning for
import Prelude hiding (catch)
At the same time these changes should be compatible with older GHCs,
since the catch being has never been the one in the Prelude.
XMonad core re-exports Control.Monad.State, which includes
a function "state" if you happen to use mtl-2. Since there's
a chance xmonad still works with mtl-1 avoid imports like:
import XMonad hiding (state)
* Adds mkPromptWithModes, creates a prompt given a list of modes (list of XPType).
* Adds Setting `alwaysHighlight` to defaultXPConfig. When set to true, autocompletion always highlight the first result if it is not highlighted.
Adds module XMonad.Actions.Launcher. This module allows to combine and switch between instances of XPrompt. It includes a default set of modes which require the programs `hoogle`, `locate` and `calc` to be installed to work properly.
screens. In xinerama mode, when a workscreen is viewed, workspaces
associated to all screens are visible.
The first workspace of a workscreen is displayed on first screen,
second on second screen, etc. Workspace position can be easily
changed. If the current workscreen is called again, workspaces are
shifted.
This also permits to see all workspaces of a workscreen even if just
one screen is present, and to move windows from workspace to workscreen.
elements when modifying the searchString.
The implemented ordering sorts based on how "deep the needle is in the
haystack", meaning that searching for "st" in the elements "Install" and "Study"
will order them as "Study" and "Install". Previously there was no ordering and
when using GridSelect to select workspaces, the ordering was not consistent, as
the list of workspaces (if not modified manually) is ordered by last used. In
this case either "Study" or "Install" would come first depending on which
workspace was last visited.
Note this is very similar to the function of the same name exported by
DynamicWorkspaces. Ultimately it would probably be cleaner to
generalize the one in DynamicWorkspaces to accept an arbitrary
workspace sort as a parameter; this is left as an exercise for future
hackers.
This is a new module to support directional navigation across multiple screens.
As such it is related to X.A.WindowNavigation and X.L.WindowNavigation, but it
is more general. For a detailed discussion of the differences, see
http://www.cs.dal.ca/~nzeh/xmonad/Navigation2D.pdf.