This one is a bit tricky:
* Clicking on an active xrandr output will disable it
* Clicking on a disabled xrandr output will enable it -> if
it is a left-click, it will put it as the left-most display
if it is a right-click, as the right-most display
Also, it will reload the i3 bars (using a script that allows
you to write custom pieces of an i3 configuration that is applied
conditionally depending on the screens you have).
It goes like this:
* Base config is in ~/.i3/config.template
* Output-specific config is in ~/.i3/config.<screen name>
* Output-specific config when other screens are also active is in
~/.i3/config.<screen>-<other-screens-in-alphabetic-order>
For instance:
$ ls ~/.i3
config.template
config.eDP1 -> will be applied to eDP1 (always)
config.VGA1-eDP1 -> will be applied to VGA1, if eDP1 is also active
config.VGA1 -> will be applied to VGA1 (if eDP1 is inactive)
fixes#19
This modules shows attached displays and their states (on or off).
Future versions of this module will order the icons by the relative
order of the screens (left-to-right) and will allow switching monitors
on and off.
see #19
Add the possibility to specify a list of commands to be added as
callbacks. Commands will be executed one after the other, waiting for
the previous command to finish execution.
Due to a bug, when the destination was unreachable, the checking thread
would terminate, effectively keeping the widget stuck in "unreachable"
mode.
Now, enable recovery by keeping the thread running even if the target is
not reachable for some time.
Add controls that allow the user to switch to the next and previous song
in cmus, toggle shuffle and repeat. Pause/play is toggled by clicking on
the song title itself.
fixes#5
Allow the user to use all tags read by cmus (cmus-remote -Q|grep ^tag)
as part of the displayed data (plus the special 'tags' "duration" and
"position").
This callback just makes it really hard to see for the user what is
going on. The alias the user provides should *always* match the
instance, so that it can be used in a meaningful way in the click
action, for example (otherwise, something like "nautilus {instance}"
gets really hard to interpret.
This is now much nicer implemented to address issue #3. A user can now
have a configuration parameter mapped to a module instance (via the
module name or the instance name) with the value "left-click",
"right-click", etc., like this:
-m disk:home -p home.left-click="nautilus {instance}"
Big oversight in my previous commits: Widgets need to be able to have
specific configurations (i.e. the path for different instances of the
"disk" module has to be different).
To account for that, it is now possible to assign an "alias" to a module
instance using ":" (for example: -m "disk:home"). This alias is then
used for the configuration parameter resolution automatically, for
example:
-m disk:home -p home.path=/home
As a consequence, parameter names in the module code are now relative to
the module, which means: shorter!
