- 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.
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`.
Ever since ce5aae54035957846baa68f8980218cd11334722 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.
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).
Despite myLayouts currently being more popular in examples, make
them all myLayout as in man/xmonad.hs to avoid mixing them in the
same module as was done a few places, leading to confusion for some users.
