This is a new approach to cleanup and fix issues we have with the
proximity lock. Discussed between Peter and me over irc.
We set "proximity[un]lock" in SXMO_STATE. This allow the input handler
to ignore power buttons while in this state. We then can't manually
change states anymore. It become possible to configure dedicated
hardware buttons trigger, or gesture trigger, to manage the current
call while in this state, by example.
The proximitylock also setup exclusive flock over the state lock
file (as other state switcher does). It prevent other state scripts to
trigger and to break the state consistency.
We stop the idle_locker to prevent 120s, and 8s timers to move the sxmo
state deeper.
When proximitylock stop, it execute back the initial state script,
to return to initial state.
I'm not sure if a user would ever want to just turn on proximity
lock, and it does kind of make the code ugly and complicated.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
On arch the dialer was crashing because systemd put a directory in
XDG_RUNTIME_DIR that wasn't readable by the user, and find was searching
XDG_RUNTIME_DIR recursively for call state files to delete.
Signed-off-by: Peter John Hartman <peterjohnhartman@gmail.com>
Was easy to produce : Disable wifi with the Config menu then
go to the Networks menu.
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
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.
modemdial doesn't have any long running child processes, so killing them
is totally unnecessary. Also fatelerror was never called after the phone
call was started so it the cleanup it did was unnecessary.
staceee edits:
This script was ugly and needed a rewrite. Aren did the first parts and
I completed this patch.
The current sxmo status bar cause a high cpu usage periodically. It was
working by triggering a script that build the whole line.
This is a proposition to improve this implementation:
The design is very simple. We got a root dir that contains files. We
will cat those file contents sorted by the file names.
This way we can update a specific part and the rewriting will then be
very light.
Some abstraction to make it simple:
$ sxmo_status.sh show
To display the current content
$ sxmo_status.sh debug
To help fuzzy developpers like me
$ sxmo_status.sh watch
To watch updates of the component files. Will stdout the new line on
change.
$ sxmo_status.sh add 99-time "11:35" # or
$ printf "11:35" | sxmo_status.sh add 99-time
To add or re-write the component 99-time with the content "11:35"
$ sxmo_status.sh del 99-time
To drop a component
Then, to wrap some of the sxmo status bar component we will still use
the statusbar hook. It make it easy for the user to override or drop
some components.
$ sxmo_hooks.sh statusbar time
To set the time based on the current time. Here other existing
components:
$ sxmo_hooks.sh statusbar call_duration
$ sxmo_hooks.sh statusbar modem
$ sxmo_hooks.sh statusbar modem_monitor
$ sxmo_hooks.sh statusbar wifi
$ sxmo_hooks.sh statusbar vpn
$ sxmo_hooks.sh statusbar battery
$ sxmo_hooks.sh statusbar volume
Or to rewrite everything:
$ sxmo_hooks.sh statusbar all
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>
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.
This is a huge patch for Swmo, Sxmo over Sway.
It is Dwm backward compatible so dwm users should not expect regressions.
If you install all dependencies, you then can toggle between Sway and Dwm using a new config entry. It will reboot the phone.
This commit also contains:
* Make the modemmonitor bullet proof
* various other smaller fixes
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
We also have to remove them on outgoing call. We use find instead of rm
with a wildcard cause wildcard look not expanded here.
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
When I try to dial a call from 'more contacts', I get
Attempting to dial: +19362396134
Starting call with CALLID: 0
error: invalid call string specified: 'More contacts
0'
This is because dialmenu() is getting an extra 'More contacts'
prepended to the callid it returns on stdout. Make the grep
which is causing that quiet using -q.
I'm not sure why this isn't hitting everyone else.
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Anjandev Momi <anjan@momi.ca>
The dialer only included recent callers, but there was no way to access
the full contact list (contacts.tsv). I added a "more contacts" options
that calls sxmo_contacts --all, providing an alphabetically sorted list
of all your contacts. It also works for the texting menu.
This is a cleaned up version of an earlier patch by Maarten van Gompel.
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
Note prefix stripping was unreliable because any +1XX number would break things.
The advice should be to always dial with +1 / international prefixes and store
contacts in your contacts.tsv with international codes; this way we avoid any
duplicate errors since we can be assured things in mmcli always come back w/
international prefixing automatically.