The numeric addresses property conveys no additional information.
By changing the logic here we can get rid of the "numeric-addresses" property
alltogether.
And adapt to changes
It's easier to track changes if we are using GListModel than
a GList. Also, eventually we shall have multiple providers,
and we can use GtkFlattenListModel to merge multiple origins
without manually managing pointers ourself.
Since several widgets has APIs to handle GListModels, it will
also help us create widgets from GListModels easily.
This removes the status message at the end of the NewCallBox, since it
will be replaced by a permanent InfoBar.
As a side effect this removes also the disconnect message when a call
ends.
Fixes: https://source.puri.sm/Librem5/calls/issues/119
How `g_type_class_peek ()` was used it didn't return the correct parent
class in most cases.
G_DEFINE_TYPE macro creates a pointer we can use to get the parent
class `n_p_parent_class`.
Because we didn't use the correct parent class the object initialisation
wasn't fully completed for some GtkWidgets.
See https://developer.gnome.org/gobject/stable/chapter-gobject.html#gobject-instantiation
for more information.
This commit makes use of the `n_p_parent_class pointer` created for this
specific use case where ever possible.
Fixes: https://source.puri.sm/Librem5/calls/issues/118
This adds a style.css file to allow the use of custom css
Fixes https://source.puri.sm/Librem5/calls/issues/115:
- Making the phone number larger
- Moving the delete button to the bottom
- Rounding all buttons, and making the grid buttons circular
- Making the call button a bit less wide
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
Use the "number" property of the dial pad for the dialed number which
takes care of cycling buttons. While we're at it, also make the clear
button external to the number entry box, enlarging it and turning it
into a backspace button.
Closes#12
Modems being added or removed were not working. To fix this, we pay
attention to the "object-removed" event and not just
"interface-removed".
Also, to deal with ModemManager appearing and vanishing, we add a
GDBus watch on ModemManager's D-Bus object.
Finally, we provide appropriate UI feedback when it's not possible to
make a call.
Closes#15Closes#16
