`EwmhFullscreen` unconditionally sinks windows in response to a
`_NET_WM_STATE` root window message removing `_NET_WM_STATE_FULLSCREEN`.
Unfortunately, at least some versions of either the Gtk or GNOME
libraries send this on startup while restoring a window's last
known state, which means a `manageHook` `doFloat` will be undone.
This change ignores the remove if the window is not fullscreen.
A followup issue, #865, has been added for the follow-on problem
that the floating state of a window is not restored on removal of
the fullscreen state.
Fixes: #820
* First version of DecorationEx.
* Fixed most warnings.
* Fix build error with ghc-9.8.1.
* Fix title shrinking with text decoration.
* Add convinience re-exports.
* Get rid of orphan instances.
* Fix a couple of warnings.
* Rename X.L.DecorationEx.Types -> X.L.DecorationEx.Common
* Add instance Default StandardCommand.
* Fix some typos and formatting
thanks to @geekosaur
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
* Fix reference to xmonad.hs
See also #859
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
* Fix reference to xmonad.hs
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
* Fix formatting
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
* Fix some typos and formatting
thanks to @geekosaur
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
* Remove commented code.
* Update CHANGES.md.
* calcWidgetPlace is now allowed to return rectangle with any X,
but that will be ignored.
* More generic instance for DecorationWidget GenericWidget.
* Replace explicit definition of `fi` with import from X.Prelude.
thanks to @slotThe.
* Move fetch-all pattern to the end of definition.
thanks to @slotThe.
* X.L.DecorationEx: Add screenshot
---------
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: Tony Zorman <soliditsallgood@mailbox.org>
Useful for restoring browser windows to where they were before restart
(which is something one should do several times a week as security
updates get released).
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: 3bf9d80c40 ("XMonad.Layout.Named: Deprecate")
It might be that the keypress does not have a valid stroke associated to
it, but is still bound to an action (e.g., xK_Left an friends). In this
case, we still want to execute it.
Closes: https://github.com/xmonad/xmonad-contrib/issues/845
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
+ Add a new prevCompletionKey to XPConfig, in order to cycle backwards.
Bound to S-<Tab> by default.
+ Already handle null keystrings (times when only a modifier was
pressed) in handleMain, such that completions aren't cleared
prematurely.
+ Augment nextComplIndex (now computeComplIndex) with the ability to go
in an arbitrary 1-dimensional direction. As a result, that function,
as well as handleCompletion and handleCompletionMain now take an
additional Direction1D argument.
Based on: https://github.com/solomon-b/xmonad-contrib/tree/feature/scrolling-prompt-completions
Fixes: https://github.com/xmonad/xmonad-contrib/issues/831
Co-authored-by: Solomon Bothwell <ssbothwell@gmail.com>
At some point `peekCString` became locale aware. This is a double
bug, since (a) `decodeString` was being applied to the result and
(b) the locale might not be UTF-8, but the string being decoded
always is.
The fix is to use `peekCAString` which bypasses the locale decode,
then continuing to do UTF-8 decode.
Added support for several more properties, and fixed parsing of many
others. Still doesn't handle COMPOUND_TEXT and the code in DebugWindow
is wrong. I have correct code in C++ but it will require some work to
translate to Haskell so it can be used in both places.
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.
Fairly straightforward, just add two hooks for (un)fullscreening. There
are multiple motivations for this:
* Users are calling for unfullscreened windows to revert back to their
original location if they were floating.
* XMonad.Layout.Fullscreen uses some deprecated exports from
XMonad.Hooks.EwmhDesktops and reimplements fullscreenEventHook.
This commit only adds the hooks. Neither of the motivations are dealt
with yet, so the docs are a bit terse still.
Related: https://github.com/xmonad/xmonad-contrib/issues/456
Related: https://github.com/xmonad/xmonad-contrib/issues/394
Related: https://github.com/xmonad/xmonad-contrib/pull/626
We test against 9.2.7 now, so we should make our stack config reflect
that—plus, it's more convenient for users, since one is more likely to
already have the latest minor version of GHC installed.
Related: 67064ddd9264bbe39d6fa88fd8336086817dd0db
The stack CI already tests against 9.2.7 instead of 9.2.5 (as the cabal
file said), since we just specify the major version of the LTS resolver,
and lts-20 is up to 9.2.7 by now. Not much has changed since 9.2.5, but
update the haskell-ci workflow regardless. Likewise, 9.4 can be bumped
one minor version, so do that as well.
Technically, contrib still does not build with stack, as it forces
xmonad-0.17.0, while only HEAD builds with newer mtl versions. However,
until our dependencies are at least revbumped, this may be the best we
can do.
Related: https://github.com/xmonad/xmonad-contrib/issues/805
Originally, `dynamicLogString` could have a bottom hidden in it and
thereby crash the `logHook`. Under some circumstances (see #801)
this could cause xmonad to get stuck. We now force the result, and
`dynamicLogString` catches the exception and substitutes a
message (currently "_|_"). Use `dynamicLogString'` for the old behavior.
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.
These modules were duplicating a substantial amount of low-level code.
`X.A.CycleWorkspaceByScreen` had already separated most of the
implementation details from the logic with `repeatableAction`; all that
was left was to generalise it a little further, put it in a suitable
place and express the other modules through it.
This combinator forces XMonad to *not* set _NET_DESKTOP_VIEWPORT.
This information is picked up by polybar's xworkspaces module and used
to re-group the workspaces by monitor. I (and others) find this super
confusing, but polybar doesn't not seem open to addressing it.
https://github.com/polybar/polybar/issues/2603
Opting in to the old behavior of not managing this property is one way
to work around it instead.
hlint 3.5 is built against libtinfo6 and works on Ubuntu 22.04 without
needing to install libtinfo5.
Fixes: b7afb0c0bc ("ci: Pin runner in hlint, nix workflows to ubuntu-20.04")
...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
I have no idea what I was thinking when I wrote that code.
While at it, just reused the code for ICCCM title which already
assumes the client may have broken the rules (I think we have
seen a case of `WM_NAME` being `UTF8_STRING`).
Invoking cabal in the project directory with a cabal.project file might
fail on unrelated dependencies missing, see
4f539734be
Doesn't fail in this repo, but let's keep the workflows in sync.
Both are now broken with ubuntu-22.04. Nix:
error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted
hlint:
/opt/hostedtoolcache/hlint/3.4.1/x64/hlint: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
Breaks `apt update` on the ubuntu-22.04 runner, which is what
ubuntu-latest resolves to these days.
Fixes: 7312d6f3f3 ("ci: Drop GHC installation via apt")
When XMonad was recently restarted, it can happen that the workspace
history is empty, hence the last focused window could actually be the
currently focused one. In that case, we don't want to go through the
machinery of looking to hide any NSPs, as there is only one window in
the current workspace (the focused one). This may or may not be a
scratchpad, we don't care.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/779
Starting with time-1.10, the iso8601DateFormat function was deprecated
in favour of more sophisticated methods for showing ISO 8601 date
formats—as such, follow the libraries lead.
Sadly, the new functionality was only introduced in time-1.9, meaning
GHC 8.8 and up. Since we still support 8.6, the introduction of some
CPP is necessary.
Libraries like Control.Monad are no longer exported from
Control.Monad.Reader et.al.
Related: https://github.com/xmonad/xmonad/pull/427
xmonad/xmonad#d170e99bc5e97db96be9a02b72149103e8d419af
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.
This is (i) much simpler to use and (ii) helps us with refiling. Emacs
will ignore todo keywords _that it knows_ when refiling, but when
started in batch-mode it doesn't know a whole lot. One would need to
thread the `todoKeywords' through to `refile' and then set
`org-todo-keywords' or a similar variable, which does not sound like a
good experience. Hence, falling back to showing the todo keyword to the
user when deciding upon a headline sounds acceptable.
haskell-ci by default passes --haddock-all to cabal v2-haddock, which
builds docs for all components and the …-docs.tar.gz tarball ends up
containing the docs for the last component, which happens to be tests.
We need the tarball to contain the library docs, for upload to Hackage.
Fixes: 7cee191516 ("CI: Remove hlint from haskell-ci")
The apt repo hosting these packages has been unmaintained for quite a
while, and we've excluded ~/.stack/programs from the cache long time
ago, so we can just let stack handle the installation. It's not much
slower than installing via apt, and even if it was, some matrix jobs
need to use the slow path anyway.
Related: 9fce3805fcf2 ("ci: Use system GHC in Stack to not waste GH Actions cache space")
Related: 7d10e470d71d ("ci: Avoid caching GHC")
This ensures that we always immediately expand the file path upon
constructing an `OrgMode' record. We thus do not have to do this in
`mkOrgPrompt' anymore.
Add sideNavigation as a fallback if needed. This should not have any
user-facing behaviour change when not using gaps or spacing, as line
navigation is preferred. However, users who do use spacing or gaps
should now potentially not have to change the default strategy in order
to have a usable module.
Users may not see the warning that insertPosition definitely needs to be
inserted at the leftmost position, which can cause undesired behaviour.
Having a combinator that handles this automatically seems like a sane
idea.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/709
(Note that `docs` wasn't changed since it already inserts itself
rightmost.)
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.
Most of these definitions are probably small enough to be inlined on
their own, but tell GHC to try really hard regardless. This is commonly
done by other parser libraries as well; e.g., [1], so it shouldn't cause
any issues either way.
[1]: https://hackage.haskell.org/package/parsers-0.12.11
While not many of these more exotic combinators are used right now, it's
still nice to have feature parity (i.e., everything that one could want
from a basic parser) such that people don't have to add their own
combinators, in case they want to use one that's not already
implemented.
This was only used in three places throughout the module and is sort of
non-standard terminology, hence it might confuse users. Talking about
functions of type
XConfig Layout -> M.Map (ButtonMask, KeySym) (X ())
is relatively standard in other modules as well, so it's probably best
to remove the type alias for it.
The Usage section made reference to a non-existent
`namedScratchpadSpawnAction` function. It has been replaced with
`namedScratchpadAction` in accordance with the documented bindings
below.
This may seem a bit self-indulgent, but both of these features are
either quite new or so old that no one remembers them anymore, so not a
lot of up-to-date content exists for them.
This is i) broken and ii) just the functionality of X.U.NamedScratchpad
rewrapped (and not necessarily improved upon) at this point.
With recent changes to the way named scratchpads work[1], we would have
to export internals of X.U.NamedScratchpad in order to restore
X.U.Scratchpad to its full functionality. This does not seem worth it,
as the latter does not bring anything substantially new to the table.
Closes: https://github.com/xmonad/xmonad-contrib/issues/756
Related: https://github.com/xmonad/xmonad-contrib/issues/591
[1]: 3fc830aa09
In case a font could not be opened, simply fall back to "xft:monospace"
and open that. The initCoreFont and initUtf8Font functions already have
mechanisms like this, is was just missing from initXMF.
Closes: https://github.com/xmonad/xmonad-contrib/issues/723
+ $keyAddDel can just be a side note in $keyDel, it does not need its
own section.
+ $logHook is covered in more detail in the tutorial and does not serve
a real purpose anymore. One could rewrite it to be more in-depth
about the inner workings of X.H.StatusBar, but for the time removing
it seems like the best option.
Closes: https://github.com/xmonad/xmonad-contrib/issues/645
Nowadays, removing keys is mostly done via removeKeys and removeKeysP,
so the documentation should reflect that fact. This part is less
step-by-step instructive than the section about adding keys, but read in
succession it presents a way to deepen the newly acquired knowledge.
* Support comp.nix.
* Re-order overlays and modules dependency-last for sanity.
* Re-export `xmonad.modernise`.
NIX.md:
* Document comp.nix.
* Simplify example system flake, removing direct dependency on the
xmonad flake.
* Advise sane module ordering.
* Include and document `modernise` workaround.
* Clarify user-substituted `<foo>` values.
.gitignore:
* Include nix 'result' symlink.
By being a bit less greedy with consuming whitespace in the date/time
parsers, we can make the `prop_{encode,decode}Preservation` properties
well-defined again.
Switch the underlying UnicodeData data type from the current ByteString
implementation to String. This is in order to facilitate descriptions
Unicode descriptions of the Unicode characters themselves. We chose
String instead of Text because it does not incur an extra dependency.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/733
Instead of providing these as default values, as originally planned,
just add a note for users who wish to customise that part of the prompt.
We simply get the user config in mkPassPrompt and so overriding that
with a custom searchPredicate and sorter seems unwise.
Closes: https://github.com/xmonad/xmonad-contrib/issues/746
Add the trivial Arbitrary instance for Priority, extend the Arbitrary
instance of OrgMsg, as well as some plumbing. Also work in some unit
tests for regression testing.
When the -XOverloadedStrings language extension is on, treat a string s
as the parser 'string' s, when appropriate. This allows one to write
things like "a" *> otherParser instead of 'string' "a" *> otherParser.
The `lisp` and `elpa` lists will simply be the (unqualified) file names.
Thus, if we use isInfixOf and try to require a library with a very short
name (like s.el), other things may be chosen over it. isPrefixOf,
together with the additional `-`, prevents this from happening.
With [1] merged, the XMonad module from core now exports mkGrabs and
setNumlockMask (now cacheNumlockMask). However, since we want
xmonad-contrib 0.17.1 to compile against xmonad 0.17.0 still, hide the
function for now and continue to use the vendored copies we have in
X.U.Grab currently. We have to ignore the dodgy-imports warning when
-fpedantic is on, but that seems like a small price to pay.
A breaking change for this is planned for 0.18.0.
[1]: https://github.com/xmonad/xmonad/pull/405
Last year I thought a bit about making this an actual `executable` in
xmonad-contrib.cabal, but decided against it. Unfortunately I can't
remember why. So let's do the bare minimum to at least ship it now, and
if I remember or if anyone has any ideas, we can do the next step or
document why not.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/734
We haven't used this for a while, and since we dropped descriptions in
X.D.Extending in favor of the haddock-generated index in
839302533b, it's useless.
This fixes several issues related to parsing of parent PIDs:
* A process with lines or spaces or parentheses in its process name
would confuse the code in X.A.SpawnOn and possibly lead to a
`Prelude.read: no parse` exception.
* `X.H.WindowSwallowing.isChildOf` looked for the parent PID anywhere in
the output of pstree, so single-digit parent PIDs would be considered
as parents of any process with that digit anywhere in its chain of
parent PIDs. (Note that apps in PID namespaces like in Flatpak often
have single-digit PIDs.)
* `pstree` is no longer required in `$PATH`.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/726
X11 only handles alpha channels in a restricted set of APIs (such as
setting `border_color`); most others throw undocumented errors and/or
produce black pixels. Document this, and mask out alpha where it
matters.
Fixesxmonad/xmonad#395, xmonad/xmonad#398.
As the XMonad config is commonly customized by saying
def { startupHook = ...
, manageHook = ...
, ...
}
It seems consistent to allow the same for an individual hook config:
let urgencyHook = def { suppressWhen = ...
, remindWhen = ...
}
Since 3fc830aa09, scratchpads are now
added in namedScratchpadManageHook. This, however, means that we need
some kind of MapRequestEvent to happen before processing scratchpads,
otherwise the manageHook didn't run yet and our extensible state is
being left empty. When trying to open a scratchpad right after starting
xmonad—i.e., before having opened a window—this may not be the case.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/728
Add support for EZConfig-style bindings while also maintaining some
guarantees as to which type of representation we will store in the
extensible state. This means that parsing of the keys will happen no
later than the call to `modal`.
Users can choose to use `mkKeysEz` or `mkKeysFun` to create a new
collection of keys to bind for a mode. This is deemed more ergonomic
than exporting the respective constructors directly.
Mostly small things, like making imports line up with the provided
comments. Also:
+ Rename mode' -> modeWithExit. This seems like a better name for
discoverability reasons.
+ Make the fields of Mode strict, because they have no reason not to,
really.
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.
This adds documentation for the new EDSL, as well as small fixes to
existing docs.
Importantly, I've added myself as a maintainer of the file (even though
we don't really care about this at this point) and updated the
copyright; the changes seem large enough to warrant this.
Some panels—such as polybar—require _NET_DESKTOP_VIEWPORT support in
order to know which workspace is on which monitor. They are then able
to only show workspaces defined on the same output as the bar with just
X11 properties.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/708
The testing repo was not a good location for them, and is now
deprecated. They are now in `scripts/build`, and will be documented
in the main repo's `INSTALL.md`.
`ManageDebug` was continuing to report in the `logHook` even after
the `manageHook` was done. In diagnosing this, I discovered that
the original code was using a tuple of `Bool`s and not even a
comment about which meant what.
The code now uses a proper pair type, and dedicated `data`s for
the two flags that make it clear what each means. This also fixed
the bug, so apparently I had the `Bool`s confused somewhere.
I also took the chance to clarify the documentation a little (a
misleading "persistent", since it doesn't use persistent XS) and
a few more cleanups. Also, it now logs all `manageHook` runs
before the `logHook` in case multiple windows are opened.
+ Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now.
+ Add support for Stackage LTS 19, which ships with GHC 9.0.2.
+ Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1.
Also, explicitly pass -XCPP to hlint; see [1].
[1]: https://github.com/ndmitchell/hlint/issues/1360
Since users should not use these functions, anyways, separating them out
seems like a good idea. Plus, one now does not need to scroll over them
to get to the dynamic scratchpad functionality (people may stop when
seeing "DEPRECATED" signs everywhere).
With the extensible state machinery in place[1], we are now able to
seamlessly integrate dynamic scratchpad functionality into
X.U.NamedScratchpad. This is one step into the direction of having a
single scratchpad implementation that can "do anything".
Related: https://github.com/xmonad/xmonad-contrib/issues/591
Related: https://github.com/xmonad/xmonad-contrib/pull/662
[1]: 70d08b82f43057447e8e2479aa515b6db0d199e4
(X.U.NamedScratchpad: Use ExtensibleState to store scratchpads)
Instead of using the scratchpads that the user specifies (as this will
realistically just be "all of them"), create some extensible state for
the scratchpads to reside in.
To ensure that this is done in a backwards compatible way, function
signatures did not change and they instead just ignore the list of
scratchpads given to them and the initialisation is done in the
manageHook, which users already have to use anyways.
We do not ship the nix flake in the release tarball, so it does not make
sense to include NIX.md in there either; at least for now.
Fixes: 4ca46c2414 (Add NIX.md)
There are multiple ways one could use XMonad with nix, so a separate
file for documenting all of this seems appropriate. E.g., when it
contains the respective installation instructions (e.g, "normally" as
instructed in the NixOS wiki, via stack, via flake, ...) we could link
to it from INSTALL.md.
For now it's a good place to document the new `develop.nix`
functionality.
Co-authored-by: Ivan Malison <IvanMalison@gmail.com>
In a multi-head setup, it might be useful to have screen information of the
visible workspaces combined with the workspace name, for example in a status
bar. This module provides utility functions to do just that.
`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.
X.H.ManageDocks: Avoid unnecessary refresh (loop) for decorations
This started as an investigation of the root cause of
<https://github.com/xmonad/xmonad-contrib/issues/565>, which was
addressed by <https://github.com/xmonad/xmonad-contrib/pull/621> without
having a full understanding of why xmonad ends up in a busy loop.
What was going on:
* X.L.SubLayouts group update algorithm assumes no duplicities in the
Stack, and results in multiplying those duplicities otherwise. Note
that this is a reasonable assumption—duplicities in a Stack have no
defined behaviour in xmonad (X11 can't place a window on a screen
twice), so "fixing" this algorithm is a waste of time.
* X.L.Decoration creates windows which X.H.ManageDocks treats as
possible docks, resulting in extra refresh whenever they appear.
* The extra refresh causes X.L.SubLayouts to multiply the duplicities,
X.L.Decoration to create new decoration windows, and these invalidate
the X.H.ManageDocks strut cache, leading to yet another refresh, and
an endless loop of these.
Having concluded that the no-duplicities assumption is a reasonable one,
there's nothing really to fix here after
<https://github.com/xmonad/xmonad-contrib/pull/621>. Still, the extra
refresh might be causing extra flicker in decorated layouts, and we can
easily avoid it, so I do that here. Plus a bit of documentation for
X.L.SubLayouts.
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
Windows created by X.U.XUtils.createNewWindow have _NET_WM_WINDOW_TYPE =
_NET_WM_WINDOW_TYPE_DESKTOP, which caused checkDock to match them and an
UpdateDocks event to be sent, causing an additional layout refresh
whenever a decoration window appeared.
This could in theory lead to a refresh loop with a layout (modifier)
that dropped and recreated its decoration windows on every
runLayout—which isn't entirely unreasonable, X.L.MouseResizableTile does
it, just luckily happens to not mark its windows as
_NET_WM_WINDOW_TYPE_DESKTOP.
In practice, such a refresh loop could be triggered when buggy
X.A.DynamicWorkspaces (before 929a6a3f6f) duplicated a Window in a
single workspace's Stack, and buggy X.L.SubLayouts then kept duplicating
the duplication (2 → 4 → 8 → …), triggering the creation of new
decoration window in each iteration.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/565
Adds property tests in both directions for the parser in X.U.EZConfig.
As with the tests for X.P.OrgMode, these (modulo `Maybe` noise) take the
shape of the operation of an inverse semigroup:
pp ∘ p ∘ pp ≡ pp and p ∘ pp ∘ p = p,
where pp is pretty-printing and p is parsing.
The keysymToString function prints the key names in pure ASCII; e.g.,
`keysymToString 250` returns "uacute" instead of "ú". This is
undesirable when printing these keysyms in places like visualSubmap.
Thus, move all of the key infrastructure (heh) from X.U.EZConfig to
X.Prelude and look up the name of the key if possible. For better
composability, slightly change the signature for `regularKeys` and the
associated parser.
This changes KeyPress handling in these modules to behave much closer to
how xmonad core itself handles keypresses. The primary difference lies
in that xmonad reads raw KeyCode and then converts it to unmodified
KeySym, while these modules used `lookupString` to find the actual
keysyms. As a consequence, key definitions like `(shiftMap, xK_Tab)`
didn't work on many layouts because an actual KeySym for `Shift-Tab` is
commonly `ISO_LEFT_TAB`, and not `Tab`.
Closes: https://github.com/xmonad/xmonad-contrib/pull/590
Co-authored-by: Tomas Janousek <tomi@nomi.cz>
This replaces the custom `cleanMask` extension in these modules—which
only filtered out XKB group bits and Button5Mask¹—with the new
`cleanKeyMask` which additionally filters out all mouse buttons, as
these aren't relevant for key bindings.
¹) Filtering out Button5Mask was probably an off-by-one mistake.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/290
Related: https://github.com/xmonad/xmonad-contrib/pull/590
We didn't clean XKB group bits out of the KeyPress events' state so key
bindings only worked in the primary keyboard layout (first XKB group).
To fix this, this adds a `cleanKeyMask` function to X.Prelude which is
analogous to `cleanMask` but aimed at cleaning regular KeyPress states
(as opposed to just KeyPresses from passive key grabs), and this is then
used instead of `cleanMask`.
Related: https://github.com/xmonad/xmonad-contrib/issues/290
Related: https://github.com/xmonad/xmonad-contrib/pull/590
There's no reason (other than me forgetting to update the docs when
these add-Hooks were added) to steer users towards the ugly record-based
low-level API.
Add a `visualSubmap` function, which works much like the regular
`submap` one, except that it visualises the available choices in a
pop-up window.
Related: https://github.com/xmonad/xmonad-contrib/issues/472
Adds several new functions and type for manipulating "simple windows".
There are several ways to draw windows in X.U.XUtils and other places
already, but they are all quite manual. Most of the time one does not
want to think about dimensions much and assumes that the code is smart
enough to "figure it out"; this is an attempt to do exactly that.
There is a less-managed version `showSimpleWindow`, which just creates
and shows the windows, as well as a wrapper-like `withSimpleWindow` that
also destroys the window once some action finishes executing.
With these functions it should be possible to refactor some contrib
modules that currently draw windows manually, like X.U.EasyMotion.
This technically introduces a regression with regards to the way that
modifier masks are printed in X.U.NamedActions and X.H.DebugEvents.
However, since this way of printing masks is move in line with
X.U.EZConfig, I personally don't think that this is noteworthy.
Adds event hooks to communicate with trayer or, more generally, with
other tray programs. For convenience, a standard query for trayer is
also provided.
This one isn't actually a personal configuration, it's more like
X.C.Desktop and the other desktop-specific configs. As I happen to
sometimes use it for testing whether everything still works with
decorated layouts, it shouldn't be considered abandoned.
Related: https://github.com/xmonad/xmonad-contrib/pull/679
When users specify non-existent keys, it seems most intuitive to just
abort the parse and not try to take the "longest" input that still
works. For example, given the "key" `M-10` we should signal a parse
error (by returning `Nothing`) instead of parsing `M-1` and ignoring
the rest of the input. The old EZConfig parser accounted for this but
when the module was rewritten to use X.U.Parser in [1], this was
forgotten about.
Fixes: https://github.com/xmonad/xmonad/issues/361
[1]: 8abeb81fd0
Ever since [1] we allow a second representation for the month (namely,
the numerical one). Since we lose this information during parsing,
pretty printing is now not a proper postinverse of parsing (it still is
a proper preinverse, however).
Thus, we can't simply check for an inverse anymore. However, the
operations still form an inverse semigroup [2], which is something
that's easily checkable. For simplicity, do this in both directions and
completely forget about linearity for now.
[1]: 91f1a0de1e (Fix date parsing issue
for org mode plugin)
[2]: https://en.wikipedia.org/wiki/Inverse_semigroup
There are a lot of times when we could already check for "valid" input
during parsing instead of relaying possibly incorrect dates and times to
`org-mode`. This seems like a sensible thing to do—I don't think anyone
would ever want to schedule anything for 35:90 :)
This patch fixes the date parsing issue currently when an entry like
`todo +d 22 01 2022` is used. I have added tests too which demonstrate
the current issue so that we can prevent future regression.
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`
If the user's prompt configuration has a custom `searchPredicate` (e.g.,
`X.P.FuzzyMatch.fuzzyMatch`) the `withWorkspace` prompt should make use
of it (instead of defaulting to an `isPrefixOf`-style matching). For
details see
https://mail.haskell.org/pipermail/xmonad/2021-December/015491.html
Add very basic unit tests for EZConfig to see if it can parse all of the
keys (and key combinations) that it promises to parse.
The long-term goal here should be to write a pretty-printer for EZConfig
and to check whether that's a proper inverse (either in the normal sense
or in the inverse semigroup sense), as the tests for X.P.OrgMode do.
Using X.U.Parser works almost as a drop-in replacement for ReadP here.
In some places (like `parseSpecial`) we need to be a little bit more
careful when constructing the parser, but this is offset a much simpler
`readKeySequence`.
Since we now have an "internal" parser library in xmonad, use it. This
allows us to get rid of some hacks in this module that were needed
because of ReadP's parsing behaviour.
This module provides a parser combinator library based on base's ReadP,
which aims to function more like other popular combinator libraries like
attoparsec and megaparsec.
In particular, the Alternative and Monoid instances are left-biased now,
so combinators like `many` and `optional` from Control.Applicative work
in a more intuitive manner. Further, some functions (like `endBy1`)
only return the "most successful" parse, instead of returning all of
them. We can now get away with providing a single parsing result
instead of ReadP's list of results (as such, parsers need to be
disambiguated earlier instead of trimming the list down after parsing).
This adds basic font-fallback support for X.U.Font, as well as modules
using it, like X.Prompt and X.A.TreeSelect.
In the new system, multiple fonts may be specified with the syntax
"xft:iosevka-11,FontAwesome-9"
Fixes: https://github.com/xmonad/xmonad-contrib/issues/208
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.
The XS.modify was leaving thunk on the history that the demand analyser
could not prove to be neccesary as they depended on the future user
interaction. This was bad as the time advance there was less and less
neccesity to force such value, so the thunk would be increasing. Since the
datatypes that the `WorkspaceHistory` are really simple, we can just
evaluate and save a good chunk of memory.
updateHistory leaks unfiltered windows from previous states as it is never
forced. The consumer of such data structure is not visible to ghc, so the
demand analysis has to fallback on pure laziness.
We fix this inserting evaluation points on the `historyHook` function. We do
this for two reasons, this is the only function calling `updateHistory`.
Plus we cannot do it clearly at the `updateHistory` function as we operate
inside a continuation on withWindowSet. In respect to the `put`, everything
would be a big thunk.
Update left and right navigation to behave correctly even if the
currently saved position is directly on the edge of the focused window.
This makes the L/R behavior consistent with U/D navigation.
How to reproduce the issue on a 16:9 resolution like 1920x1080:
- configure Grid layout;
- open 4 terminals;
- navigate to the top-right terminal;
- open another terminal;
- immediately close it;
- try navigating left from the currently focused top-right terminal;
- observe navigation being "stuck".
The documentation for this module was lacking, making it significantly
harder to use than the functionality wise very similar
X.A.CycleRecentWS—change that.
This changes how the "is*Of" infix operators are hoisted into the
ManageHook context. Instead of `q ~? x` being a lifted version of
`isPrefixOf q x` we instead let it be a lift of `isPrefixOf x q`.
While this obviously does not matter for symmetric operators like `(==)`
and `(/=)`, for `isInfixOf` it is rather essential. The reason for that
is that the given `q` on the left side is an atom that can't (shouldn't)
be changed (by the user) and we only have control over the right hand
side. Otherwise, things like
title ~? "foo"
would read "only match if `title` is an infix of `foo`" instead of the
much more useful "only match if `foo` is an infix of `title`".
Fixes: 8b6f17ba66
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
Move the function from X.U.DebugWindow, where it was defined already.
This is a safe version of getWindowAttributes, returning a Maybe instead
of throwing an exception, in case the window attributes could not be
retrieved.
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.
Instead of telling the user how to add custom keybindings to
xmonad—something which is already done in the tutorial—instead explain
instead how one would go about writing a version of
X.U.EZConfig.additionalKeys. This mostly involves looking at the type
signatures and sticking some standard functions together, so it's quite
a decent way to learn about some of xmonad's internals.
During the release of xmonad 0.17.0, I realized that we need to be able
to upload candidates before tagging the release on GitHub, because there
might be issues with the tarball and Hackage may reject it. When that
happened, I had to remove the release, delete the tag, upload the
candidate manually to see what's wrong with it, try to fix it, upload it
manually again, and so on.
This commit swaps the logic: when the workflow is invoked manually, it
uploads the candidate. This can be done multiple times, and once
everything is fine, the release can finally be tagged and it's released
to Hackage proper. The only disadvantage is that we need to remember to
try uploading the candidate. Not sure if there's a perfect solution…
It no longer does what it was intended to do, and in fact, now does the
opposite.
When X.A.Search came to be in ~2007, Google's default of showing 10 or
so search hits was radically inadequate for poweruser needs. The 'num'
argument was used to force display of more hits (i.e., n meant 'display
at least n hits per page').
However, at some point, 'num' was inverted to mean something
catastrophically different: now it apparently means 'display no more
than n hits, total'. If you use that parameter, you will get 1 or 2
pages of hits at most reading 'About 98 results' or 'About 99
results' (no matter how many millions are available), and a blurb at the
bottom of the final page saying 'In order to show you the most relevant
results, we have omitted some entries very similar to the 99 already
displayed.' Removing the 'num' parameter then shows you all the hits
that were suppressed.
This is bad, and should be removed.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/642
Co-authored-by: Gwern Branwen <gwern@gwern.net>
ConfigureEvents may occur after a window has been deleted, an UnmapEvent
has already been sent (and thus xmonad already unmanaged the window),
but before a DestroyWindowEvent is caught by the eventHook. For
example, this is the case when one uses smartBorders with a single
window (such that smartBorders is "active"). The ConfigureEvents
sensibly already have an empty stack (because the UnmapEvent has already
been received), which we then copy to the history.
Whenever a parent window has been found, the sensible thing to do is to
always restore it. The fact that oldStack is Nothing simply encodes an
empty workspace and is thus something we definitely need to handle as
well.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/638
In [1] we changed the return type to not be an IO action and hence this
example can't work, even with an otherwise correct configuration.
[1]: 168cb6a6c3 (Removed unnecessary IO)
Since the tutorial is really the better place to start learning how to
use xmonad, X.D.Extending can be the place for more "advanced" usage
examples. These would be things like writing small functions to scratch
an itch (rather than entire modules). Rewrite the introduction
accordingly.
On the way, remove some small inconsistencies/dead links/remarks about
how things are different from version 0.5 onwards—these times are long
gone now.
The configurations on the wiki are quite old and mostly non-functional
at this point. Instead, we have a shiny new tutorial we can refer to.
It contains links to actual maintainers configurations (complex they may
be, at least they compile).
This was temporarily disabled in 229d52ff07 and 086db3123b because we
couldn't keep xmonad-contrib backwards compatible with xmonad 0.15 any
more, but xmonad 0.17.0 is out now and we can try to stay compatible for
a while.
Using `ppPrinters` with `WorkspacePredicate` and `WorkspaceFormatter`
allows users to define custom workspace types, beyond the ones
integrated in PP (i.e. urgent, current, visible, visible with no
windows, hidden, and hidden with no windows). `WorkspacePredicate`s are
added for these predicates (`isType`) with unsafe versions that assume
that predicates with a higher precedence already faield `isType'`.
`WorkspacePredicate`s can also be combined and modified with `notWP`,
`andWP`, and `orWP`.
Related: https://github.com/xmonad/xmonad-contrib/issues/557
Co-authored-by: Tomáš Janoušek <tomi@nomi.cz>
The CONTRIBUTING.md file for xmonad now has style guidelines [1]. Since
X.D.Developing does not add anything new here and we direct new
contributors to CONTRIBUTING.md anyways, simply refer to the relevant
section.
[1]: bc8f7ff133
* The Haddock documentation is a very good resource for the general
markup syntax.
* Since we are very biased in favour of stack, document how to build
Haddock docks with it.
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")
I've tested these manually by adding them to extra-deps. Hopefully
they'll soon be available in a release of GHC or Stackage, so I'm not
adding an extra stack.yaml to test this.
We install GHC using apt, so stack shouldn't install it, but should it
ever end up installing it anyway (version mismatch, version unavailable
in hvr/ghc ppa, …), we don't want it wasting valuable cache space.
Currently, all contrib modules are licensed under a 3-clause BSD license
anyways. The term "freer" is quite confusing and may even refer to
several (non-BSD) licenses, depending on the authors sensibilities.
* "community-maintained" is more accurate and sounds better than "third-party"
* refresh description
* add logo and badges to make it prettier
* update doc links
This will make it easier to transition to an implementation of EWMH that
doesn't expose the individual hooks: X.H.ManageDocks would become a
deprecated compatibility reexport of X.H.EWMH.Struts for a release or
two, but the individual hooks need to be removed before that.
Note that individual hooks in X.H.EwmhDesktops were deprecated earlier
and individual hooks in XMonad.Hooks.UrgencyHook aren't exported any
more (or perhaps never been), so this only leaves X.H.SetWMName, which
unfortunately does not have a combinator interface at this point.
Related: https://github.com/xmonad/xmonad-contrib/pull/625
* 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.
https://github.com/xmonad/xmonad-contrib/pull/192 introduced a breaking change:
* `XMonad.Hooks.EwmhDesktops`

 `ewmh` function will use `logHook` for handling activated window. And now
 by default window activation will do nothing.
