I believe this common use-case for the deprecated X.L.Named should still
be provided somewhere, rather than telling everybody to let-define this
themselves.
The other one – `nameTail` – only has about 6 uses in publicly available
configs (https://github.com/search?q=nameTail+path%3Axmonad&type=code),
so I'm not adding that one but I'm happy to be convinced to add it too.
Related: 3bf9d80c40b9 ("XMonad.Layout.Named: Deprecate")
The module has badly bitrotted, and is in such a state that it's
unlikely anyone is using it currently. Better alternatives exist, so
just deprecating seems appropriate here.
Closes: https://github.com/xmonad/xmonad-contrib/issues/793
It turns out qutebrowser will place an entire `data:` URL in
`_NET_WM_NAME`, up to at least 389K characters including
newlines and possibly binary characters.
Clamping window titles to the first line, and to 2K chars
because `defaultShrinker` is quadratic in the title length.
X.L.StateFull's `FocusTracking` and the eponymous `TrackFloating` were
redundant, hence the former was slated for deprecation. However,
the latter and its host module are somewhat poorly named; the layout
modifier has little relation to floats. As such, it's renamed and
rehosted, becoming the eponymous `FocusTracking`.
The redundant offerings in the original modules are redefined in terms
of the new module where possible, and deprecated.
See: #418; comments on #253, #783.
...by introducing yet another special case. Unsurprisingly, this is
just a bandaid—the logic in this module is just wrong. It
purposefully (not introduced with this change) computes the wrong
positions for certain extreme points such that splitVertically (which
simply goes down the list of stack windows _in order_) still works.
What we should do instead is to either
- keep track of windows that want to change their size and compute a
rectangle for them first, or
- immediately when handling the resize message, compute *all* of the
new sizes immediately (instead of only for the window getting
resized).
The latter would force us to keep track of the size of the current stack
we operate in, but since 'handleMessage' lives in X this should not pose
a big problem. I reckon this is the better approach.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/788
The links were broken due to:
1. Incorrect quotes (' instead of " for module links and occasionally
vice-versa).
2. Changes in the name of the "target" module not reflected in the
"source" docs.
3. Typos to begin with.
4. Use of `<foo>` in the docs is rendered as just `foo` with a link to
`/foo`.
5. Similarly for `"Foo"` if it starts with a capital letter (and hence
could be a module).
6. Markup inside `@` code blocks still being applied.
e.g. `@M-<arrow-keys>@` is rendered as `M-arrow-keys` with a spurious
hyperlink from arrow-keys to `/arrow-keys`, which is confusing.
Three links from XMonad.Util.Run have been removed outright, since
they're no longer examples of the usage of 'runProcessWithInput'.
WmiiActions has been gone since 2008, while XMonad.Prompt.Directory
and XMonad.Layout.WorkspaceDir haven't been using
'runProcessWithInput' since 2020 and 2012, respectively.
In some cases the `<foo>` were surrounded with @, especially in the
case of key definitions, for consistency. (This wasn't done
everywhere, because it looks ugly in the source.)
MoreManageHelpers has never been in xmonad-contrib. ManageHelpers
seems to fill the expected role.
In the case of the module description for X.H.ManageDebug the quotes
were simply removed because none of the likely options to make the
link work were successful.
Essentially, whenever the tutorial actually has decent material on the
subject matter. The replacement is roughly done as follows:
- logHook → tutorial
- keybindings → tutorial, as this is thoroughly covered
- manageHook → tutorial + X.D.Extending, as the manageHook stuff the
tutorial talks about is a little bit of an afterthought.
- X.D.Extending (on its own) → tutorial + X.D.Extending
- layoutHook → tutorial + X.D.Extending, as the tutorial, while
talking about layouts, doesn't necessarily have a huge focus there.
- mouse bindings → leave this alone, as the tutorial does not at all
talk about them.
New module that allows for having a configurable border position around
windows. Originally found in a comment by L. S. Leary in [1]. Enough
people have requested this on IRC in recent memory to warrant a proper
module.
[1]: https://github.com/xmonad/xmonad/issues/152#issuecomment-362716434
Co-authored-by: L. S. Leary <LSLeary@users.noreply.github.com>
Data.Default deprecations were removed in
5140f5b5d06790e055eb7fb0cf3eccc4997aa736, yet some comments still refer
to defaultTConf—fix that.
Related: 6b4675e3fa85f95f808a95f8cad790e798cf6ad5
While monitors are, more often than not, wider than they are high,
specifying a ratio in the vertical direction can also make sense; e.g.,
when flipping a monitor by 90 degrees. Thus, we should definitely
support both.
`WindowScreen` is a type synonym for the specialized `Screen` type, that
results from the `WindowSet` definition in XMonad.Core. Having this type
defined and exported in a central module saves extension developers from
trying to reconstruct it, whenever the general `Screen i l a sid sd` is
not suitable.
Note: this should be moved to `XMonad.Core` in the next core release.
This started as an investigation/fix of xmonad freezing when a bug in
X.A.DynamicWorkspaces caused duplicate Windows in a single Workspace
Stack, but I soon(-ish) realized that trying to make SubLayouts robust
enough to handle duplicities in a Stack is futile. Any code that creates
duplicities in a Stack is buggy, and must be fixed; the rest can assume
there aren't any.
Instead, let's just document that this is a pre-condition, and that (and
how) stuff will misbehave.
Related: https://github.com/xmonad/xmonad-contrib/issues/565
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
