Hidden windows are now ignored by the layout so that hidden windows in
the stack don't offset position calculations in the layout.
Also in X.H.ManageHelpers: added `isMinimized`
Instead of searching for the currently focused window across workspaces,
make it so there is never any window above focus on the Stack that is
given to the modified layout.
Closes#657.
Whenever possible, prefer the safe wrappers withWindowAttributes or
safeGetWindowAttributes to getWindowAttributes.
Places where these are not applicable are limited to layouts, where
there is not good "default value" to give back in case these calls fail.
In these cases, we let the exception handling of the layout mechanism
handle it and fall back to the Full layout.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/146
This file was obviously copied from `DwmStyle`, and the author missed changing that
out to `simpleDeco` in one place. Just patching in place since it's a one-word change.
Deprecation warnings are now shown to users via xmessage when xmonad
recompiles, and this may include warnings in xmonad(-contrib) itself if
people have a build script that invokes stack/cabal without --silent,
and they then may get confused. The deprecation warning in that case
won't be shown every recompile but only once whenever xmonad(-contrib)
needs to be rebuilt, but it's still annoying.
This silences the warning. We intend to refactor this part of the code
so this is a temporary measure.
Fixes: f666cf4e4e ("X.H.EwmhDesktops: Deprecate standalone hooks")
* Add a few utility functions which make working with IndependentScreens
more ergonomic; namely workspaceOnScreen, focusWindow', focusScreen,
nthWorkspace, and withWspOnScreen.
* Clean up whenCurrentOn and make it more readable.
* Fix the type-signature of onCurrentScreen.
Users are having trouble with this module all the time. Now that
certain helper functions are undeprecated, we should tell users how they
may use them. It is also worth explaining the scary-looking
`spacingRaw` command a bit further.
Related: https://github.com/xmonad/xmonad-contrib/pull/597
These should be undeprecated for several reasons:
- The suggestion to use spacingRaw is pretty ridiculous; the interface
to spacingRaw is very general and flexible, which is great, but I
think that most people probably do not need all of that flexibility,
and one of these convenience functions may suit their needs better.
- There is precendent for having convenience functions like
these (like X.L.Magnifier)
These were deprecated in a rewrite to make X.L.Spacing support a
non-uniform border length, but from a usability perspective wrappers
should always be preferred to such a general interface with rather shaky
documentation.
Related: https://github.com/xmonad/xmonad-contrib/pull/243 (2c53d507ee)
- Added `workspacesOn` for filtering workspaces on the current screen.
- Added `withScreen` to specify names for a given single screen.
- Added new aliases `PhysicalWindowSpace` and `VirtualWindowSpace`
for a `WindowSpace` for easier to read function signatures.
- Fixed a bug where `marshallPP` always sorted workspace names
lexically.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/420
This is a convenience module in order to have less import noise. It
re-exports the following:
a) Commonly used modules in full (Data.Foldable, Data.Applicative, and
so on); though only those that play nicely with each other, so that
XMonad.Prelude can be imported unqualified without any problems.
This prevents things like `Prelude.(.)` and `Control.Category.(.)`
fighting with each other.
b) Helper functions that don't necessarily fit in any other module;
e.g., the often used abbreviation `fi = fromIntegral`.
A stack of stacks is a more natural representation of what SubLayouts
does: it packs information about the global focus as well as focus in
individual groups (sublayouts).
It doesn't carry information about the sublayouts themselves (but a
similar structure in X.L.Groups does), so we still use Groups and
fromGroups in some places, but future refactor can simplify that as
well, I'm sure.
My main motivation for this is that I need to expose the window groups
to the user config, and a stack of stacks seems to be a nice data
structure for that. The motivation for exposing the groups is that I
want to manipulate focus in a way that takes groups into account. As an
example, I want the following:
* mod-1, mod-2 to mod-0 switches to n-th group if not already focused,
and if focused, focus next in the group
* show these numbers and window titles in xmobar (like tmux/screen/vim
status line), like so:
1a weechat 1b browser 2 vim 3 mutt
Achieving this just using BoringWindows is quite tricky, but with the
ability to somehow (InspectLayout, which is work-in-progress, or message
with IORef) get the stack of stacks out of SubLayouts, this becomes
easy.