This breaking change can be avoided if we designed that a bit
differently. #192 changed `ewmhDesktopsEventHook` to invoke `logHook`
instead of focusing the window that requested activation and now
`logHook` is supposed to invoke a `ManageHook` through `activateLogHook`
which consults a global `NetActivated` extensible state to tell if it's
being invoked from `ewmhDesktopsEventHook`. This seems convoluted to me.
A better design, in my opinion, is to invoke the `ManageHook` directly
from `ewmhDesktopsEventHook`, and we just need a way to configure the
hook. Luckily, we now have `X.U.ExtensibleConf` which makes this
straightforward. So we now have a `setEwmhActivateHook`, and the
activation hook defaults to focusing the window, undoing the breaking
change.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/396
Related: https://github.com/xmonad/xmonad-contrib/pull/110
Related: https://github.com/xmonad/xmonad-contrib/pull/192
Related: https://github.com/xmonad/xmonad-contrib/pull/128
Now that we have `XMonad.Util.ExtensibleConf`, users can comfortably use
the `ewmh` combinator and still customize workspace ordering, filter out
scratchpads and expose altered workspace names.
To make this all work nicely, we introduce not one, but two
configuration options: a sort/filter function and a rename function.
This is because renaming and sorting in one go makes it hard (perhaps
even impossible) to decide which workspace to switch to upon receipt of
a _NET_CURRENT_DESKTOP request from a pager or wmctrl/xdotool. (The only
reason this wasn't a problem before is because one could pass the
renaming function to `ewmhDesktopsLogHookCustom` only, not
`ewmhDesktopsEventHookCustom`, which is a confusing hack as can be seen
in the related closed pull requests.)
Related: https://github.com/xmonad/xmonad-contrib/pull/238
Related: https://github.com/xmonad/xmonad-contrib/pull/105
Related: https://github.com/xmonad/xmonad-contrib/pull/122
For configuration values that don't compose well using a Semigroup
instance, provide a high-level API allowing arbitrary modification of
the value, taking its Default if absent. This API is only usable for
separate configuration data and cannot be used to guard addition of hook
using `once`.
This better matches the documentation.
It is still, however, considered bad practice to rely on the order of
these operations. `f` isn't meant to touch any extensible configuration.
If it happens to do so anyway, it no longer loops. :-)
Unless specified otherwise, operators in Haskell associative to the
left. However, the ergonomics of (!>) heavily lean towards the left
operand being a "single" search engine, not a combined one.
This causes trouble when not using `multi` or defining search engines
with a right fold, but (following the documentation) writing something
like
multiEngine = intelligent (wikipedia !> mathworld !> (prefixAware google))
instead. This particular definition would force the user to write
`wikipedia/mathworld:wikipedia:search-term` instead of just
`wikipedia:search-term` to access the first search engine.
Simply giving (!>) an explicit associativity fixes these problems.
When removing a workspace and distributing its windows, it's important
to remove any duplicates that may be there due to, for example, usage of
X.A.CopyWindow. X will only draw one of these window, leading to some
artifacts.
Related: https://github.com/xmonad/xmonad-contrib/issues/565
Co-authored-by: Tomas Janousek <tomi@nomi.cz>
When there is a directory and a file in $PATH of the same name `foo`, we
display `foo`, as well as `foo/` in the prompt, but selecting either one
of them will invariably run or raise the directory, as this test is done
beforehand.
Since directories already carry a trailing forward slash from the shell
prompt's `getShellCompl`, this is easily disambiguated by incorporating
an additional check.
It is duly noted that the same problem also exists for files in the
current directory. This could be fixed in a similar way (adding a
unique suffix to files and checking for that), but since this would
involve changing `getShellCompl` and no-one has complained about this so
far, it was deemed "not worth it" for now.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/616
XMonad.Hooks.UrgencyHook knows how to understand this hint, but it's
not advertised as supported via _NET_SUPPORTED. This prevents certain
applications (e.g. kitty terminal emulator) from using it.
So far, we have used the `D` tuple, as defined in X.Operations, for
these. However, `D` uses `Word32` for its components, which are not
supposed to carry negative values.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/578
Utilise EZConfig's Emacs style syntax for entering the prefix key.
The syntax has been well-established for use in configuration files;
especially in this case it can be a bit awkward having to specify a
function that takes a config just for a single keybinding.
X.D.Extending claims to index all of the contrib library, but this was
not really the case. While most modules where indeed indexed, some
notable ones were missing from this list. Since we're pointing users to
this quite prominently, this is something that needs to be fixed.
* X.A.Search: Update/Remove outdated URLs, add GitHub
- The `codesearch`, `openstreetmap`, and `thesaurus` searches were
using old URLs; update those.
- Remove the now defunct isoHunt serach.
- Add a search for GitHub.
* X.A.Search: Change http to https
- The `codesearch`, `openstreetmap`, and `thesaurus` searches were
using old URLs; update those.
- Remove the now defunct isoHunt serach.
- Add a search for GitHub.
This adds the function `killOthers`, which kills all unfocused windows
on the current workspace.
As discussed in the PR itself [1], the module suffix `WithAll` is not
quite optimal at this point, as we are acting on window _groups_ and not
necessarily just all window on a workspace. However, in order to keep
this commit atomic, this consideration is postponed until another day.
[1]: https://github.com/xmonad/xmonad-contrib/pull/602
Currently when creating an XMonad Prompt one is stuck with "XMonad:" as
the title for the prompt. However, sometimes it is nice to be able to
create a prompt with custom commands that has a particular title.
This changes the internals of X.P.XMonad to facilitate this and adds
xmonadPromptCT as a user facing function.
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)
This works like logTitles, but gets an explicit screen to log the window
titles on. This may be useful when having status bars for each screen
that show all windows on their respective visible workspaces.
It is already possible to "start" from $HOME by specifying a relative
directory (one starting without a starting slash). However, it is often
nice to be explicit about this by writing `~/' directly—support this.
So far, while parsing strings like "<ptn><more-letters>", the `getLast`
function immediately stopped on strings of the form "<ptn><whitespace>".
This may be a bit confusing given the functions name. Strings of
the—perhaps artificial—form
"a +d f 1 +d f 2"
would be cut short and parsed as
Deadline "a" (Time { date = Next Friday, tod = Just 01:00 })
instead of the more intuitive
Deadline "a +d f 1" (Time { date = Next Friday, tod = Just 02:00 }).
This is readily fixed by applying the `go` parser as often as possible,
only returning the longest list, and then pruning eventual leftovers at
the end of the string. Since we were already invoking `dropWhileEnd` to
trim whitespace before, the added `reverse`s should not impact
performance at all.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/584
With "nix build", just the build of xmonad-contrib itself takes 3
minutes (it builds twice, the second build with profiling enabled), so
it ends up being almost 6 minutes in total, making this workflow the
slowest one.
Some people like their mouse pointer to move when changing focus with
the keyboard, other people like their pointer to stay and focus to
follow. xmonad(-contrib) supports both preferences, but imperfectly:
The former requires using the XMonad.Actions.UpdatePointer contrib
module, the latter (focusFollowsMouse) only reacts to CrossingEvent; the
focus isn't updated after changing workspaces or layouts.
This adds an inverse of XMonad.Actions.UpdatePointer.updatePointer that
immediately updates the focus instead.
Fixes: https://github.com/xmonad/xmonad/issues/108
When `runProcessWithInput` is invoked immediately after
`ungrabPointer`/`ungrabKeyboard`, we don't actually ungrab at all
because `runProcessWithInput` blocks and the ungrab requests wait in
Xlib's queue for a requests that needs a queue flush.
Common uses of `unGrab` (before `spawn`) aren't followed by a blocking
action, so the ungrab requests are flushed by xmonad's main loop, and
this is merely a timing issue—fork/exec takes a while and xmonad
probably manages to get back to its main loop in time. Uses of
`runProcessWithInput` in ordinary non-submap key bindings happen to work
because key bindings are passive grabs—the grab is released by the
user's fingers releasing the key itself, even if xmonad's ungrab
requests are stuck in a blocked queue. Submap key bindings, however,
take an active grab and therefore need to ungrab explicitly.
Easy fix—explicit `sync`.
Fixes: https://github.com/xmonad/xmonad/issues/313
This implements window swallowing on top of SubLayouts; the matched
windows are simply tabbed together instead of one actually being
swallowed. This provides an improved experience for people using
SubLayouts, as the parent window is still accessible.
Done as part of ZuriHac 2021.
Related: https://github.com/xmonad/xmonad-contrib/issues/416#issuecomment-777400194
Before https://github.com/xmonad/xmonad/commit/383ffb7 this would
bind all unbound keys to toggle struts; after it, it would bind no
keys at all. With this commit, it will check for this case and use
the default keybinding instead.
Users who intend no key to be bound should probably use `withSB`
instead, especially in light of aforementioned commit.
Due to differences between random-1.1 and random-1.2, on newer systems
stringToRatio returns numbers outside [0, 1] range, which breaks
colorRangeFromClassName colorizers.
This commit fixes the issue by using randomR to directly generate the random number.
Also this fixes the compilation warning (genRange and next are deprecated in random-1.2).
This adds a new logHook, nsHideOnFocusLoss, that hides the given
scratchpads when they lose focus. This is akin to the functionality
provided by a lot of dropdown terminals.
This exports the `withRecentsIn` function, as it's quite useful when
using X.H.RefocusLast in other modules as a library.
It is already possible (RecentsMap is fully exported) to completely
define this function outside of the module, so we are not exposing any
more internals than we were before.
By deprecating everything except `WSIs` and adding constructors to
logically combine `WSType` values, we can have a more flexible interface.
Adding anything to the old interface would mean going through `WSIs`, and
all old constructors can be implemented of terms of `WSIs`.
When we applied hlint hints in bd5b969d9b,
the definition of desktopLayoutModifiers got (via the hint to eta
reduce) changed from
desktopLayoutModifiers layout = avoidStruts layout
to
desktopLayoutModifiers = avoidStruts
While the former is general enough to infer the type signature
LayoutClass l a => l a -> ModifiedLayout AvoidStruts l a
the latter just sees the usage site of
, layoutHook = desktopLayoutModifiers $ layoutHook def
in the desktopConfig function and thus—through the magic of
MonomorphismRestriction—infers the specialized type
Choose Tall (Choose (Mirror Tall) Full) Window
-> ModifiedLayout AvoidStruts
(Choose Tall (Choose (Mirror Tall) Full)) Window
This obviously completely falls apart once someone wants to change the
layout and still uses desktopLayoutModifiers (unaware that it is just
avoidStruts at the moment). The easy fix is to give things type
signatures, so nothing needs to be inferred.
The _actual_ solution would be, in my opinion, to completely deprecate
X.C.Desktop and remove it in a future release, as well as to completely
rewrite the provided Example.hs. This needs more deliberation though.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/560
Related: bd5b969d9b
This is for disambiguation purposes. Otherwise, there is no way to
decide whether
message +s 17 jul 12
wants to schedule the note for the 17th of july at 12:00, or for
the 17th of july in the year 12. The easiest way around this is to
stipulate that people want to make these notes for the future more
often than not and to simply prohibit note before the year 25 (as that
is where the valid times end).
Instead of trying to find a prefix and then killing the rest of the
word, actually see whether it at least fits the pattern. This means
that
message +s saturated
will no longer parse as a scheduled item for saturday, while
message +s satur
still will.
If we have a URL in the clipboard and we use `orgPromptPrimary`, it
would be nice if
message +s 11 jan 2013
would result in
* TODO [[_URL_][message]]
SCHEDULED: <2013-01-11 Fri>
instead of the current
* TODO message
SCHEDULED: <2013-01-11 Fri>
_URL_
This has the advantage that if one shows scheduled or deadlines items in
the org-agenda, it is possible to immediately follow this link with
`C-c C-o` or similar functionality.
The URL detection is very rudimentary right now. One use `parseURI`
from `network-uri`, but that would be an additional dependency that I
didn't think was worth it.
This implements whitespace pruning at the end of a sheduled item or
deadline. If we have a message like
This is a message +s today
it is expected that we created a heading of just "This is a message",
without the extra whitespace.
This is a function that takes a pretty-printer and makes it aware of
copies of the currently focused window. This is particularly nice when
using it with a StatusBarConfig.
Related: https://github.com/xmonad/xmonad-contrib/pull/463
- 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
At the moment, we re-calculate the prompt width every time we want
to (re)draw the prompt window. This is unnecessary, as the screen
dimensions or the preferred position changing _while the prompt is
active_ is extremely unlikely.
This now calculates the desired width at the start of the prompts event
loop and threads it through to the places that need it.
While it is true that we need an IORef complWin in case of an exception,
so the window can be destroyed correctly, we do not need its non-IORef
counterpart at all.
When we need to access the complWin it's undoubtably when we want to do
_something_ with regards to window management; these things naturally
live in `XP ()` and so there's not loss of purity with this change.
We do want to ignore some hints.
Currently this is:
- Evaluate: Some type level magic sometimes requires us to write
expressions that could be evaluated further, but should not.
Related: https://github.com/xmonad/xmonad-contrib/issues/537
This isn't true since 63e31ccd8d, `xmonadPropLog'` does the encoding
now and accepts a normal Haskell String now.
Fixes: 63e31ccd8d ("X.H.DynamicLog: Move UTF8 encoding from dynamicLogString to xmonadPropLog'")
The new X.H.Rescreen provides a simpler composable API for hooking into
rescreen. Unfortunately it also breaks other code that listens for
RRScreenChangeNotifyEvent, so this conversion isn't really optional.
Not that there's any dispute this is nicer, is there? :-)
This appears to be more natural. The function will most often be fixed
by the module using `XC.once` and the configuration will often be
supplied by users of those modules, so it's better to partially apply
the function first.
`statusBarGeneric`: A generic `StatusBarConfig` that launches a status
bar but takes a generic `X ()` logging function instead of a `PP`. This
has several uses:
* With `xmonadPropLog` or `xmonadPropLog'` in the logging function, a
custom non-`PP`-based logger can be used for logging into an `xmobar`.
* With `mempty` as the logging function, it's possible to manage a status
bar that reads information from EWMH properties like `taffybar`.
* With `mempty` as the logging function, any other dock like `trayer` or
`stalonetray` can be managed by this module.
Related: https://github.com/xmonad/xmonad-contrib/pull/463
statusBarPipe abuses the interface of StatusBarConfig by starting the
status bar before the startupHook. This worked correctly before, but it
does not play will with `dynamicSBs`
Entirely unnecessary for the current version of `cycleWindowSets`, but
if anyone ever wants to use `greedyView`, this shows that it's not at
all complicated to adapt `unView` to that.
To make this more "obviously correct", make it resemble the `view`
implementation, just do the exact reverse. Now the only complex bit is
the "undelete" operation.
This also fixes another issue: state was only preserved in the focused
workspace, but it may have changed in another visible workspace as well.
The property test is updated to test this.
The way that workspace cycling is implemented right now—by generating
new windowsets where the things we want happen to be true and then
replacing the old windowsets—is not safe, as workspaces and layouts may
carry state with them. That state will get lost in translation when
windowsets are simply replaced.
As an example, a conflict occurs when using `X.L.ShowWName.showWName` in
one's layoutHook. When cycling through workspaces via, e.g.,
`cycleRecentWS` the flashed workspace tag will not disappear, as the
necessary state to control this isn't present in the new windowset.
Instead, what we want to do is to keep the "current" windowset alive and
actually switch to the requested workspaces. This mostly works without
much trouble, the only hard part is maintaining the invariant that
previewed workspaces don't count towards the history of recently-viewed
workspaces. This is done by remembering the tag-order of the original
windowset and then restoring that at the end.
This is a breaking change, insofar as it changes the type signatures of
the exported functions `recentWS`, `cycleWindowSets`, and
`toggleWindowSets` to return a list of `WorkspaceId`s instead of a list
of `WindowSet`s.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/504
It's often difficult to make contrib modules work together. When one
depends on a functionality of another, it is often necessary to expose
lots of low-level functions and hooks and have the user combine these
into a complex configuration that works. This is error-prone, and
arguably a bad UX in general.
This commit presents a simple solution to that problem inspired by
"extensible state": extensible config. It allows contrib modules to
store custom configuration values inside XConfig. This lets them create
custom hooks, ensure they hook into xmonad core only once, and possibly
other use cases I haven't thought of yet.
This requires changes to xmonad core: https://github.com/xmonad/xmonad/pull/294
A couple examples of what this gives us:
* [X.H.RescreenHook](https://github.com/xmonad/xmonad-contrib/pull/460)
can be made safe to apply multiple times, making it composable and
usable in other contrib modules like X.H.StatusBar
* `withSB` from X.H.StatusBar can also be made safe to apply multiple
times, and we can even provide an API [similar to what we had
before](https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/XMonad-Hooks-DynamicLog.html#v:statusBar)
if we want (probably not, consistency with the new dynamic status bars
of https://github.com/xmonad/xmonad-contrib/pull/463 is more important)
* The [X.H.EwmhDesktops refactor](https://github.com/xmonad/xmonad-contrib/pull/399)
can possibly be made without breaking the `ewmh`/`ewmhFullscreen` API.
And we will finally be able to have composable EWMH hooks.
Related: https://github.com/xmonad/xmonad/pull/294
Decoration windows are created using XMonad.Util.XUtils.createNewWindow
which happens to set _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_DESKTOP,
and ManageDocks considers such windows candidates for struts and
therefore requests property events, thus overriding the original event
mask requested by decorations.
The fix is to first obtain the current event mask, set the required bits
in it only then reset the mask.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/517
Fixes: ec14617123 ("X.H.ManageDocks: React to strut updates of override_redirect docks")
Related: https://github.com/xmonad/X11/pull/77
command specific
- The names were awfully long. spawnStatusBar and killStatusBar are
perfectly fine alternatives.
- It's more flexible to have killStatusBar command specific. Also added
killAllStatusBars to provide the old functionality
This prevents an unnecessary refresh.
That refresh would normally be harmless but it does reset the input
focus, which happens to upset some non-conforming clients such as
https://github.com/flameshot-org/flameshot. Flameshot is an interactive
screenshot tool that creates an override-redirect fullscreen window to
let the user select a rectangle to capture and then allows drawing and
adding text and so on, but it unfortunately doesn't follow ICCCM
recommendations:
> If it is necessary for a client to receive keystrokes on an
> override-redirect window, either the client must grab the keyboard, or
> the client must have another top-level window that is not
> override-redirect and that has selected the Locally Active or Globally
> Active focus model.
Instead, it just takes input focus and hopes for the best. And it also
sends an entirely useless _NET_WM_STATE_FULLSCREEN request, which would
trigger a refresh and take that focus away.
This commit works around that by not handling that useless
_NET_WM_STATE_FULLSCREEN for unmanaged windows and thus preventing that
refresh. It's just a workaround, however: if a legitimate refresh is
necessary at any point, the focus _will_ be taken away.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/550
Fixes: https://github.com/flameshot-org/flameshot/issues/773
xmobar allows you to define a list of additional fonts (additionalFonts) and to use the fn tag to choose between them. xmobarFont is essentially the same as the xmobarColor function, but for fonts.
Building xmonad-contrib benefits greatly from compiling modules in
parallel. Vanessa McHale suggested setting ghc-options in
xmonad-contrib.cabal in #431, but that's bad practice—these options
should be set by the user/environment where it's being built, not
selfishly hardcoded for specific package. In stack.yaml and
cabal.haskell-ci, we know for sure that xmonad-contrib is the terminal
(leaf) library, so we can set it there and speed up builds in our CI and
also for anyone who uses our stack.yaml (not that anyone should).
Closes: https://github.com/xmonad/xmonad-contrib/pull/431
Turns out `commit: master` doesn't really mean latest master, because
it's cached. It sometimes works, because when the GHA cache comes from
a job that depended on xmonad-0.15, then the master archive isn't cached
and is fetched. When the cache comes from a job that previously fetched
master, it's not fetched again.
The least ugly way to fix it I found is to use the `[<refname>]@{<date>}`
git revision format, and substitute current date/time before invoking
stack. To make stack-master.yaml valid without the substitution, we use
`master@{today}` which is a valid git revision that GitHub understands.
GitHub Actions writes caches on the first miss and then never updates
them again. If the CI is used frequently, the caches never expire and
as they get old, become less useful.
To avoid this, force refreshing the caches once a month.
When building with an LTS version that has exactly the dependencies we
need (xmonad-0.15), stack doesn't need to download the Hackage index. If
GitHub Actions cache locking chooses this job as the one that writes the
cache, then the "stack-pantry-Linux" cache entry stays empty, possibly
forever.
Force Hackage index update to prevent this from happening.
This further reduces our usage of cache storage by caching the metadata
only once per repo. Now the metadata cache is ~250MB and the individual
caches with built dependencies are ~10M each.
Related: cfe99998fc
Related: https://github.com/xmonad/X11/pull/75
Stack installation of GHC takes more than a gigabyte, so caching it
wastes space (GitHub docs say it will be aggressively evicted after
reaching the 5G limit) and also time (compression, decompression).
Related: 9fce3805fc
Related: a5cee9bac2
Related: https://github.com/xmonad/X11/pull/75
Drop nightly and lts-15: they don't add GHC versions to the matrix and
new deps are better tested in the haskell-ci (cabal) workflow.
There's also little point in testing against both xmonad 0.15 and xmonad
master with all LTS versions. Drop most of those, reduces GitHub cache
and CPU time usage.
Related: fd243ca1c1
Related: https://github.com/xmonad/X11/pull/75
Last released xmonad doesn't build with GHC 9.0 and haskell-ci doesn't
let us tweak the test matrix easily. Let's hope the stack.yml workflow
is sufficient to test backward compat.
Related: 2a1a18023a
Current version of Steam sends _NET_ACTIVE_WINDOW ClientMessage for
every mouse click which results in a lot of border blinking.
Ignore requests that would result in no change to get rid of the
annoying border flicker that is inevitable with the current
implementation of XMonad.Operations.windows.
(Note that Steam also sends ConfigureRequest events, and these cause
an additional refresh due to the call to `float` when handling the event
in xmonad core. Not sure if worth fixing.)
Related: https://github.com/xmonad/xmonad-contrib/pull/371
Related: https://github.com/xmonad/xmonad-contrib/pull/399
- Only suggest the usage of TopicItem; this is much easier to work
with and essentially a straight upgrade to the old method.
- Use a more stripped-down example so we don't confuse beginners more
than necessary (though this is still not optimal).
Add the convenience type `TopicItem`, for easier (and safer!)
specification of topics, as well as several small helper functions to
help users work with it.
* `X.A.DynamicWorkspaceGroups`: TopicSpace support
This adds `viewTopicGroup` and a corresponding prompt. This is similar
to `viewWSGroup`, but it calls `switchTopic` instead of `W.greedyView`,
inorder to run the topic action on the workspace.
These past months I've spent a lot of time working on xmonad and I feel
like I've done a lot. This is, however, not sustainable long term. :-(
I'd like to try making my GitHub Sponsors profile a bit more visible,
hoping that would allow me to continue dedicating time to xmonad.
I know that the correct approach probably is for the xmonad project to
find a fiscal sponsor like the Software Freedom Conservancy or Open
Collective or something and accept donations as a project, and then
redistribute that to people, but I don't think the project has enough
momentum to do something as complicated as that. :-/
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.
Turns out similar logic is already in updateGroup, and we don't even
need to worry about extra/missing windows and we can just differentiate
the result of reordering.
This makes the following sequence of operations idempotent, as it should be:
windows $ W.float w $ W.RationalRect 0 0 1 1
windows $ W.sink w
Previously, any window not visible to the SubLayout modifier (xmonad
invokes runLayout with tiled windows only) would be reordered to the end
of stack. This commit changes the reordering logic to only reorder
windows in Groups and keep all other windows where they were.
- We would really like a full template and not just a snippet where
we'll have to guess the context.
- It's generally nice to know which versions of xmonad and contrib a
users was using when encountering an issue.
We're not parsing anything (as opposed to the respective `P` functions)
and so there's no need to create a dummy map with units as values and
then take the difference; we can simply remove the relevant keys from
the map.
A new prompt that works like 'safePrompt', but is optimized for the
use-case of a program that needs a file as an argument.
This is necessarily a new function and can't just be achieved by using
the old `safePrompt`, as `getShellCompl'` does not at all filter the
files (compgen already does that based on the input), but only the
available commands. If we start the prompt with a single command then
the chosen `searchPredicate` becomes quite useless and we can't take
advantage of fuzzy matching for file finding. This, however, is quite
useful when having a program that explicitly expects a file as one of
its arguments, e.g. dragon [1].
What we have to do instead of to generate all available files with
compgen and _then_ filter this down to what we want via a given
function. In order to make this change backwards compatible we have to
introduce the rather ugly `shellComplImpl`, which takes a laundry list
of all of the different parameters that we need. Since the function is
not exported, this ugliness does perhaps not matter too much.
[1]: https://github.com/mwh/dragon
When `alwaysHighlight` is enabled and one immediately presses (by
default) Return after opening the prompt (because the highlighted
completion is what one wants) then the selection will not enter the
prompt history. Instead, an empty string will be entered because there
hasn't been any input yet and hence the `highlightedCompl` field has not
yet been filled in.
The fix is simply checking whether `alwaysHighlight` is set during
startup and, if yes, already setting the highlighted completion to the
first suggestion.
This builds upon the idea of 780360abf0
but it fixes the issue in a bit of a nicer way; instead of throwing an
exception and closing the prompt, we simply check if there is only a
single completion available inside `hlComplete` directly.
While what 780360abf0 said is true insofar
that we have incomplete information when inside `hlComplete`, this does
not actually matter in this case. We have access to the complete user
input (possibly consisting of things not from this round of completion),
which is enough here.
Fixes a bug introduced in f2cfaa3398.
The changes there allowed the prompt to cycle through its input; it now
becomes necessary to single out the case of only having a single
suggestion that's also highlighted. Otherwise, `hlComplete` (condition:
`alwaysHighlight` is enabled) will loop forever. This case can't be
handled from within hlComplete, as we are giving it incomplete
information to start with (by only calling it with the last word of the
current completion in `handleCompletion`), which is necessary for things
like completing arguments.
This applies for withSB and withEasySB, as well as statusBarProp and
statusBarPropTo, making composability better. statusBarPipe is more
awkward to use now, but that's fine
- XMonad.Hooks.DynamicLog.PP: the pretty-printing abstracion, with the
corresponding utilities
- XMonad.Hooks.StatusBar: A new module to provide a better interface to
manage external status bars.
This more general function subsumes (almost) all previously known
combinators in this library (it is still symmetric with regards to
magnification, as this is what most users want). Also export some
previously internal (but not crucial to the implementation) types to
make this possible.
This ports DynamicIcons to the recently introduced ppRename mechanism,
which means DynamicIcons can now safely be combined with clickablePP,
workspaceNamesPP and marshallPP.
This also fixes DynamicIcons not working properly with urgent workspaces
due to forgotten ppUrgent counterpart in data Icon. Also,
ppVisibleNoWindows wouldn't work properly.
The code is now considerably simpler, but we lost the ability to use
different icons depending on whether the workspace is
visible/hidden/urgent/etc. If anyone needs that, it can be worked around
by using some markup that is later interpreted in
ppVisible/ppHidden/ppUrgent/etc.
Related: https://github.com/xmonad/xmonad-contrib/pull/481
Move all the workspaces and icon generation logic into getWorkspaceIcons
and drop the Maybe which is no longer necessary since we made the
formatting logic configurable.
Related: https://github.com/xmonad/xmonad-contrib/pull/450
Make it possible to keep workspace id in the output (iconsFmtAppend) and
to wrap icons even if there's just one, or zero.
Also, change the default to use curly brackets to avoid confict with
brackets/parentheses used by default PPs in DynamicLog.
Related: https://github.com/xmonad/xmonad-contrib/pull/450
The silent error `user error (createFontSet)` would break certain
modules (like the prompt) by simply not showing anything.
Pango 1.44 dropped support for FreeType in favor of HarfBuzz, losing
support for traditional BDF/PCF bitmap fonts. Hence, some distributions
don't ship `xorg-fonts-misc` anymore.
Fixes https://github.com/xmonad/xmonad-contrib/issues/348
We only requested PropertyChange events from docks in the `manageDocks`
manageHook, but that only gets called for normal windows, not
override_redirect ones. Therefore, xmobar in its default configuration
wouldn't get its struts refreshed on changes. This resulted in gaps not
updating after xmobar repositions itself on xrandr changes.
If one wanted to handle that repositioning in xmonad, it was possible to
configure xmobar with `overrideRedirect = False`, which is meant for
window managers with proper EWMH stacking order support [1], so in
xmonad it resulted in xmobar covering fullscreen windows. That can be
worked around by adding `checkDock --> doLower` to manageHook, but it
starts to smell of too many workarounds.
[1]: https://specifications.freedesktop.org/wm-spec/wm-spec-1.5.html#STACKINGORDER
The fix is to request PropertyChange events for all windows that we
treat as docks.
Related: https://github.com/xmonad/xmonad-contrib/pull/490
This is primarily a cleanup to make it easier to use `setDocksMask` from
the on-demand cache init (see further commits), but it makes the code
nicer:
- the logic to refresh and cache a strut is now concentrated in
`updateStrut` instead of being spread over `updateStrutCache` and
`docksEventHook`
- the logic to initialize the cache if not yet initialized is now
concentrated in `maybeInitStrutCache` instead of being spread over
`initStrutCache` and `getStrutCache`, so the dual-purpose return type
of `getStrutCache` is no more
- the logic to detect changes and refresh is now always handled by
`XS.modifiedM` instead of an additional `||`
Related: https://github.com/xmonad/xmonad-contrib/pull/406
Ever since ce5aae5403 TopicSpace uses the
history implementation of X.H.WorkspaceHistory instead of something
hand-rolled. This, however, did not go far enough; at this point, we
can deprecate essentially all of TopicSpace's redundant history handling
and explicitly tell users to use the more modular X.H.WorkspaceHistory
instead.
For many (10+) years, we had a cascade of ugly workarounds:
* X.U.Run.spawnPipe returned a binary handle, so the String passed to
it must have been encoded by C.B.UTF8.String.encodeString
* X.H.DynamicLog.dynamicLogString therefore returned such an encoded
String, so one could use it directly in a hPutStrLn, but literal
Strings wouldn't work
* xmonadPropLog' also expected an encoded String to make it easier to
use together with dynamicLogString, again breaking usage with String
literals and other normal unicode Strings
Then in 1d0eaddc25 Sibi fixed spawnPipe to return a handle usable with
normal Strings, which then obviously broke the entire cascade. But,
instead of using the opportunity to remove all the ugly workarounds, he
decided to add some more on top, so now spawnPipe with dynamicLogString
outputs doubly encoded UTF-8 and xmobar has a hack to strip this double
encoding (https://github.com/jaor/xmobar/pull/482), which only works
when XFT is in use and breaks on some long unicode codepoints. :-(
There is a better way: make everything just use normal Strings and only
encode when it goes out the wire. This means dynamicLogString can be
freely mixed with String literals, manual uses of xmonadPropLog' don't
need encodeString, and everything just works nicely.
This obviously breaks configs that used some of these pieces in
isolation (like mine), but that's a small price to pay. After all, right
now all users of spawnPipe/dynamicLogString are getting doubly encoded
UTF-8 which might or might not work in xmobar and probably breaks
horribly everywhere else, so this fix should be a clear improvement. :-)
Fixes: 1d0eaddc25 ("Make spawnPipe to use system's locale encoding")
Fixes: https://github.com/xmonad/xmonad-contrib/issues/377
Fixes: https://github.com/jaor/xmobar/issues/476
Related: https://github.com/xmonad/xmonad-contrib/pull/334
Related: https://github.com/jaor/xmobar/pull/482
This makes it easier to see the differences between these functions,
makes it less likely someone will change one and not the others, etc.
More importantly, the documentation doesn't contain circular references
any more. :-)
Also, let's just use hSetEncoding. The concern of this being stateful
and theoretically having something written in the wrong encoding is
pointless: nobody has the handle until we return it from `spawnPipe'`.
(This also means that spawnPipeWithNoEncoding is now a text handle that
possibly does newline translation, just with char8 encoding. There
should be no difference in practice.)
Fixes: 8b2bd3ae5c ("Add new variants of spawnPipe functions with encoding support")
This breaks putting <fn> tags and icons into workspace names, which some
people might like. Those few who generate workspace names dynamically
from window titles may (and should) escape it themselves.
* New logout options
Factor out Mate logout action and add a shutdown action which the user can bind additionally or in its place.
* Add documentation
* Update CHANGES.md
Short-circuiting the search isn't worth the code complexity, so just
search for all windows with the same leader and then pick the first one
using `listToMaybe` and pass that to `doShiftTo`.
Also, rename to `shiftByLeader` because we aren't really shifting to the
leader itself. We just shift to another window that has the same leader.
Will be useful for shiftToLeader.
Use W.shiftWin instead of W.shift as it isn't guaranteed that the window
being managed by the ManageHook is still in focus.
When focus changes¹ on an inactive workspace (not `current`, but
`visible`), TrackFloating and UseTransientFor would think they should
use the remembered focus point as they look at the wrong (`current`)
workspace instead of the workspace they're supposed to layout, and so
focus seems to be out of their set of windows, when actually it is not.
Fix this by looking at the correct workspace.
¹) This isn't entirely straightforward, as there are normally no
keybindings or StackSet operations for this, but it's perfectly legal
to `W.view` the inactive workspace, change focus, and `W.view` back
in a single `windows` action.
If a manually crafted ClientMessageEvent with invalid (nonexistent)
ev_window is sent to xmonad (by sending it to the root window), the
nonexistent window is added to Urgents and stays there forever.
This can also happen when a window in Urgents disappears while xmonad is
restarting, in which case xmonad never sees the DestroyWindowEvent and
never gets to remove the window from Urgents.
As both of these are fairly unlikely, only do the cleanup in
startupHook to not waste cycles.
The EWMH support added in 7e9c986217 only added handling of
_NET_WM_STATE_DEMANDS_ATTENTION to handleEvent and cleanupUrgents, but
manual urgency clearing via clearUrgents or automatic urgency clearing
via filterUrgencyHook was left without EWMH support. This commit adds
the missing pieces.
Fixes: 7e9c986217 ("Add EWMH DEMANDS_ATTENTION support to UrgencyHook.")
Atoms are at most 32-bit even on 64-bit platforms, per the X protocol,
despite them being stored in a CLong. Even if they weren't (and they
are, see /usr/include/X11/Xproto.h and
https://stackoverflow.com/a/23265984/3407728), xmonadctl isn't unpacking
the CLong into multiple data items.
Stop pretending it has anything to do with time, it's zero, and it's not
being read anywhere, we're passing the parameter only because
setClientMessageEvent needs one. We should switch to
setClientMessageEvent' and pass no data, but that would move the X11
dependency lower bound.
- StatusBarConfig serves as an abstraction over status bars. This
enables users to customize their status bars without having to do
the plumbing themselves.
- Multiple status bars can be used directly thanks to the
StatusBarConfig, which provides a way to compose status bars
The ppVisibleNoWindows was added in #241 but none of the modules that
rename/mangle workspace names were updated (or didn't exist at the
time). This fixes this.
Related: https://github.com/xmonad/xmonad-contrib/pull/241
Related: 670eb3bc60 ("Added pretty printer for empty visible workspaces")
The last release of wmctrl was in 2005 and it doesn't correctly set
source indication in _NET_ACTIVE_WINDOW client messages
(https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#sourceindication),
which is obviously completely irrelevant here, but if one decides to
implement clickableWrap for switching windows as well (like I did), it's
nice to use the same tool for it.
It's also nice to use a tool that compiles and runs on 64-bit
architectures without having to patch it (taken care of by distros,
though). :-)
526336ecec introduced a bug where
tab-completion has an issue when a completion contains spaces; it only
deletes the last word of that completion, causing the next TAB to again
select the current selection and add it to the command. In this way,
the prompt can get "stuck" on an item, endlessly adding all but the
first word to the command every time TAB is pressed.
C.f. xmonad/xmonad-contrib/issues/455
Just because there are some completions doesn't mean that the given
index may not still be too big.
Incidentally, this now allows every prompt to cycle through its items in
a nice way.
- `logWhenActive` to have loggers active only when a certain screen is
active.
- `logTitleOnScreen`, `logCurrentOnScreen` and `logLayoutOnScreen` as
screen-specific variants of `logTitle`, `logCurrent`, `logLayout`
- `logConst` to log a constant `String`
- `logMaybe` and `.|` to combine loggers.
Before c6cdb77e3b, handling of floats was
trivial (too trivial, and thus inefficient and flickery): any float
whose rectangle covered (RationalRect 0 0 1 1), regardless of what
screen or workspace it belonged to, got its borders hidden.
Then c6cdb77e3b added some nuance
(OnlyLayoutFloatBelow, OnlyLayoutFloat, OnlyScreenFloat) which requires
looking at floats in the context of individual screens. Unfortunately
the implementation only worked in singlehead setups, as it always used
only the active screen/workspace regardless of which screen/workspace
was currently being layouted. This resulted in the new functionality not
working correctly on inactive screens and also regressed the handling of
fullscreen floats on inactive screens.
The fix is conceptually easy: use the screen that is being layouted.
There is a catch, unfortunately: this code runs in redoLayout, but the
information we need is only available in modifyLayout and
modifyLayoutWithUpdate. I could store a screen id in the
ConfigurableBorder record in modifyLayoutWithUpdate and use it later in
redoLayout, but that'd be a massive hack, so what I do instead is to
find the relevant screen by searching for one that covers the `lr`
(layout/screen rectangle). In most setups, this should be reliable. If
it turns out it is not, we can fix this later.
Fixes: c6cdb77e3b ("'XMonad.Layout.NoBorders': various improvements:")
Fixes: https://github.com/xmonad/xmonad-contrib/issues/280
In c6cdb77e3b, several new constructors
were added but not "In order of increasing ambiguity (less borders more
frequently)" as the docs for data Ambiguity say. Correct the order and
clarify that Never only considers ambiguity of tiled windows (as in the
doc for smartBorders).
Fixes: c6cdb77e3b ("'XMonad.Layout.NoBorders': various improvements:")
Related: https://github.com/xmonad/xmonad-contrib/issues/280
If this is not done, trying to select another window with the mouse when
the treeselect window is up, the X server executes a pointer/keyboard
grab until `allowEvents' is called; which it never is and so both remain
frozen indefinitely.
C.f.:
- xmonad/xmonad/issues/116
- xmonad/xmonad-contrib/issues/445
If this is not done, trying to select another window with the mouse when
the prompt is up, the X server executes a pointer/keyboard grab until
`allowEvents' is called; which it never is and so both remain frozen
indefinitely.
C.f.:
- xmonad/xmonad/issues/116
- xmonad/xmonad-contrib/issues/445
* split into buildenv deps and stack build
* make the deps list more git-friendly
* use stack from github environment (I've seen the curl fail intermittently)
* indent consistency
My main motivation here is that I'd like to add some unit tests (as
opposed to testing everything using QuickCheck properties), but there
are other benefits: it's now easier to run a subset of tests -- the
command-line interface is more powerful.
Also, rename the test-suite to "tests" as it's no longer limited to
properties.
* silence warnings about unlisted modules
* remove xmonad-contrib dependency to make it unambiguous that modules
are recompiled with -DTESTING, not taken from the library
* sort build-depends
So far, when `alwaysHighlight' was enabled and the user selected an item
while not having completely written it out in the prompt, the input
string and not the eventual completion string would be entered into the
prompt history, which is obviously not the desired behaviour. This can
cause the history to clutter up with all these abbreviations, making
subsequent invocations of the prompt tedious to work with.
For example, an input of "xm" would narrow to both "xmonad" and
"xmobar", but thanks to `alwaysHighlight' "xmobar" was selected. If the
user now pressed enter, the prompt would correctly return "xmobar" as
the string to act upon, but "xm" would be entered into the prompt
history!
This is needed because the cache directory is now a part of XConf, which
is calculated once on startup and hence any recalculation would be
fragile.
Some internal functions that are not exposed (like writeHistory) were
also changed to accept that directory as an argument.
Fixes#164.
It's not clear to me why these functions take in XPState as a param only
to then produce some XP () values. It seems like they could just as well
call `get`.
In order to effectively restart status bars without relying
on pipes, spawnStatusBarAndRemember saves the PID of status
bars to kill them with cleanupStatusBars.
Removed checking for docks
Cleaned imports
Use signalProcesGroup instead of inverting the PID
Updated the documentation
Updated the documentation
Stop recommending pipes as the best/first thing to do and instead
recommend property based logging for all bars that support it. Also
strongly recommend users to use the already pre-made functions that do
all of the plumbing.
Add comments for the arguments of the most important user-facing
functions.
In an effort to modernize XMonad.Hooks.DynamicLog (and thus to stop
recommending pipes as the best way to interface with xmobar), implement
property log based solutions for the most important functions. Sadly
dzen does not seem to support this kind of interfacing with xmonad.
The descriptions of xmobar, statusBar, and statusBar' have been updated
to reflect that they should be seen as secondary choices.
This turns off the warnings about unused imports _unless_ one is using
the oldest supported version of GHC (right now that's 8.4.4 or older);
then it turns them into errors! This prevents xmonad from emitting
warnings about imports that have to be there due to backwards
compatibility, but are obsolete in newer versions (think MFP), while at
the same time preventing bitrot.
Starting with 5240116f3c we only support
GHC versions 8.4.4 and up (more precisely, the GHC version associated
with stackage lts-12 and up). The imports in question are now in
Prelude and need not be imported explicitly.
It was added in 81d338952d in an attempt to fix focus handling after
closing a floating window, but shortly after made redundant in
a551d1367c when we noticed it causes more harm than good. Unfortunately
it wasn't fully reverted, making the code more complex than necessary.
Drop the remaining bits.
Now it's almost obvious that the only difference between this and
X.L.StateFull.FocusTracking is the isF condition.
BTW the original issue 81d338952d was trying to fix can be fixed by
using X.H.RefocusLast, from the author of X.L.StateFull.FocusTracking.
:-)
Drop Eq constraint that isn't needed.
Drop the redundant Maybe from findZ return type. Breaks symmetry but
makes it easier to use (join no longer needed).
* Add Emacs-style Prefix handling
* Update CHANGES.md
* Add helper tests for prefix type
* Add docstrings.
* Fix handling of repeated prefix when we fall-back with no binding.
* Add a caveat about nested prefix binding
Because the there is a hard limit on the number of items in the topic
history now, it makes sense to first cons on the topic and then filter
the result (so setLastFocusedTopic can be used to exclude certain topics
from ever entering the history).
This makes docksStartupHook unnecessary. That is desirable because we
didn't add a changelog entry about it being necessary, and 4 years after
its introduction we still have users grabbing old configs and reporting
(https://github.com/xmonad/xmonad/issues/21#issuecomment-596161669) that
ManageDocks doesn't work properly.
I would love to finally settle this.
Full story follows:
xmonad-contrib 0.12 introduced (00be056a1b, merged in April 2013)
caching to ManageDocks to avoid queryTree calls on every runLayout,
which brought in several bugs. Attempts to fix these bugs in
xmonad-contrib 0.13 introduced (28e9f8bce7, merged in February 2016) a
breaking change in ManageDocks that required users to add
docksStartupHook (or docks, after e38fb3bdb8 got merged in November
2016) to their configs for avoidStruts to still work after xmonad
restart. Unfortunately this was never mentioned in the changelog nor in
any compilation warning (which get discarded by xmonad --recompile
anyway !!!), so as of March 2020 we still have users being bitten by
this.
Back in September 2016 in a discussion about other bugs introduced in
28e9f8bce7 I suggested that we use Maybe to indicate whether the cache
had been initialized and initialize it on demand when it had not.
Unfortunately I wasn't sufficiently clear about what I meant and Brandon
was going through some health issues, so we just got into a heated
argument and ended up merging a suboptimal solution. :-(
And since we're _still_ getting complaints from users every now and
then, I believe it's worth dealing with even after all these years.
If nothing else, let this serve as a reminder that breaking users'
configs without any warning is wrong.
(Oh and we should probably stop hiding xmonad.hs compilation warnings,
otherwise we can't ever hope to provide smooth deprecation and upgrade
paths.)
Fixes: 00be056a1b ("Cache results from calcGap in ManageDocks")
Fixes: 28e9f8bce7 ("add docksStartupHook for handling docks when restarted")
Fixes: e38fb3bdb8 ("Make usage of ManageDocks simpler and more robust")
Related: https://github.com/xmonad/xmonad-contrib/issues/118
Related: https://github.com/xmonad/xmonad-contrib/pull/30
Related: https://github.com/xmonad/xmonad-contrib/pull/80
Related: https://github.com/xmonad/xmonad/issues/21
None of these properties are currently being set when xmonad starts:
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
_NET_CURRENT_DESKTOP(CARDINAL) = 0
_NET_CLIENT_LIST_STACKING(WINDOW): window id #
_NET_CLIENT_LIST(WINDOW): window id #
because the caching introduced in 92fe5f34ff initializes the
cache with the same values that they should have in an empty session, so
we don't detect a change and don't set them.
Fix it by initializing the cache with impossible (or at least extremely
improbable) values.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/363
This enables adding the Typeable constraint to LayoutClass itself
(https://github.com/xmonad/xmonad/pull/242) which in turn enables
querying the current layout state. That might be useful to e.g. show the
current X.L.WorkspaceDir in xmobar.
This is a preparation commit that fixes the compile failures that would
result in merging that change to xmonad. For this to be generally useful
we first need to merge (and ideally also release) that xmonad change,
and then we'll need some documentation and perhaps a type class to help
find the right LayoutModifier in the tree of ModifiedLayouts and
Choices. That will come later.
This makes it possible to change the workspace directory by sending a
message, which enables automation/scripting not possible with
`changeDir` which displays a prompt.
Example of such usage:
6ea6c52aac/.xmonad/xmonad.hs (L183-L189)
- By default window activation does nothing.
- `activateLogHook` may be used for running some 'ManageHook' for
activated window.
- `activated` predicate may be used for checking was window activated or
not.
This module contains a modifier that simply sets X11 window border width
to 0 for every window in the layout it modifies. No efforts are made to
bring the border back, which can be annoying if windows are moved to a
different workspace, but it prevents the "border flash" you get with
XMonad.Layout.NoBorders.
Configs that apply WorkspaceId transformations, such as
IndependentScreens (adding/removing a screen-number prefix) and
NamedWorkspaces (adding/removing a name suffix), cannot use clickablePP
as is, since they need to apply clickableWrap to an appropriately
transformed WorkspaceId. Rather than force them to reimpliment
clickableWrap, export it.
An example use-case, where IndependentScreens has added a screen number
prefix to the workspace ids (0_1, 0_2, ...), and we want a status-bar
that shows the ids without screen number (1, 2, ...), but also makes
them clickable:
getClickable :: (WorkspaceId -> WorkspaceId) -> X (WorkspaceId -> String)
getClickable f = do
wsIndex <- getWsIndex
pure $ \ws -> case wsIndex (f ws) of
Just idx -> clickableWrap idx ws
Nothing -> ws
composePP :: PP -> ScreenId -> X PP
composePP pp s = do
clickable <- getClickable (marshall s)
return
. marshallPP s
$ pp
{ ppCurrent = ppCurrent pp . clickable,
ppVisible = ppVisible pp . clickable,
ppHidden = ppHidden pp . clickable,
ppHiddenNoWindows = ppHiddenNoWindows pp . clickable,
ppUrgent = ppUrgent pp . clickable
}
Parameterizing completion case-sensitivity for single-mode prompts was
possible without making any breaking changes. For multi-mode prompts,
however, the completion function is expressed through the XPrompt
'completionFunction' method. The only argument that method receives is a
Dir value, so parameterizing completion case-sensitivity means adding a
new field to the Dir constructor.
Provide a way to perform case-insensitive file / directory completion.
We're using compgen to generate completion candidates, and this is
case-sensitive by default. We can control this by setting the
completion-ignore-case Readline variable prior to invoking compgen. If
we're running a Bash with Readline support, this works as expected.
Otherwise, it has no effect -- completion candidates are still returned,
but compgen generates them in a case-sensitive manner.
To avoid breaking changes, the signatures and behavior of existing
exported functions are unchanged:
- XMonad.Layout.WorkspaceDir.changeDir
- XMonad.Prompt.Directory.directoryPrompt
- XMonad.Prompt.Shell.getShellCompl
New variations of these functions are provided, allowing the caller
to specify the desired case-sensitivity via a ComplCaseSensitivity
argument:
- XMonad.Layout.WorkspaceDir.changeDir'
- XMonad.Prompt.Directory.directoryPrompt'
- XMonad.Prompt.Shell.getShellCompl'
The XMonad.Prompt.Shell exports a couple new functions:
- compgenDirectories
- compgenFiles
We make use of this in XMonad.Prompt.Directory to avoid duplicating the
compgen code.
Add an example and more comments to the documentation, and make some
small code tweaks (more type signatures and a couple variable renames)
to aid readability.
Add a statusBar' function that accepts pretty printing options embedded
in the X monad, so users can leverage dynamic printing modifiers, such
as workspaceNamesPP.
I was naively passing the workspace to runLayout without filtering out
floating windows from its stack, like XMonad.Operations.windows does.
The fact that 'windows' does this filtering explains how layouts like
those in LimitWindows continue to behave correctly in the presence of
floating windows.
This fixes some incorrect behavior where the presence of a floating
windows caused visible windows (other than the focused one) to be
included in the surfaceRing.
Verify that rotateSome behaves as expected and never fails to pattern
match.
In order to run these tests, I ran a custom script:
scripts/run-tests.sh tests/RotateSome.hs
where the script contained the following:
set -eu
toplevel=$(git rev-parse --show-toplevel)
XMONAD="${XMONAD:-$toplevel/../xmonad}"
main=$(realpath -e "$1")
instances_target="$XMONAD/tests/Instances.hs"
instances_symlink="$toplevel/tests/Instances.hs"
properties_target="$XMONAD/tests/Properties"
properties_symlink="$toplevel/tests/Properties"
utils_target="$XMONAD/tests/Utils.hs"
utils_symlink="$toplevel/tests/Utils.hs"
trap "
rm '$instances_symlink' '$utils_symlink' '$properties_symlink' || true
" EXIT INT QUIT TERM
ln -s "$instances_target" "$instances_symlink"
ln -s "$properties_target" "$properties_symlink"
ln -s "$utils_target" "$utils_symlink"
runghc -DTESTING \
-i"$toplevel" \
-i"$toplevel/tests" \
"$main"
This module provides a pure function, 'rotateSome', as well as a pair of
X actions that use it to rotate unshown windows through the focused
stack position while leaving other windows in place. I find this useful
in combination with layouts such as LimitWindows, which determine window
visibility based on stack position.
Provide boring-aware versions of the 'siftUp' and 'siftDown' functions.
Since these actions never affect the position of boring windows, they
work well with layouts that decide which windows are visible/hidden
based on stack position, such as LimitWindows.
Provide swap-like functions that handle the wrapping case by exchanging
the windows at either end of the stack rather than rotating the stack.
https://github.com/xmonad/xmonad/issues/234
The effect is the same, but this seems to express the intent more
clearly, and it will make it easier to factor out the shared behavior
with skipBoringSwapUp.
Provide boring-aware versions of 'swapUp' and 'swapDown'.
Note that 'iterate f x' produces a list whose zeroth element is
'x' prior to any application of 'f'. The 'focusUp' and 'focusDown'
operations reject this iteration by checking in the filter predicate
that the focus actually changed:
filter ((`notElem` W.focus st:bs) . W.focus)
We can't do that for swaps, since our focus never changes, so we drop
the zeroth iteration prior to any predicate-based filtering.
The filter predicate checks whether the window immediately below the
our focus is boring. If so, we've performed an uninteresting upwards
swap and should continue swapping until we either swap past a window
that is not boring or wrap around the top of the stack.
It's particularly important that we accept the wrapping case regardless
of any boring neighbor, otherwise we risk missing a legitimate
non-boring swap. Consider, for example, the following stack:
focus: A
up: []
down: [B, boringC]
A swapUp yields:
focus: A
up: [boringC, B]
down: []
This should be considered non-boring, since the non-boring windows
swapped order: A B -> B A. If we were to reject it, we'd swap A up past
boringC and up again past B, putting us back where we started.
Put another way, if our focus was at the top of the stack, then all
other windows were necessarily below it. We want a swapUp to place our
focus below the lowest non-boring window. A wrap around to the bottom of
the stack guarantees that is the case.
Some users like to include type signatures in their configuration. The
Minimize type constructor was not exported, making it impossible to
write a type signature when using minimize.
With this change, a user can write an xmonad.hs like:
import XMonad
import XMonad.Layout.Minimize (Minimize, minimize)
import XMonad.Layout.LayoutModifier
myLayout :: ModifiedLayout
Minimize
(Choose Tall (Choose (Mirror Tall) Full))
Window
myLayout = minimize $ layoutHook def
main :: IO ()
main = xmonad def { layoutHook = myLayout }
Some users like to include type signatures in their configuration. The
HiddenWindows type constructor was not exported, making it impossible to
write a type signature when using hiddenWindows.
With this change, a user can write an xmonad.hs like:
import XMonad
import XMonad.Layout.Hidden (HiddenWindows, hiddenWindows)
import XMonad.Layout.LayoutModifier
myLayout :: ModifiedLayout
HiddenWindows
(Choose Tall (Choose (Mirror Tall) Full))
Window
myLayout = hiddenWindows $ layoutHook def
main :: IO ()
main = xmonad def { layoutHook = myLayout }
The current handle returned by `spawnPipe` doesn't have any encoding
and it uses the function fdToHandle which returns a Binary
Handle. When spawnPipe is used with a program like xmobar, this can
easily lead to errors:
λ> h <- spawnPipe "xmobar"
λ> hPutStrLn h
"\35753Haskell\25110\32773Ghci\33021\27491\30830\26174\31034\27721\23383\24182\19988\35835\21462\27721\23383\21629\21517\30340\25991\26723"
<stdin>: hGetLine: invalid argument (invalid byte sequence)
One workaround, to avoid this is to use `hSetEncoding`. But from
reading GHC's source code - the entire Handle and write operations
seems stateful. So doing something like hPutStr and hSetEncoding can
theoretically lead to an undefined state as the first write will use
latin encoding and the second write will use the new encoding. More
details about it are present here:
* http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Handle.Internals.html#writeCharBuffer
* http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Buffer.html#CharBuffer
So having these new functions will ensure that we get the handles in
the proper encoding in the first place.
Prompts based on `mkComplFunList` and `mkComplFunList'` were not
taking into account the `searchPredicate` funtion from `XPConfig`.
This was rather confusing.
We fix it by passing `XPConfig` to these functions; although
this is strictly more than they need, it makes the breaking change very
easy to fix and is also more future-proof.
Provide a way to advertise _NET_WM_STATE_FULLSCREEN in _NET_SUPPORTED.
I had this hardcoded for a while but read the mpv manpage recently:
Specifically, yes will force use of NetWM fullscreen support, even
if not advertised by the WM. This can be useful for WMs that are
broken on purpose, like XMonad. (XMonad supposedly doesn't advertise
fullscreen support, because Flash uses it. Apparently, applications
which want to use fullscreen anyway are supposed to either ignore
the NetWM support hints, or provide a workaround. Shame on XMonad
for deliberately breaking X protocols (as if X isn't bad enough
already).
I'm not sure Flash is still a good reason these days to not advertise
fullscreen support yet still handle it and look like idiots while doing
so. (And if anyone thinks it is a good reason, their unchanged xmonad
config will continue behaving that way.)
Not everyone has those repositories checked out at those paths. IMHO, it would
be much better to configure these as "optional-packages". In any case, users
should probably configure those in their cabal.project.local.
This change needs base-4.9.0.0 or later so that we can
include Control.Monad.Fail. We could jump through hoops to
support older compilers still, but it feels like it's not
worthwhile.
Colors in 'XPState' continue to use 'XPColor' since it provides a
cleaner interface. For backwards compatibility color changes to
'XPConfig' were reverted. To avoid accessor clashes you'll have to deal
with slightly different names:
| 'XPState'/'XPColor' | 'XPConfig' |
| ------------------- | ----------- |
| bgNormal | bgColor |
| fgNormal | fgColor |
| bgHighlight | bgHLight |
| fgHighlight | fgHLight |
| border | borderColor |
A vim-like keymap, yay! And dynamic colors and a reworked event loop.
Also fixes 'showCompletionOnTab' which was broken, and many new or
improved prompt interface functions.
Changes moveWord/moveWord' but updates the old keymaps to retain the
original behavior. See the documentation to do the same to your XMonad
configuration.
P.S. That bug I mention was there before my changes.
The user may modify the list of workspace tags that results form
applying the dynamic order. This way one may filter workspaces they
don't want in the order (e.g. "NSP") or apply any transformation he
wishes to the list of tags.
* Rewrite the `refocus` function such that it modifies the windowset
without performing a refresh, instead returning the given layout
object when one is required.
* Message handling which uses `refocus` has been rewritten to less
frequently request unnecessary refreshes.
The 'FullscreenFull' layout modifier hides all windows fully covered by
the fullscreen area, even when no fullscreen windows are present. Fix
this, closing #278. Also switch to 'X.U.Rectangle'.
* don't constrain to precise
* add libxrandr dependency
* test against new GHC versions
* install xmonad from git before cabal can install it from hackage
* Explicitly import pure, (<$>), (<*>) and (<$) from Control.Applicative.
* Use DeriveDataTypeable pragma.
* Remove type signature from pattern synonym.
* Reintroduce the original 'ModifySpacing' type and constructor as
deprecated; the new 'ModifySpacing' type was renamed to
'SpacingModifier'. Suggested by @LSLeary.
* Types 'SpacingWithEdge', 'SmartSpacing', and 'SmartSpacingWithEdge'
have been reintroduced as deprecated type synonyms of 'Spacing'. Work
by @LSLeary.
Also 'borderMap' is now exported; it might be useful.
Make 'stackMerge' safer by implicitly appending any leftover elements
rather than discarding them. Otherwise on refresh the missing windows
will be deleted. This is only necessary if the stack has been shortened
- i.e. not required by this module.
Minor miscellaneous documentation fixes.
* All the backwards-compatibility functions now accept `Int` rather than
`Integer`: `spacing`, `spacingWithEdge`, `smartSpacing`,
`smartSpacingWithEdge`, `setSpacing`, and `incSpacing`. Work done by
@LSLeary.
* Introduce the new functions `setScreenWindowSpacing`,
`incScreenWindowSpacing`, `decScreenWindowSpacing`. Unlike their
original `setSpacing`, `incSpacing` counterparts, these refresh no
more than once. Requires `sendMessages` from my PR of
`XMonad.Actions.MessageFeedback`. Suggestion by @LSLeary and
implemented so any combination of messages can be sent without
triggering unnecessary refreshes.
- Follow the naming conventions of `XMonad.Operations`. Functions returning
`X ()` are named regularly (previously these ended in underscore) while
those returning `X Bool` are suffixed with an uppercase 'B'.
- Provide all `X Bool` and `SomeMessage` variations for `sendMessage` and
`sendMessageWithNoRefresh`, not just `sendMessageWithNoRefreshToCurrent`
(renamed from `send`).
- The new `tryInOrderB` and `tryMessageB` functions accept a parameter of
type `SomeMessage -> X Bool`, which means you are no longer constrained
to the behavior of the `sendMessageWithNoRefreshToCurrent` dispatcher.
- The `send*Messages*` family of funtions allows for sequencing arbitrary
sets of messages with minimal refresh. It makes little sense for these
functions to support custom message dispatchers.
- Remain backwards compatible. Maintain deprecated aliases of all renamed
functions:
- `send` -> `sendMessageWithNoRefreshToCurrentB`
- `sendSM` -> `sendSomeMessageWithNoRefreshToCurrentB`
- `sendSM_` -> `sendSomeMessageWithNoRefreshToCurrent`
- `tryInOrder` -> `tryInOrderWithNoRefreshToCurrentB`
- `tryInOrder_` -> `tryInOrderWithNoRefreshToCurrent`
- `tryMessage` -> `tryMessageWithNoRefreshToCurrentB`
- `tryMessage_` -> `tryMessageWithNoRefreshToCurrent`
The layout now maintains a list of windows that never have borders, and
a list of windows that always have borders. Use 'BorderMessage' to
manage these lists and the accompanying event hook ('borderEventHook')
to remove destroyed windows from them. Also provides the 'hasBorder'
manage hook.
Two new conditions have been added to 'Ambiguity': 'OnlyLayoutFloat' and
'OnlyLayoutFloatBelow'; 'OnlyFloat' was renamed to 'OnlyScreenFloat'.
See the documentation for more information.
There's no reason to return a rectangle for any window that is totally
obscured by a full-screen window, and not doing so has the nice property that
when hidden windows' borders overlap with a full-screen window's, the user
will not be confused by overlapping partially-drawn borders. It also makes the
Fullscreen modifiers combine much better with smartBorders.
Both screen and window borders can now be disabled. Implement missing
messages. The layout now handles windows that are displayed but not part
of the stack, such as those created by 'XMonad.Layout.Decoration'.
Several additional fixes.
The 'smartBorder' now depends on the window/rectangle list resulting
from 'runLayout' rather than the stack, which means that the child
layout will always be called with the screen border. If only a single
window is displayed, it will be expanded into the original layout
rectangle.
Simple extensions of the pretty printer to differentiate between empty
and non-empty visible workspaces. Analogical to the existing
functionality for hidden workspaces. Particularly useful if some
displays managed by xmonad are turned off temporarily.
The new 'ppVisibleNoWindows' function was wrapped in a Maybe data type.
Its value dafaults to 'Nothing' and 'ppVisible' is used as fallback.
This commit adds `dzenWithFlags` function for users who wish to change the
command line arguments passed to `dzen`. The behaviour of `dzen` function is
kept the same.
The `group3` addition I made in a previous commit enabled one to go so
far, but then quickly hit some walls due to non-exported symbols from
`XMonad.Layout.Groups`.
This commit removes `group3`, as it would hardly be useful to anybody,
and introduces a new `ModifyX` message that allows the modifying
function to return a `Groups` layout inside the `X` monad. Here's an
example on why this is useful:
Say you have a master layout with tabbed sub-layouts, and you have
terminal windows sprinkled around these sub-layouts. You now want to
gather all of them into a single tabbed sub-layout, effectively
implementing a "tabbed terminal" (or browser, or editor, etc). With
functionality like this, `XMonad` can become a unified multi-window
application manager: one does not need tabbed browsers, terminals,
etc.
In order for this to be possible, however, the modifier function needs
to be able to query for things like the window class name with
`runQuery`, and that in turn means it has to operate inside the `X`
monad. This is only possible if `Groups` accepts the modifier
introduced in this commit.
I bet many other uses for a `ModifierX` message can be found. I have
the functionality of the example I gave implemented and working with
this change, since it was my motivation to get it done (and I must say
it is quite sweet to have tabbed window unification).
This is similar to 'Column' layout with some differences.
- Add/remove windows keeps window bounds.
- Enforce minimum window size.
- Negative scale can be used to increase the size of the last window
instead of the master window.
Provides a predicate 'fuzzyMatch' that is much more lenient in matching
completions in XMonad.Prompt than the default prefix match. Also provides
a function 'fuzzySort' that allows sorting the fuzzy matches by "how well"
they match.
Not sure why wasn't it accepted.
Discussion: https://markmail.org/thread/kgrybzqarqzqiige
This is as per the work done in
http://lynnard.me/blog/2013/12/30/more-xmonad-goodies/, where the
functionality is explained in detail.
This also fixes#214. The original suggestion in that bug report is
not enough. Even if we export `gen` and `Uniq`, we would still have to
export the `Groups` type constructor. I thought it better to simply
allow the user to create a three-dimensional group instead.
Adds a badge showing the number of people helping this repo on CodeTriage.
[](https://www.codetriage.com/xmonad/xmonad-contrib)
## What is CodeTriage?
CodeTriage is an Open Source app that is designed to make contributing to Open Source projects easier. It works by sending subscribers a few open issues in their inbox. If subscribers get busy, there is an algorithm that backs off issue load so they do not get overwhelmed
[Read more about the CodeTriage project](https://www.codetriage.com/what).
## Why am I getting this PR?
Your project was picked by the human, @schneems. They selected it from the projects submitted to https://www.codetriage.com and hand edited the PR. How did your project get added to [CodeTriage](https://www.codetriage.com/what)? Roughly 7 months ago, [wisn](https://github.com/wisn) added this project to CodeTriage in order to start contributing. Since then, 2 people have subscribed to help this repo.
## What does adding a badge accomplish?
Adding a badge invites people to help contribute to your project. It also lets developers know that others are invested in the longterm success and maintainability of the project.
You can see an example of a CodeTriage badge on these popular OSS READMEs:
- [](https://www.codetriage.com/rails/rails) https://github.com/rails/rails
- [](https://www.codetriage.com/crystal-lang/crystal) https://github.com/crystal-lang/crystal
## Have a question or comment?
While I am a bot, this PR was manually reviewed and monitored by a human - @schneems. My job is writing commit messages and handling PR logistics.
If you have any questions, you can reply back to this PR and they will be answered by @schneems. If you do not want a badge right now, no worries, close the PR, you will not hear from me again.
Thanks for making your project Open Source! Any feedback is greatly appreciated.
Now when using getSortByXineramaPhysicalRule and all helper given by
Actions.PhysicalScreens the user have to provide a screen comparator that can
compare screen using their id or/and their coordinate.
type in a password, bypassing the clipboard. Also incorporate some shell
escapes to properly handle pass labels with spaces and special
characters in them.
menuArgs breaks compilation on GHC < 7.10 because it uses fmap but
only has a MonadIO constraint.
Functor was not a superclass of Monad until GHC 7.10.
These layout have different applications but their names could cause some
confusion since the module names could just as well be swapped. To support this claim,
what we call "spacing" is named "gaps" in i3wm (i3-gaps). Therefore hyperlinks have
been added to inform the reader of the existence of the other module.
The X.U.Dmenu library has support to run dmenu-like launchers, but X.A.Commands
has the use of dmenu hardcoded. This commit makes it possible to use other
launchers without duplicating existing code.
Firstly, the links are updated to point to Hackage rather than xmonad.org since not all redirect work correctly. For example the link to developing documentation went to the main XMonad's Hackage page rather then XMonad.Docs.Extending on Hackage.
Secondly, the links are changed such that their [id]-tag isn't showing.
Lastly, a link to XMonad's contributing.md has been added.
This module provides a way to query the session startup.
Currently the flag has to be set by calling setSessionStarted in
the startupHook. The goal would be to merge this into xmonad at some
point and set the flag when the state file is read in, and remove the
need to manually set it.
MonadIO is compatible with xfork which prevents dmenu prompts from
freezing XMonad.
Without xfork, if I try to give focus to another window while dmenu is
waiting, XMonad freezes until I kill dmenu in virtual terminal or ssh
session.
Before this fix, when using layoutHintsToCenter together with
MultiColumns, in certain situations XMonad would render the border of
the focused window below a border of unfocused windows. This looks odd
and is here fixed by changing MultiColumns to always place the focused
window in front (even though they should not really overlap) and making
LayoutHints preserve the order returned from the underlying layout,
except for the focused window that is placed on top.
This is a good idea since layoutHintsToCenter requires the focused
window to be on top for good rendering, even if that is not really
required when the underlying layout is used on its own. This way
layoutHintsToCenter requires less of the layout that is modified and
MultiColumns is more compatible with future layout modifiers that are
not so considerate.
* Use global state instead of per-layout - so now window is minimized on
all workspaces (EWMH requires that windows with _NET_WM_STATE_HIDDEN
set should be minimized on any workspace but previously they were not)
* Use `windows` instead of `modify`. That should fix bugs related to
actions that should be done by `windows` and not done by
`modify` (fixes#46)
* Mark module X.H.RestoreMinimized as deprecated
Like 'windowPrompt', but uses the multiple modes feature of
@Prompt@ (via 'mkXPromptWithModes').
Given a list of actions along with the windows they should work
with, display the appropriate prompt with the ability to switch
between them using the @changeModeKey@.
For example, to have a prompt that first shows you all windows, but
allows you to narrow the list down to just the windows on the
current workspace:
> windowMultiPrompt config [(Goto, allWindows), (Goto, wsWindows)]
This change improves the UX of X.Prompt when `alwaysHighlight` is
enabled. This is especially useful for use with `mkXPromptWithModes`
which forces `alwaysHighlight` to be `True`.
When the user presses the `complKey` and `alwaysHighlight` is `True`,
one of two things will happen:
1. If this is the first time `complKey` is pressed in this round of
completion then the prompt buffer will be updated so it contains
the currently highlighted item.
2. Every other time that the `complKey` is pressed the next
completion item will be selected and the prompt buffer updated.
This gives immediate feedback to the user and allows using some
prompts with `alwaysHighlight` that weren't possible before (e.g.,
shellPrompt, directoryPrompt, etc.)
Prompt should have been using getXMonadDir this entire time but since
we now have getXMonadCacheDir use that instead. This brings
xmonad-contrib inline with the changes in #62.
This also fixesxmonad/xmonad-contrib#68
Move EWMH code from `X.H.Focus` to `X.H.EwmhDesktops`. Thus:
- I'll use `manageHook` for handling activated window.
- By default window activation do nothing (assuming default `ManageHook`).
- I can use `activated` predicate for changing window activation behavior.
- I may use additional combinators from `X.H.Focus` for more complex
focus/workspace switch strategies.
All False short-cuts the default behavior for the event, which leads to a non-functioning window manager. Returning mempty ensures that the default action is still executed,
Establish active asynchronous pointer grab before entering infinity cycle.
Because xmonad already has passive synchronous pointer grab, this overwrites
it temporary and avoids freezing X, when button press occurs after submap key
press.
Also, terminate submap at button press in the same way, as we do for wrong key
press.
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.
This provides a less complicated interface to the specification of
custom behavior. In particular it allows the specification of a custom
window titling function.
XMonad.Prompt allows the user to specify a search predicate in XPConfig.
However, previously XMonad.Prompt.Pass did not apply this predicate.
This now applies the predicate in similar manner as XMonad.Prompt.Shell.
I have been using this code locally for years now, and it turned out to
be quite useful in many cases, so I thought it is about time to submit
it to the repository.
You can add indexes to workspaces and use them to do actions on
workspaces. This allows you to dynamicaly associate a workspace to a
keybinding without depending of the workspace name or the workspace
position.
This is fixing for problem that
WorkscreenId was shown in XMonad.Actions.Workscreen document
(ex: viewWorkscreen),
but never shown WorkscreenId definition.
To enable this feature add `workspaceHisotryHook` from
`XMonad.Hooks.WorkspaceHistory` to your logHook.
Your previously-visited workspaces can be navigated with
the 'moveHistBack' and 'moveHistForward' actions (which are bound to the 'o' and 'i' keys)
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.
As it now consists of a startup hook, a manage hook, an event hook and
a layout modifier, and behaves erratically when any one component is not
included in a user's config (which happens to be the case for all
configs from xmonad-contrib 0.12 since the startup hook is a new
inclusion), it's probably wise to have a single function that adds
all the hooks to the config instead.
NB: This will need a release notes entry anyway!
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.
TreeSelect displays your workspaces or actions in a Tree-like format.
You can select the desired workspace/action with the cursor or hjkl keys.
This module is fully configurable and very useful if you like to have a
lot of workspaces.
Please see the Documentation provided by 'XMonad.Actions.TreeSelect'.
Add functions to allow cleaning up only screens which disappear. This
works better where killing the statusbar for a specific screen is
possible. The old way is still relevant for setups which do not have
such a method (e.g., safeSpawn xmobar/spawnPipe xmonadpropwrite).
- The set of windows proposed by the prompt can be parametrized. Two
helper functions are currently defined. One for selecting all
available windows and another one for selecting all windows of the
current workspace.
- Add BringToMaster action which brings the selected window to the
current workspace and set it as master.
- windowPromptGoto, windowPromptBring, windowPromptBringCopy are
marked as deprecated since they can be realized by the more generic
windowPrompt function. For instance, "windowPromptGoto prompt" can
be easily replaced by "windowPrompt prompt Goto allWindows".
This patch enables support for key binding like Ctrl + i which was not
previously possible. Technically, this changes the type of completionKey
from KeySym to (KeyMask, KeySym).
* All references to darcs have been updated to git
* Most Google Code references have been changed to GitHub
* References to specific issues at code.google.com have been left
alone
* Updated the GenerateManpage.hs to work with the latest version of
pandoc
* Previously I was removing empty workspaces after switching away from
them, but this seemed to cause a bug when workspaces were defined
statically in your XMonad configuration.
* Next up: a function to delete an existing project.
Reorder the application of hooks so that users' config is honored.
Notably, this means setWMName works in startupHook instead of
needing to do it repeatedly in logHook.
Run a ManageHook from handleEventHook when a window property changes.
You would use this to match e.g. browser windows whose title is not
"final" until after the on-load hooks of the loaded document complete.
Correct the docstrings / comments in X.C.Mate, which still referenced
gnomeConfig. Also update the session manager configuration to use
dconf and a current (on Mint at least) path for the session config.
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.)
pass stores its passwords in directories, so the contents of the directory
store needs to be enumerated recursively. Alexander Sulfrian provided this
patch on the mailinglist, which I tested (it works) and cleaned up slightly.
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)
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.
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.
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.
The screen equivalent of 'withWorkspaces' lets you more easily define keys that
move/swap between screens.
Also, rename wsKeyspecs to wsKeys, and make a couple of doc tweaks.
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
This allows easier configuration of workspaces and their keybindings. Required
generalizing the 'Prime' type, so lots of other lines changed in rather trivial
ways.
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.
This module provides 3 <XMonad.Prompt> to ease passwords manipulation (generate, read, remove):
- one to lookup passwords in the password-storage.
- one to generate a password for a given password label that the user inputs.
- one to delete a stored password for a given password label that the user inputs.
All those prompts benefit from the completion system provided by the module <XMonad.Prompt>.
The password store is setuped through an environment variable PASSWORD_STORE_DIR.
If this is set, use the content of the variable.
Otherwise, the password store is located on user's home @$HOME\/.password-store@.
Source:
- The password storage implementation is <http://git.zx2c4.com/password-store the password-store cli>.
- Inspired from <http://babushk.in/posts/combining-xmonad-and-pass.html>
Initial support for the Mate desktop environment (http://mate-desktop.org).
Based on existing Gnome 2 support, since Mate is a maintained fork of
Gnome 2.
A set of hooks, and convenience combinators, to help with ManageHook debugging.
Ordinary users may well want to use debugManageHookOn in normal configs,
specifying a key sequence which can be pressed before running a command in
order to capture debug information just for that command's main window.
This is especially useful when trying to diagnose issues such as programs
that do not play well with SpawnOn, or ManageHook matching on 'title' when
the program does not set the window title until after it is mapped.
Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug
requires these fixes, but some of them are significant even if not using
ManageDebug.
The following change from 2013-02-09 breaks shell completion for me:
hunk ./XMonad/Prompt/Shell.hs 65
+ commandToComplete _ c = c
It seems to be passing the entire string into compgen in order to get the file completions, but it should only pass the last word. I propose reverting this change. Comments are appreciated.
This makes a breakage due to missing patches in core a bit more obvious.
Previously you would have a build failure regarding some missing identifiers
(def re-exported by XMonad from Data.Default), while after applying this patch
it will be clear that xmonad-core needs to be updated.
The issue was that window titles, such as those set by, for example a browser,
could set the window title to display something like
<action=malicious shell command>normal title</action>
Which could be executed by xmobar (or dzen).
This adds a ppTitleSanitize which does the above functions. This way when users
override ppTitle, the benefits are not lost.
Thanks to Raúl Benencia and Joachim Breitner for bringing this to my attention.
Hooks.DynamicBars was previously using an MVar and the unsafePerformIO hack (
http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar
state. Since ExtensibleState exists to solve these sorts of problems, I've
switched the file over to use unsafePerformIO instead.
Some functions' types had to be changed to allow access to XState, but the
public API is unchanged.
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.
modWorkspace already was capable of modifying the layout with an arbitrary
layout -> layout function, but its original type restricted it such that it
could only apply a single LayoutModifier; this was often inconvenient, as for
example it was not possible simply to compose LayoutModifiers for use with
modWorkspace.
This patch also reimplements onWorkspaces in terms of modWorkspaces, since with
the latter's less restrictive type this is now possible.
On a keyboard-less device (such as a smartphone), where one has to use
an on-screen keyboard, the maximum completion window height must be
limited to avoid overlapping the keyboard.
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.
This authorspellings file includes a couple people who've contributed to xmonad
(not XMonadContrib). When people have multiple addresses, the most recent one
has been picked.
2013-01-01 04:00:31 +00:00
377 changed files with 35762 additions and 8413 deletions
<ahref="https://web.libera.chat/#xmonad"><imgalt="Chat on #xmonad@irc.libera.chat"src="https://img.shields.io/badge/%23%20chat-on%20libera-brightgreen"></a>
<ahref="https://matrix.to/#/#xmonad:matrix.org"><imgalt="Chat on #xmonad:matrix.org"src="https://img.shields.io/matrix/xmonad:matrix.org?logo=matrix"></a>
</p>
# xmonad-contrib
**Community-maintained extensions for the [XMonad][web:xmonad] window manager.**
[xmonad core][gh:xmonad] is minimal, stable, yet extensible.
[xmonad-contrib][gh:xmonad-contrib] is home to hundreds of additional tiling
algorithms and extension modules. The two combined make for a powerful X11
window-manager with endless customization possibilities. They are, quite
literally, libraries for creating your own window manager.
## Installation
For installation and configuration instructions, please see:
* [downloading and installing xmonad][web:download]
* [installing latest xmonad snapshot from git][web:install]
* [configuring xmonad][web:tutorial]
If you run into any trouble, consult our [documentation][web:documentation] or
ask the [community][web:community] for help.
## Contributing
We welcome all forms of contributions:
* [bug reports and feature ideas][gh:xmonad-contrib:issues]
(also to [xmonad][gh:xmonad:issues])
* [bug fixes, new features, new extensions][gh:xmonad-contrib:pulls]
(also to [xmonad][gh:xmonad:pulls])
* documentation fixes and improvements: [xmonad][gh:xmonad],
-- For detailed instructions on editing your mouse bindings, see
-- "XMonad.Doc.Extending#Editing_mouse_bindings".
--
-- Using these mouse bindings, it will not snap while moving, but allow you to click the window once after it has been moved or resized to snap it into place.
-- Note that the order in which the commands are applied in the mouse bindings are important.
-- Note that the order in which the commands are applied in the mouse bindings are important. Snapping can also be used together with other window resizing
-- functions, such as those from "XMonad.Actions.FlexibleResize"
--
-- An alternative set of mouse bindings that will always snap after the drag is:
--
-- > , ((modm, button1), (\w -> focus w >> mouseMoveWindow w >> afterDrag (snapMagicMove (Just 50) (Just 50) w)))
-- This module can also be used to select any other action
-- | Extensive configuration for displaying the tree.
--
-- This class also has a 'Default' instance
dataTSConfiga=TSConfig{ts_hidechildren::Bool-- ^ when enabled, only the parents (and their first children) of the current node will be shown (This feature is not yet implemented!)
,ts_background::Pixel-- ^ background color filling the entire screen.
,ts_font::String-- ^ XMF font for drawing the node name extra text
,ts_node::(Pixel,Pixel)-- ^ node foreground (text) and background color when not selected
,ts_nodealt::(Pixel,Pixel)-- ^ every other node will use this color instead of 'ts_node'
,ts_highlight::(Pixel,Pixel)-- ^ node foreground (text) and background color when selected
,ts_extra::Pixel-- ^ extra text color
,ts_node_width::Int-- ^ node width in pixels
,ts_node_height::Int-- ^ node height in pixels
,ts_originX::Int-- ^ tree X position on the screen in pixels
,ts_originY::Int-- ^ tree Y position on the screen in pixels
,ts_indent::Int-- ^ indentation amount for each level in pixels
,ts_navigate::M.Map(KeyMask,KeySym)(TreeSelecta(Maybea))-- ^ key bindings for navigating the tree
}
instanceDefault(TSConfiga)where
def=TSConfig{ts_hidechildren=True
,ts_background=0xc0c0c0c0
,ts_font="xft:Sans-16"
,ts_node=(0xff000000,0xff50d0db)
,ts_nodealt=(0xff000000,0xff10b8d6)
,ts_highlight=(0xffffffff,0xffff0000)
,ts_extra=0xff000000
,ts_node_width=200
,ts_node_height=30
,ts_originX=0
,ts_originY=0
,ts_indent=80
,ts_navigate=defaultNavigation
}
-- | Default navigation
--
-- * navigation using either arrow key or vi style hjkl
{-# DEPRECATED "This module contains a personal configuration, to be removed from xmonad-contrib. If you use this module, please copy the relevant parts to your configuration or obtain a copy of it on https://xmonad.org/configurations.html and include it as a local module." #-}
moduleXMonad.Config.Dmwit{-# DEPRECATED "This module contains a personal configuration, to be removed from xmonad-contrib. If you use this module, please copy the relevant parts to your configuration or obtain a copy of it on https://xmonad.org/configurations.html and include it as a local module." #-}where
<>(isFullscreen-->doFullFloat)-- TF2 matches the "isFullscreen" criteria, so its manage hook should appear after (e.g., to the left of a <> compared to) this one
moduleXMonad.Config.Droundy{-# DEPRECATED "This module contains a personal configuration, to be removed from xmonad-contrib. If you use this module, please copy the relevant parts to your configuration or obtain a copy of it on https://xmonad.org/configurations.html and include it as a local module." #-}(config,mytab)where
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
