HdyDialer was deprecated and therefore is replaced with HdyKeypad.
HdyDialer used a `gchr *` to store the entered phone number. On every
button press the entire text of the display entry was replaced with the new
string, which messed up selection and cursor position.
HdyKeypad connects directly to a GtkEntry and inserts each
button press the same way as a keyboard stroke would do.
In the case of the `call display` entry every new digit is appended to the
end of the input and therefore it also moves the cursor to the end of the
entry. Instead of making the Entry not editable, only the events which
would remove text form the entry are blocked, via the `delete-text`
signal. And the signal `insert-text` is used to block unwanted chars
from beeing inserted.
Same as for the `call display` entry also the `new call box` entry is
made editable and the signal `insert-text` is used to block unwanted
chars. All other user action possible on a entry arn't blocked
e.g. repositioning the cursor.
The advantage of making the Entry editable is that we can show
the cursor position.
It also allows the user to select the position where new digits are
inserted in the `new call box`.
On a button press the focus is set to the Entry to give the correct
feedback to the user.
This centers the text on the entry, as required by the design.
This also makes the delete button remove only one char at the time, to
move closer to the desired UX.
Related: https://source.puri.sm/Librem5/calls/issues/58
Fixes: https://source.puri.sm/Librem5/calls/issues/82
Clean up the disconnect messages so they make sense when presented to
the user. Also add new state change reasons from ModemManager 1.10
and 1.12.
Fixes#90
The CallsBestMatchView and CallsPhoneNumberQuery classes are written
in Vala because they may be generally useful and to leave open the
possibility of adding them to libfolks itself, which is written in
Vala.
This is an initial, static implementation of plugins. The
CallsApplication has a plugin name which can be changed with a new
--provider command line option. This plugin name is used to
instantiate the appropriate plugin when the application is activated.
From then on, the plugin cannot change.
In future, we can expand this support to include loading multiple
plugins at once, configurable through some UI. This will have
far-reaching implications though, and complicate things like
enumerating the provider hierarchy. There is also no practical
benefit right now; the mm and ofono plugins can't be used at the same
time because ModemManager and oFono don't play nice together, and the
whole raison d'être of the dummy plugin is undermined if you can make
use of one of the others. So for now, we just implement one static
plugin.
