This patch adds a new hook that's called when the user submits an
unknown choice to a contextmenu. This is useful to be able to
handle arbitrary text inputs beyond the listed choices. This can
be used to search files, do a web search, run commands, etc.
The hook takes two arguments: the $WINNAME of the contextmenu that
was used and the $CHOICE typed into the menu by the user. This
should allow fine-grained control of the fallback depending on
where the choice was entered.
In my personal config I currently use a simple script just to open
URLs or search the web. You can see it here:
https://git.sr.ht/~brecht/sxmo-config/tree/master/item/hooks/contextmenu_fallback
Signed-off-by: Peter John Hartman <peterjohnhartman@gmail.com>
When selecting "YouTube" from the scripts menu "YouTube (audio)" was
being selected. This happens because the audio version is first in the
choices list so it was matched first when grepping for "YouTube".
This patch solves that by requiring the name of the entry to match
exactly, not just contain the selected item.
Signed-off-by: Anjandev Momi <anjan@momi.ca>
We need the recent -S (status) command to probe the real state of
callaudiod.
- Lot of cleanup and refactorisation
Most of the code has been moved to a better place. The call audio
setups, the pickup action and the incall menu now are three different
things we can call individually.
- Handle failures individually
Every important task as the mmcli command or volume settings should warn
a urgent message to the user if they failed.
If we failed to setup audio, or to pickup the call then we dont even try
to open the incall menu.
- Made the incall_menu closeable and re-opennable
You can close the incoming call menu and the incall menu and re-open
them from any menu.
To make this possible I moved some of the responsibilities to the
modem monitor that trigger action after modem manager signals. We then
check at this point if it was the last call and do some cleanup if so.
- Initial work for concurrent calls
Added some code to the hooks and the modem checkfinished and
checkincoming calls to handle those cased. If you are in a call and someone
else try to call you, we refresh the incall menu and new entries will allow
you to switch calls.
- The incall menu isnt sticked to one call
This menu itself doesnt need a CALLID argument. It allow us to
manage every active call. We should be able to hold and hangup and
switch calls as we want.
In ssh, using sxmo_appmenu.sh > text > tail a conversation then Ctrl+C
will let a dangling tail -f process.
I think this is caused by this & wait. Ctrl+C was actually killing
sxmo_appmenu.sh instead of the running sxmo_modemtext.sh
I'm not sure if this was needed for some reason. I tested a little bit
without noticing a regression
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
- Move sxmo icons in sxmo_icons.sh
This script should be loaded when icons are needed
- Move init env variable setups in a /etc/profile.d/sxmo_init.sh
This script is loaded by tinydm and for ssh/tty logins.
The logged in user can re-trigger check_sxmo_wm if they toggle wm.
- sxmo_commons.sh now only load aliases. It can be loaded by scripts to
ensure busybox compatibility
- moved some parts of ~/.config/sxmo/xinit to ~/.config/sxmo/profile
This file also is loaded just before starting sway. It goal is to setup
env variables dedicated to sxmo
~/.config/sxmo/xinit only goal is now to trigger some dwm dedicated
things (as ~/.config/sxmo/sway can start exec commands to)
To recap, loads orders are :
tinydm:
/etc/profile.d/* # do not set SXMO_WM
~/.profile
sxmo_winit.sh:
~/.config/sxmo/profile
sxmo_xinit.sh:
~/.config/sxmo/profile
~/.config/sxmo/xinit # to start sxmo_hooks.sh
ssh/tty:
/etc/profile.d/* # will set SXMO_WM
~/.profile
- unify sxmo_winit.sh and sxmo_init.sh
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
Add a sxmo_daemons to manage all sxmo daemons
$ sxmo_daemons.sh start mmsd mmsdtng
$ sxmo_daemons.sh start network_monitor sxmo_networkmonitor.sh
$ sxmo_daemons.sh start sleepy sleep 2
$ sxmo_daemons.sh start network_monitor sxmo_networkmonitor.sh
-> This will stop the old daemon and start a new one
$ sxmo_daemons.sh running network_monitor
network_monitor is still running
$ echo $?
0
$ sxmo_daemons.sh running unknown
unknown is not running
$ echo $?
1
$ sxmo_daemons.sh running sleepy
sleepy is not running anymore
$ echo $?
2
$ sxmo_daemons.sh running network_monitor -q && echo "tada !"
tada !
$ sxmo_daemons.sh stop network_monitor
$ sxmo_daemons.sh stop all # to stop every managed daemons
We can now start, stop and check daemons status with ease. When
dwm/sway shutdown, we stop all daemons. Restarting or toggleing window
manager cannot leave any dangling daemons anymore.
As you can see, all daemons now start from the start hook. We gave the
full power on the user to disable or add daemons.
This patch is painfull cause I had to make sure every daemons behave
correctly and shutdown gracefully when killed (which was definitely not
the case !).
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
Any sane linux system will have a posix compliant shell at /bin/sh
This change will allow us to better detect running scripts using pgrep.
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
For aesthetic reasons. Also, bizarrely, this problem:
https://todo.sr.ht/~mil/sxmo-tickets/218
is resolved by changing to off then crust rather than lock then crust.
(No idea why because on my pinephone lock then crust works fine.)
Signed-off-by: Stacy Harper <contact@stacyharper.net>
This make it easier for user to override it with this template. Plus, it
fix a bug we had with the user hook usage (missing parenthesis).
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Anjandev Momi <anjan@momi.ca>
In sxmo_modemmonitor.sh checkfornewtexts() we should skip MMS and SMS WAPs,
which will be SMS messages with text of "--" or no TEXTDATA at all. Hence,
there are a couple small checks in checkfornewtexts() to do that.
As well, there is a further dbus-monitor call in sxmo_modemmonitor.sh that
monitors org.ofono.mms.Service for 'MessageAdded' to process a new MMS messages.
Most of the action happens in sxmo_modemmonitor.sh processmms().
An MMS message might be either a message with an attachment to one recipient
OR a message with multiple recipients ('Group Chat') and no attachments (or
some attachments).
Attachments get placed in ~/.local/share/sxmo/modem/$PHONENUMBER/attachments/.
They are named $PAYLOAD.jpeg, $PAYLOAD.mp3, etc., where $PAYLOAD is the unique
id that mmsd-tng assigns the mms and stores in ~/.mms/modemanager/. (Note that
since the PAYLOAD file remains on the filesystem, we could just re-extract the
attachments whenever we want them. This might be an improvement down the road.)
If there are multiple recipients, we will make a "unique" new phone number out
of *all* the numbers involved (to and from) for each group chat. For instance,
if you and Bob and Suzie are on a group chat you will have a number like
+15551234567+16661234567+17771234567 in ~/.local/share/sxmo/modem. You can
treat this like a normal number (i.e., give it a contact name, reply to it,
etc.)
Once an MMS message has arrived, one notification will be made like normal.
If there are attachments, clicking on the notification will open them all using
sxmo_open.sh.
You can also go to the message (via Texts) and click View Attachments to run
sxmo_files.sh on the attachments directory.
You can also Add an attachment when you compose a message. There is a basic
ability to Delete attachments too.
I've also reversed the contact lists so the CONTACTNAME is on the left and PHONENUMBER on
the right, otherwise with large phonenumbers it was hard to see who the CONTACTNAME is.
=== MMSD-TNG CONFIGURATION TIPS AND TRIPS ===
sxmo's mms requires mmsd-tng that includes the mmsctl program. Right now, this is
in the latest git head. See https://gitlab.com/kop316/mmsd/-/merge_requests/52.
To compile with this on edit meson_options.txt and set mmsctl to true. Then build as normal
via mmsd-tng's README. (We can also just do: gcc -o mmsctl mmsctl.c -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -ldbus-1 -ljson-c)
sxmo's mms does not require any configuration on top of what is needed to get mmsd-tng to work.
However, mmsd-tng can be a bit of a tricky thing to confugre, so here are some tips:
1. mmsd-tng includes example configurations in its README. A helpful list is here:
https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info
Here is an example (works with "Mint Mobile" which uses T-Mobile):
~/.mms/modemmanager/mms
[Modem Manager]
CarrierMMSC=http://wholesale.mmsmvno.com/mms/wapenc
MMS_APN=Ultra
CarrierMMSProxy=NULL
DefaultModemNumber=NULL
AutoProcessOnConnection=true
AutoProcessSMSWAP=true
[Settings]
UseDeliveryReports=false
AutoCreateSMIL=false
ForceCAres=false
TotalMaxAttachmentSize=1100000
MaxAttachments=25
2. mmsd-tng must use the *modem's* dns to resolve mms files. Since
NetworkManager rewrites /etc/resolv.conf with both wifi and modem active, I
found it easiest to have a static /etc/resolv.conf and to set
/etc/NetworkManager/NetworkManager.conf dns=none.
The main goal of this patch is to simplify the locking and unlocking
flow in sxmo.
The idea is to manage effectively and with ease the screenlock state
with only one button.
Pressing power button will rotate the screen lock from
unlock -> off -> lock -> unlock -> …
You can also double power button to jump in the target state
faster. Example :
unlock -> [double power] -> lock
off -> [double power] -> unlock
lock -> [double power] -> off
In short, this is the same circle in reverse order.
Some of the other inputs has been changed to make this coherent.
in short:
VOLUP: 1 = menu; 2 = sysmenu; 3 = list all windows;
VOLDOWN: 1 = keyboard; 2 = change window; layout 3 = close/kill windows;
POWER: 1 = deeper lock; 2 = higher lock; 3 = open a terminal
As you can see, we cannot suspend with only the power button.
To access suspension, we rely on swayidle/xprintidle to rotate the
screen lock from
lock -> off -> crust (8 seconds the first step, then 8 seconds for the
second)
So buttons will wake the phone up and idle will make the phone to sleep,
step by step.
With this behavior, you can run a video with mpv then double power to
lock the screen (blue led). Swayidle will not off then suspend cause mpv
is an idle inhibitor by itself.
While in crust, the powerbutton will then "uncrust" and the action will
still be handled by sxmo to move you back to "lock". Waiting 8 seconds
will move you to "off" then 8 additional seconds to go back to "crust".
I also added a hook to detect and disable the idle daemon in some cases
(mpc playing, proximity lock on, ssh session active). It is a hook the
user can override and extends.
I added a simple script to have some sort of swayidle on xorg for
backward compatibility.
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
At this moment, we list the files in .config/sxmo/userscripts/ to add
entries on the Userscripts submenu.
This way we cannot customize the entry label cause the script filename
will be the displayed entry. So we cannot use icons or emojies in the
label.
With this patch, we can use a plain text file located at
~/.config/sxmo/userscripts as appmenu entries, instead of a directory at
this same location.
This file can be formated like this:
AddEvent ^ 0 ^ ~/bin/add_event
Mail ^ 0 ^ ~/bin/mail
Weather ^ 0 ^ sxmo_terminal.sh -f "monospace:size=5" sh -c "curl http://wttr.in/ | less -SR"
This allow the entry name to be different from the command it runs.
This also allow icons in the entries.
This also allow single line little scripts.
This patch still allow the current behavior with directory listing. The
location can be either a file, or a folder.
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
adding -s 300 after -k Escape seems to give vis/vim/vi time to enter
command mode and be able to receive the commands (wq, etc.) otherwise
it didnt work.
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
We had issue in ssh mode and this new bemenu curses mode.
No issue on other sxmo menu that use successive bemnu but this appmenu
loop displaying some ~F char when you select a subentry.
I refactorised a little bit this script and now it works well. I'm not
stil not sure of what was causing this.
By the way I changed some echo for printf. I also added the wrap
argument for bemenu in ssh mode.
