| Age | Commit message (Collapse) | Author |
|---|
|
Yeah, GObject is pretty obscure here. But to get the implementation's
override function, we want GET_INTERFACE, otherwise we're looking at
some random memory location that's sometimes NULL. And then we crash.
|
|
|
|
The interfaces usually retrieve objects (e.g. skeletons) from the Modem object
using g_object_get(), but we didn't make sure that these objects were actually
valid before using them.
This should clean up errors happening when the modem gets unplugged and still
some actions are ongoing.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=685933
|
|
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
|
|
When a user creates an SMS object, we will expose all its properties in DBus
properly, but we will not create the internal list of SMS parts.
The list of SMS parts will be created when the SMS is stored or sent, whatever
comes first. When the message is sent and it was previously stored, the list of
parts is not re-created.
If the message requires multiple parts, the multipart reference is computed as
follows:
* If the SMS was not stored and is being sent, we just use a random number.
* If the SMS is being stored, we will use a multipart reference which is not
being used already in another SMS to the same destination.
|
|
Instead of letting the plugins specify a default storage to use, just look at
the supported ones and use the best one.
"MT is preferred over "ME" or "SM", as "MT=ME+SM"
|
|
There is no point in specifying a default 'mem1' memory storage, which is used
for reading/listing/deleting, as those are operations that need a specific
'mem1' set each time.
Also, there is no point in specifying separate default 'mem2' and 'mem3' memory
storages, specially because now we allow Sms.Store() to specify a storage.
So, we will now only have a 'default' memory storage, which is applicable for
both 'mem2' and 'mem3' (storing, sending from storage and deleting).
|
|
We will list which are the storages allowed to use when receiving/storing SMS
messages.
|
|
Selection specific storages to run actions on them can now be done with the
broadband-modem-specific lock|unlock_sms_storages() methods.
|
|
We really want the 'mem3' storage set as soon as possible.
|
|
We can now check whether a specific storage is valid for receiving or storing.
|
|
So that plugins can subclass the generic SMS object.
|
|
|
|
|
|
load_supported_storages may fail, which results in unallocated storage
memory. This patch modifies load_initial_sms_parts_from_storages and
is_storage_supported to handle that gracefully.
|
|
|
|
* mm_base_modem_peek_port_* () will return either a port object (no new
reference), or NULL if none available.
You would usually peek() a port if you're going to use it just in the current
method, as there is no way to that reference to get invalid (we're single
threaded).
* mm_base_modem_get_port_* () will return either NEW references to valid
port objects, or NULL if none available.
And, you would usually get() a port, whenever you want the port object to be
valid even out of the current method, for example when keeping it in the
context of an async operation.
Also, we need to consider that the primary AT port MAY BE NULL when you
peek() or get() it. This is due to the fact that we may be releasing ports
(due to device disconnection) in the middle of async operations.
|
|
Renamed `MMCommonSimpleProperties' to `MMSimpleStatus', and removed the
`MMSimpleStatusProperties' provided in libmm-glib. We'll just use the original
one from libmm-common always.
|
|
Renamed `MMCommonSmsProperties' to `MMSmsProperties', and removed the
`MMSmsProperties' provided in libmm-glib. We'll just use the original one
from libmm-common always.
|
|
|
|
|
|
They will all get it themselves.
|
|
|
|
|
|
|
|
|
|
|
|
storages
|
|
|
|
|
|
An SMS must be first created with the Messaging interface, and then sent using the
Send() method from the SMS-specific interface.
|
|
Uncompleted multipart SMS will be exported to DBus, where only the "state"
property is valid, so that we allow completely removing those uncompleted
multipart SMS which will never get completed due to one reason or another.
|
|
|
|
|
|
|
|
We will instead not export an SMS until completed and assembled
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The interface won't be exported if the given check fails.
|
|
|
