I'm very proud of this bluetooth menu. It allow us to manage our
connection with ease. But most of the time the only thing I want to do
is to connect to devices. Having this device dedicated submenu as extra
step, forward and backward, just to connect, is really annoying.
This add a simple mode to this bluetooth menu. It is enabled by default.
If you select a device with this mode on, you'll connect/disconnect
automatically without entering the device dedicated submenu. For this
workflows to be confortable, I also added paired/connected icons on the
the device entries.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Signed-off-by: Peter John Hartman <peterjohnhartman@gmail.com>
Config file for future xob replacement of dunst as audio and brightness
indicator.
Cloning and building:
https://github.com/florentc/xob
works and displays a bar the same way as wob.
Signed-off-by: hazardchem <pthom44@live.com.au>
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
I was getting ghost wakeups *only* while plugged in, and isolated it to
the battery sending a wakeup which we weren't detecting.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
This will allow the user to decide what to do when there are or are not
notifications. Default is the green led. Users already have control over other
led-behavior in sxmo_hook_lock/unlock/screenoff/postwake/presuspend.
They should also be able ot control whether, e.g., notification is green
or blinks or does nothing.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Turning on debug, I noticed that every 8s or so, it'd try to free
everything in sxmo_hook_check_mutexes.sh, which would call
sxmo_mutex.sh:free() which would call flock, grep, cut, xargs, sed, etc.
Importantly, this would also call sxmo_hook_statusbar.sh lockedby, which
sucks up a lot of CPU.
I decided to move the statusbar update out of mutex, and hvae only one
update for all of check mutexes.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Moreso because I have a lot of userscripts that send popups, but its
kind of annoying to get stale or old notifications when I resume from
suspend.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Rather than in the start hook. This is so when we logout/togglewm
we can have a fairly clean slate.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Gnu find outputs a warning if the maxdepth option appears after any
positional options, such as filtering files, because maxdepth also
affects options that come before it.
As a side note, maxdepth appears to be gnu extension that busybox picked
up, so we might want to be careful about using it.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
I wanted to have no text at all when I start a text message, but setting
SXMO_DEFAULT_DRAFT="" resulted in the code thinking it was not set and
reverting back to the "Enter new text message here." This change fixes
that.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
I'm not sure if this has been a bug all along, or if it is a regression,
but this is necessary in order to reply to a text chain with multiple
numbers.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
This really makes things more sane for debugging. Some noise gets lost,
but you can still always tail -f ~/local/state/superd/logs/* sxmo.log
tinydm.log to catch the context.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Removes some clutter -- this would show up in the compose window if you
use mpris and playerctl, which was ugly.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Sometimes the menu would open before keyboard in sxmo_menu_with_kb.sh.
Reproduce: from main menu, click texts. A small pause is sufficient.
This is bad since then menu overlaps keyboard and you can't type esc
or numbers.
Signed-off-by: Anjandev Momi <anjan@momi.ca>
Superd handles cleaning up any child processes we start, that logic can
be removed from this script. Using superd should also make this more
reliable, and provide better logging facilities.
Signed-off-by: Peter John Hartman <peterjohnhartman@gmail.com>
If the statusbar takes a while to run it will leave the system in an
inconsistent lock state, not waiting for the statusbar reduces the
amount of time we're in this state for.
This might be a slight performance improvement when switching through
multiple modes (e.g. screenoff to unlock) because the statusbar can take
a while to execute normally.
sxmo_daemons.sh is used to so that if the previous execution of the
statusbar is still running, it gets killed to avoid resource exhaustion.
Signed-off-by: Peter John Hartman <peterjohnhartman@gmail.com>
