This reverts commit 4a99991086.
Reason for revert: temporary revert since this breaks the build on most distros that we currently support, including Ubuntu 24.04, and sdbus-cpp 2.0 is not backward compatible with older systemd versions.
GitLab: #1141
Change-Id: I3d50c0a433bd63d7dc76a2659258cf9e38bbbc29
The commands apparently run for each file listed, or something
similar, leading to:
configure: creating ./config.status
config.status: creating test/agent/Makefile
chmod: cannot access 'test/agent/pre-inst-env': No such file or directory
chmod: cannot access 'test/agent/scenarios/bulk-calls/run-scenario': No such file or directory
config.status: creating test/agent/pre-inst-env
chmod: cannot access 'test/agent/scenarios/bulk-calls/run-scenario': No such file or directory
* configure.ac [ENABLE_AGENT]: Separate AC_CONFIG_FILES uses per file.
Change-Id: Ib283955b73540248e09bf31ef44ef3d178b216fa
This approach allows client apps that install ringtones (and any other resources) in custom locations to specify that directory at runtime. This will take precedence over the build time data directory supplied for platforms which install to a fixed path.
https: //git.jami.net/savoirfairelinux/jami-client-qt/-/issues/1619
Change-Id: I81616f79196e645a5ad677d6956be6a2ffcd976a
The goal of this patch is to allow the clients to get a better
sent/read status from the daemon.
API doesn't change much, but internal logic got some changes. For the
client:
+ SwarmMessage now contains a map<string,int> status where string is the
uri of a member, int is the status (0 = sending, 1 = sent, 2 = read)
+ cancelMessage is removed as not used anymore (sendMessage with flag=1
will edit a message)
+ getMessageStatus is removed as the status is sent in the SwarmMessage
+ accountMessageStatusChanged is now emitted for swarm messages when a
fetch or setDisplay occurs. Client must handle this signal correctly.
+ Previous code to manage last displayed, fetched status is now merged
with message status
+ Sync info is done when the sync is opened, else status are not updated
correctly
GitLab: #948
Change-Id: I60763d4de8a995c6fc9f6df6434e266211f8dc2f
This heavily changes the API for the client. The goal here is
to move the logic to construct the history to show in the daemon
and not the client. This has several advantages:
1. Logic is common across every platforms, so bugs should not be
platform-specific
2. Client got less logic
3. Signal are simplified, if an edition comes, "MessageUpdated"
will be triggered instead MessageReceived.
4. Some tests are added for linearizing the history.
5. Search on edition is fixed.
Tests got heavily re-written, but the content didn't change (2 tests
are added, the rest is simplification).
GitLab: #831
Change-Id: Ie7c81077067e9e49db1dd396829c9225c0512c16
This is a follow-up commit to
3dd5f4ebfd ("dbus: use sdbus-c++ for
dbus communications"). The build should abort if the sdbus-c++ module
is missing (it's "required" on the CMake side, so why shouldn't it be
on the Autotools one?).
* configure.ac: Fail when sdbus-c++ is not found. Quote the
sdbus-c++-xml2cpp command.
Change-Id: I8268abec10ba5be0eb8b520988affc9c0345a4fb
This patch introduces the ability to start calls and extends the
usage of rendezvous points to swarm with multiple participants.
When starting a call in a swarm with multiple participats, one device
will work as the host of the conference, and the caller will
immediately start the call alone.
Other peers will receive a commit and a notification to be able
to join the active call. To join a call, users needs to call
rdv:uri/device/convId/confId to be added (if authorized) to the conf.
There are some majors differences in the process.
First, every conversation will be able to decide a default host
for conferences. This still needs some design and will be
introduced in another patch. For now, the caller is the host.
Then, because all members of the call may not be interested to join
a call, or they may want to get several calls at the same time, the
system must be able to manage more than one active calls (e.g. a
company with multiple projects can do several standups at the same
time).
Finally, in the conversation, two commits will be generated to be
able to know what active calls are available. The first is
announcing that a conference started, the second announces that
the conference stopped (the host closed the call).
However, this introduces a difficulty. The host may crash and not
commit the end of the call in time. In this case, hostedCalls are
stored in a file and the conversation is updated during the init
of the daemon.
Change-Id: I081a4920edb3773bbed884ae50f34e476ad42094
Documentation: https://docs.jami.net/technical/swarm.html#call-in-swarm
GitLab: #312
It's not possible to replace the DRing namespace for jami because of conflicts
with namespaces and classes defined under the jami namespace. Thus, use libjami
as the namespace.
Script to reproduce:
rg -l DRing | sort | uniq | awk '$0 !~ /NEWS/' | xargs sed -i -e 's|DRing|libjami|g'
rg -l DRING_ | sort | uniq | xargs sed -i -e 's|DRING_|LIBJAMI_|g'
sed -i -e 's|dring|jami|g' src/jami/CMakeLists.txt
sed -i -e 's|dring|jami|g' src/jami/def.h
Change-Id: I80e8c8b58a7586527a016bbef850bab07869c473
This store user's preferences per conversation into
conversation_data/<convId>/preferences
In this way, the daemon is able to sync this file across devices
and remove preferences at the same time we remove the conversation.
For now, only support "color" and "ignoreNotifications"
The preferences are synced via partial SyncMsg sent across devices.
Change-Id: I8fe74cc06733ad61d45d721e0264b1941d4cf122
+ Bump deamon version to enable multistream
+ use signal for recorder to check if file stopped
+ answerMediaChangeRequest pass isRemote for tests
Change-Id: I396b8246264cb7826350f75e74f20f05b864f384
The agent requires Jami's bindings to correctly run scenario. This
can only be done if Guile can find the correct scripts. Thus, the
pre-inst-env script can be used to setup the correct environment for
running the agent before its installation.
Change-Id: I474ef204bb33fd2098eee44b5b99c00f120c4536
The current design got some limitations. It's not possible to
control informations per shared media. This means that we can't
got several active sinks for example.
The goal of this patch here is to update the conferences orders
to be able to control the state of each sink individually and for
the client to be able to handle conferences with accounts connected
via several devices with several medias per devices.
So each orders is sent with a different level (account/device/media)
For example, we will be able to send a moderator order for an account,
to hangup a device or to set a media active.
To support those orders, both sides MUST be patched. Else, the old
protocol will be used. The version of the protocol supported is sent
in the conferences informations to notify the peer what version to use.
Finally, this patch changes some APIs to support multisteam:
+ Some APIs now takes the deviceId or the sinkId when necessary
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Doc: https://git.jami.net/savoirfairelinux/jami-project/-/wikis/technical/6.1.-Conference-Protocol
Change-Id: Ieedd6055fd43b2a09b2cc8b253dcd6a3bf260a39
