| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
now except the border color does not change.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This new feature creates a 'selected windows' buffer which allows
the user to select windows. These windows are then automatically
made the argument for a Wml window operation such as shifting.
This is great for when one wants to apply an action to a set of windows
which are too difficult to describe with Wml expressions.
In addition, I have added a bunch of mouse bindings and key bindings
to this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added ShiftAndSwap functionality, which allows user to shift a
<windowset> to a <workspace> and then swap that workspace with
another <workspace>
e.g. move Spotify to workspace 's' and put workspace 's' on the last
monitor.
This replaces the shift-and-follow as this is more powerful (shift
and follow just puts the "shifted-to" workspace on the current
monitor.)
ofc if the two workspaces to swap are not visible, this just operates
as a normal shift command.
- Moved more dragging functionality to the Dragging.hs file and cleaned
it up a little. More is certainly needed.
- With the more powerful dragging functionality, many bindings are made
redundant. I replaced one of these redundant bindings (button13 ->
mouseWheel). This used to move the focused window around the stack,
but this has been made redundant by the drag-to-swap functionality
(button14 -> left-click-drag), so now it changes the master region
size.
|
| |
|
|
|
|
|
|
|
|
| |
Dragging a window will leave a hole behind until it reaches its final
destination, making it look a little better.
Now I've also implemented drag so that when ending the drag with a
right-click it tiles the window on the screen it's currently on.
It is still pretty jenky and very much a WIP.
|
| | |
|
| |
|
|
|
|
| |
These new bindings allow the user to click on a window and "drag" it to
a different window. This will swap the two windows once the drag button
is released. The other binding is similar, but for whole workspaces.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
left/right. It is more intuitive and is more flexible. As a part of this, I incresed the timeout for multiple button bindings to 5000ms like how keystrokes work.
|
| | |
|
| | |
|
| |
|
|
| |
made the movement atomic to improve speed
|
| | |
|
| |
|
|
|
|
|
|
| |
1. Change swap windows to be button13 + mousewheel instead of mouse
wheel buttons
2. Change the history double-tap button to focus the window under the
cursor before going back.
|
| | |
|
| |
|
|
|
|
|
|
| |
Perhaps a Python script is in order to make it less ugly, but
as things stand it works.
This also uses the XDG_RUNTIME_DIR to store the variable associated with
the target to control.
|
| |
|
|
| |
This is part of a plan to decouple Spotify from RDE.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Remove a bunch of esentially-unused layouts. Now the layouts are:
- Spiral
- Mosaic
- Tall
|
| | |
|
| |
|
|
|
| |
Button mapping is now similar in architecture to KeyMapping. As a
consequence it works with the pending buffer.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
A "Theater" is basically the state of the "StackSet". This means that
jumping to a Theater will reset all the windows to where they were
when the user last left that theater, or an empty theater if there is
not.
New windows that a theater does not know about are put in the "hidden"
workspace (which is "*").
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
This is the set of the current set of screens and workspaces. It can be
saved and restored. In a sense it works like how most other tiling
managers handle "workspaces" where one can change all screens at once.
Not that it's a superior system to XMonad (it's not), but it's sometimes helpful.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The bordering layout can add windows along the border of the screen,
that way something like videos or something can be shown in the corner
of the screen.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Right now all existing logs are logged at Info, but this will
change. This should make it significantly easier to debug
things wit log levels like Trace. I may at some point define more
log level endpoints or come up with a more expressive logging
system, but this is a good start.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Macros may be defined by using <M-d>
<M-d>w begins defining a windowset macro
<M-d>t begins defining a workspace macro
The next character typed is the key chord to save the macro to. The next
sequence of keys read up until the Return key is the macro value. This
macro may then be used as WML objects.
Macros are pretty primitive right now. I need to think about if it would
be worthwhile to make these macros either take arguments or add some
kind of state to WML a la sed to take a step to make the language Turing
complete, and if such a development would actually be desirable. If
anything it would be an academic exercise.
|
| | | |
|
| | | |
|
