Kaidan issueshttps://invent.kde.org/network/kaidan/-/issues2023-08-09T14:06:10Zhttps://invent.kde.org/network/kaidan/-/issues/423Follow-up from "Implement XEP-0444: Message Reactions"2023-08-09T14:06:10ZMelvin Keskinmelvo@olomono.deFollow-up from "Implement XEP-0444: Message Reactions"The following discussion from !879 should be addressed:
- [x] @lnj started a [discussion](https://invent.kde.org/network/kaidan/-/merge_requests/879#note_542642):
> How about not using QVariantMap, but a QVector of Q_GADGETs?The following discussion from !879 should be addressed:
- [x] @lnj started a [discussion](https://invent.kde.org/network/kaidan/-/merge_requests/879#note_542642):
> How about not using QVariantMap, but a QVector of Q_GADGETs?Melvin Keskinmelvo@olomono.deMelvin Keskinmelvo@olomono.dehttps://invent.kde.org/network/kaidan/-/issues/422Refactor roster item positioning2022-10-29T11:32:32ZMelvin Keskinmelvo@olomono.deRefactor roster item positioningThe following discussion from !860 should be addressed:
- [ ] @lnj started a [discussion](https://invent.kde.org/network/kaidan/-/merge_requests/860#note_542637):
> I think this function has two different use-cases. Can you make t...The following discussion from !860 should be addressed:
- [ ] @lnj started a [discussion](https://invent.kde.org/network/kaidan/-/merge_requests/860#note_542637):
> I think this function has two different use-cases. Can you make two separate functions out of it?
> * `positionToInsert(RosterItem) -> int`
> * `newItemPosition(int currentIndex) -> int`
>
> Maybe you can also avoid the `newPosition - 1` above by doing that in the function then?
>
> And is it correct that `beginMoveRows()` always uses `newPosition` but `m_items.move()` uses `newPosition - 1` in some cases?Melvin Keskinmelvo@olomono.deMelvin Keskinmelvo@olomono.dehttps://invent.kde.org/network/kaidan/-/issues/421Use MessageComposition for all kinds of messages from QML2023-10-07T11:44:09ZLinus JahnUse MessageComposition for all kinds of messages from QML`MessageComposition` should probably contain a full `Message` object.
- [ ] Message corrections
The current message from the MessageModel could be fully loaded into the `MessageComposition`, be edited in there and then resent. This w...`MessageComposition` should probably contain a full `Message` object.
- [ ] Message corrections
The current message from the MessageModel could be fully loaded into the `MessageComposition`, be edited in there and then resent. This would solve the issue that we currently don't resend the full edited message (I think currently we only send the new body).
Corrections are currently done through
1. `MessageModel::correctMessage(replaceId, body, spoilerHint)`
2. `MessageModel::sendCorrectedMessageRequested()`
3. `MessageHandler::sendCorrectedMessage(Message msg)`
and should be done via properties of `MessageComposition` & `MessageComposition::send()`.
- [ ] !1067: send "normal" messages without `MessageHandler::sendMessage(to, body, isSpoiler, spoilerHint)`https://invent.kde.org/network/kaidan/-/issues/420Follow-up from "Send encrypted messages for inactive chats"2022-10-13T16:57:35ZLinus JahnFollow-up from "Send encrypted messages for inactive chats"The following discussion from !852 should be addressed:
- [ ] @lnj started a [discussion](https://invent.kde.org/network/kaidan/-/merge_requests/852#note_539676):
Re: `MessageHandler::send()`
```cpp
QFutureInterface<QXmpp:...The following discussion from !852 should be addressed:
- [ ] @lnj started a [discussion](https://invent.kde.org/network/kaidan/-/merge_requests/852#note_539676):
Re: `MessageHandler::send()`
```cpp
QFutureInterface<QXmpp::SendResult> interface(QFutureInterfaceBase::Started);
const auto recipientJid = message.to();
auto sendEncrypted = [=, this]() mutable {
await(m_client->send(std::move(message)), this, [=](QXmpp::SendResult result) mutable {
reportFinishedResult(interface, result);
});
};
auto sendUnencrypted = [=, this]() mutable {
await(m_client->sendUnencrypted(std::move(message)), this, [=](QXmpp::SendResult result) mutable {
reportFinishedResult(interface, result);
});
};
// If the message is sent for the current chat, its information is used to determine whether to
// send encrypted.
// Otherwise, that information is retrieved from the database.
runOnThread(MessageModel::instance(), [accountJid = AccountManager::instance()->jid(), recipientJid]() {
return MessageModel::instance()->isChatCurrentChat(accountJid, recipientJid);
}, this, [=, this](bool isChatCurrentChat) mutable {
if (isChatCurrentChat) {
runOnThread(MessageModel::instance(), []() {
return MessageModel::instance()->isOmemoEncryptionEnabled();
}, this, [=](bool isOmemoEncryptionEnabled) mutable {
if (isOmemoEncryptionEnabled) {
sendEncrypted();
} else {
sendUnencrypted();
}
});
} else {
runOnThread(RosterModel::instance(), [accountJid = AccountManager::instance()->jid(), recipientJid]() {
return RosterModel::instance()->itemEncryption(accountJid, recipientJid).value_or(Encryption::NoEncryption);
}, this, [=, this](Encryption::Enum activeEncryption) mutable {
if (activeEncryption == Encryption::Omemo2) {
auto future = m_clientWorker->omemoManager()->hasUsableDevices({ recipientJid });
await(future, this, [=](bool hasUsableDevices) mutable {
const auto isOmemoEncryptionEnabled = activeEncryption == Encryption::Omemo2 && hasUsableDevices;
if (isOmemoEncryptionEnabled) {
sendEncrypted();
} else {
sendUnencrypted();
}
});
} else {
sendUnencrypted();
}
});
}
});
return interface.future();
```
> This is complex and has too many thread jumps and generates another QFuture just for sending a simple message.
>
> Ideas from me how to fix this:
> * cache the usable devices property
> * use a parameter here and decide whether to encrypt when calling this (e.g. already in the MessageModel, it seems to be much easier there)
Solution would be to use a proper CacheMelvin Keskinmelvo@olomono.deMelvin Keskinmelvo@olomono.dehttps://invent.kde.org/network/kaidan/-/issues/419RosterItem: Use spaceship operator2022-10-11T18:00:47ZLinus JahnRosterItem: Use spaceship operatorReplace different implementations of `<`, `>`, `<=`, `>=`, `==` and `!=` with the C++20 `<=>` spaceship operator.Replace different implementations of `<`, `>`, `<=`, `>=`, `==` and `!=` with the C++20 `<=>` spaceship operator.https://invent.kde.org/network/kaidan/-/issues/418Make MediaUtils::mimeDB thread_local static, use it everywhere2022-10-02T20:23:46ZLinus JahnMake MediaUtils::mimeDB thread_local static, use it everywhere1. I think we're currently using that mime db from multiple threads which is an issue.
2. There are places where we stil create a temp. QMimeDatabase(); use the one from media utils1. I think we're currently using that mime db from multiple threads which is an issue.
2. There are places where we stil create a temp. QMimeDatabase(); use the one from media utilshttps://invent.kde.org/network/kaidan/-/issues/417error while loading shared libraries: libZXingCore.so.12022-10-15T11:07:34ZEn Ricoerror while loading shared libraries: libZXingCore.so.1Hello,
sorry for posting here but there is no "Kaidan" section in bugs.kde.org.
The bug is really simple: I run KDE Neon and I've installed Kaidan with "apt install kaidan", but the software doesn't start. If I run the "kaidan" command ...Hello,
sorry for posting here but there is no "Kaidan" section in bugs.kde.org.
The bug is really simple: I run KDE Neon and I've installed Kaidan with "apt install kaidan", but the software doesn't start. If I run the "kaidan" command in the Konsole, this message is shown:
kaidan: error while loading shared libraries: libZXingCore.so.1: cannot open shared object file: No such file or directory
P.S. this is the installed package: kaidan/focal,now 0.5.0-0xneon+20.04+focal+release+build12 amd64https://invent.kde.org/network/kaidan/-/issues/416Next iteration of thread and class architecture2022-09-24T10:47:29ZLinus JahnNext iteration of thread and class architectureThese are some of my thoughts about the current state of the thread and class architecture in Kaidan.
I'm sharing them with you
### 1 What has changed recently / our new tools
* **1.1** QXmpp offers async APIs with QFutures
* **1.2** ...These are some of my thoughts about the current state of the thread and class architecture in Kaidan.
I'm sharing them with you
### 1 What has changed recently / our new tools
* **1.1** QXmpp offers async APIs with QFutures
* **1.2** Signals have been replaced by QFutures in many places in QXmpp
* Kaidan could also start to use QFutures to replace some signals
* **1.3** We can easily execute lambdas on another thread with `runOnThread()` or the cross-thread `await()`
* **1.4** We started to use the watcher idiom
### 2 Issues with the current architecture
* **2.1** We can't handle signals from objects from the XMPP thread (MessageHandler, RosterManager, etc.) from QML.
* In QML `Connections` does not work on objects from different threads
* => we need additional wrapper classes on the main thread
* => there are many classes for one purpose: e.g. QXmppRosterManager, RosterManager, RosterController, RosterModels (if we want to have multiple independent views)
* **2.2** We need to create `*Requested()` signals to access the XMPP thread objects (avoidable in C++, required for QML)
* **2.3** We need many additonal **thread-safe** "caches" classes (e.g. TransferCache or ServerFeaturesCache)
* some could be part of an existing controller class
* it would be nice to avoid having to deal with thread-safety at all (e.g. no mutexes)
* **2.4** Too many thread interactions
* in some places the logic is complicated just because of the thread interaction
* sometimes values need to be cached somewhere on the main thread and need to be updated via signals just because the Manager class runs on another thread
* sometimes the code is not "linear" because of jumps with `*Requested()` signals back and forth between threads,
as a result the code is hard to read
* **2.5** MessageModel and RosterModel act as controllers not just as data models
* it's not possible to create two message/roster models to view two different chats
* not well structured: especially the message model does many things unrelated to just viewing the messages, e.g. it also does chat markers, chat states and OMEMO management
=> the code is not encapsulated => large maintenance effort
* **2.6** In some places there still are manual `Connections` in QML where a watcher idiom would be much better
Issues I don't know how to solve them yet:
* **2.7** the database/model situation is very complicated
* insert/delete/update is "duplicated" in the models and in the db
* we had issues because code was executed in the model before it was in the database (or something like that), see !822
* it's much faster to use cached data, but as a result of that there is no single place of truth
<!-- * there's no central place of truth -->
### 3 Ideas for improvements
* **3.1** Replace Kaidan managers (RosterManager, MessageHandler, …) on the XMPP thread with controllers on the main thread
* the QXmppClient and its extensions stay on the XMPP thread
* the controllers use `runOnThread`, cross-thread `await` and signal connections to communicate with the QXmpp client extensions
* QML never accesses objects from another thread (so no additional wrapping classes are needed) (solves **2.1**)
* all of the controllers/managers/models/db classes live on the same thread (solves **2.4**)
* only the QXmpp client extensions live on the XMPP thread
* note: the DB classes internally run lambda functions on the database thread, but live on the main thread
* thread safety is no issue anymore (solves **2.3**)
* no mutexes are needed when communicating with the QXmpp client extensions (because of QFutures and signals)
* no thread-safe "caches" are required anymore, the existing (or additional) controllers can be used directly
* finally no `*Requested()` signals anymore (solves **2.2**)
* all models and controllers run on the same thread
* QXmpp client extension communication is done by using await, runOnThread and "normal" signal connections
* **3.2** Splitting up RosterModel and MessageModel (solves **2.5**)
* RosterController and MessageController should handle everything that is not related to presenting the data via QAbstractListModel
* the models should be creatable from QML
* the models should attach to the controllers to receive updates
* **3.3** About **2.6**: Just use new watchers and replace signals, e.g. for interaction with the TransferCache
### 4 Questions
* **4.1** How *exactly* do the controllers handle multiple accounts (and so multiple clients and managers)?
* definitely solvable
* **4.2** How exactly do we communicate the updates from the Roster/MessageController between multiple models?
* **4.3** Are there issues/disadvantages with **3** (and especially **3.1**)?
* **4.4** How can we do a smooth transition without touching too much code?
* Yes, we can do **3.1** in small(er) steps:
* We can start with adjusting parts of the code, e.g. replacing the RegistrationManager, the UploadManager or the OmemoManager with controllers
* MessageHandler and RosterManager are bigger tasks, but they still can be done independently
* …https://invent.kde.org/network/kaidan/-/issues/415Failed to connect when no_proxy has a dot-prefixed entry2022-09-28T10:19:52ZLuiz Angelo Daros de LucaFailed to connect when no_proxy has a dot-prefixed entryHello,
I have http(s)_proxy and no_proxy defined:
```
no_proxy="localhost, 127.0.0.1, mydomain.com, .mydomain.com"
http_proxy="http://proxy.mydomain.com:8080"
https_proxy="http://proxy.mydomain.com:8080"
```
With my xmpp server at jab...Hello,
I have http(s)_proxy and no_proxy defined:
```
no_proxy="localhost, 127.0.0.1, mydomain.com, .mydomain.com"
http_proxy="http://proxy.mydomain.com:8080"
https_proxy="http://proxy.mydomain.com:8080"
```
With my xmpp server at jabber.mydomain.com (with the correct SRV entries pointing '@mydomain.com' to jabber.mydomain.com)
In this situation, the kaidan 0.8.0 connection fails with:
[client] Disconnected: QXmppClient::SocketError
It only works if I remove the ".mydomain.com" entry.
It should, at least, not fail.
**Update**: changed mydomain,com to mydomain.com. It was a typo while writing this report.https://invent.kde.org/network/kaidan/-/issues/414Crash with new database2022-09-09T12:11:25ZJonah BrüchertCrash with new databaseWith a new database, kaidan crashes with a qFatal error message:
```
Failed to execute query: "INSERT OR REPLACE INTO omemo_devices (account, user_jid, id, label, key_id, session, unresponded_stanzas_sent, unresponded_stanzas_received, r...With a new database, kaidan crashes with a qFatal error message:
```
Failed to execute query: "INSERT OR REPLACE INTO omemo_devices (account, user_jid, id, label, key_id, session, unresponded_stanzas_sent, unresponded_stanzas_received, removal_timestamp) VALUES (:a, :bb, :bc, :bd, :be, :bf, :bg, :bh, :bi)"
QSqlError: NOT NULL constraint failed: omemo_devices.key_id Der Datensatz konnte nicht abgeholt werden
```Melvin Keskinmelvo@olomono.deMelvin Keskinmelvo@olomono.dehttps://invent.kde.org/network/kaidan/-/issues/412Please update the kaidan ubuntu touch application2022-06-05T07:25:38ZQuilty weavyPlease update the kaidan ubuntu touch applicationThe app has not been updated (or even touched) for four years from now in ubuntu touch OS. Please update it to the latest version, version 0.5. This is the link (hope you remember it) :- https://open-store.io/app/im.kaidan.kaidanThe app has not been updated (or even touched) for four years from now in ubuntu touch OS. Please update it to the latest version, version 0.5. This is the link (hope you remember it) :- https://open-store.io/app/im.kaidan.kaidanhttps://invent.kde.org/network/kaidan/-/issues/410Use Craft for binary factory Android build2022-06-04T20:13:04ZNicolas FellaUse Craft for binary factory Android buildThe Android build for Kaidan on binary-factory.kde.org is one of the few Android builds that don't use craft yet.
Please have a look at converting it to Craft. That would allow to eventually remove the current toolingThe Android build for Kaidan on binary-factory.kde.org is one of the few Android builds that don't use craft yet.
Please have a look at converting it to Craft. That would allow to eventually remove the current toolinghttps://invent.kde.org/network/kaidan/-/issues/409[Feature Request] Option to specify max age for history2022-10-03T13:00:22Zjake g[Feature Request] Option to specify max age for historyMany chat applications you can turn storing history on or off.
I would prefer to have the history, but anything older than 72 hours is deleted.
The reason for this is if my computer or phone is stolen.
I would prefer that there is not 2...Many chat applications you can turn storing history on or off.
I would prefer to have the history, but anything older than 72 hours is deleted.
The reason for this is if my computer or phone is stolen.
I would prefer that there is not 2 years of chat history just sitting there on the device.https://invent.kde.org/network/kaidan/-/issues/408[Feature Request] Data Saving option (on Android do not automatically downloa...2022-10-03T12:58:42Zjake g[Feature Request] Data Saving option (on Android do not automatically download images to chat when enabled.)Kaidan is going to be what I use for everything once omemo is in place.
I am wondering if it would be possible for the kaidan android app to detect if your on wifi or not.
The reason for this is when people send images, I would like to...Kaidan is going to be what I use for everything once omemo is in place.
I am wondering if it would be possible for the kaidan android app to detect if your on wifi or not.
The reason for this is when people send images, I would like to automatically receive them into the active chat when im on wifi, but if I am not on wifi then I would instead prefer to be sent a link to the image that I can click if I want kaidan to download and display the image into the chat.
Think of this as a data saving feature. This might be a tall order but I am absolutely positive a lot of people would find such a feature very useful.https://invent.kde.org/network/kaidan/-/issues/407[Feature Request] Display how long a contact has been Idle/online/offline for.2022-10-03T13:00:27Zjake g[Feature Request] Display how long a contact has been Idle/online/offline for.Display how long a contact has been Idle/online/offline
Many applications do this, some just display online/offline status, but show additional info on mouseover hover.
In pidgin if you mouse over a contact in your list you can see exa...Display how long a contact has been Idle/online/offline
Many applications do this, some just display online/offline status, but show additional info on mouseover hover.
In pidgin if you mouse over a contact in your list you can see exactly how long they have been away for.https://invent.kde.org/network/kaidan/-/issues/406MUC groups support2022-09-28T10:21:36ZJavier V.MUC groups supportDoes Kaidan has in plans to include MUC groups suspport? That's a must for interoperability and federation. BTW, the ability to create groups should be such that they are omemo encrypted by default (when omemo becomes available). Than...Does Kaidan has in plans to include MUC groups suspport? That's a must for interoperability and federation. BTW, the ability to create groups should be such that they are omemo encrypted by default (when omemo becomes available). Thanks !https://invent.kde.org/network/kaidan/-/issues/405Kaidan tray icon does not load when using kdocker on Ubuntu 21.04 + 21.102022-01-09T15:00:53Zjake gKaidan tray icon does not load when using kdocker on Ubuntu 21.04 + 21.10Kaidan tray icon does not load when using kdocker, instead it puts the missing icon window with a red question mark.
Additionally it would be nice if Kaidan provided a setting/option to treat the close button as a minimize button instea...Kaidan tray icon does not load when using kdocker, instead it puts the missing icon window with a red question mark.
Additionally it would be nice if Kaidan provided a setting/option to treat the close button as a minimize button instead, this would prevent me from accidentally exiting Kaidan and closing my chat.
kdocker can be used to restore/minimize Kaidan(or other applications) to the system tray.
I use kdocker to do the same thing to thunderbird and Dino:
![2021-11-12_13-23](/uploads/2bf802f82b3dd629af585f4a2de9b457/2021-11-12_13-23.png)https://invent.kde.org/network/kaidan/-/issues/404Kaidan Settings window Glitch on Ubuntu 21.04 and 21.102024-02-16T18:25:30Zjake gKaidan Settings window Glitch on Ubuntu 21.04 and 21.10system info: Ubuntu 21.04 + 21.10, KDE plasma 5.21.4 + 5.22.5, QT 5.15.2
When I open the settings window I get weird overlaying text:
![2021-11-12_13-16](/uploads/8c8e8f63afc83a76ec2d6af4e9a7e7c7/2021-11-12_13-16.png)system info: Ubuntu 21.04 + 21.10, KDE plasma 5.21.4 + 5.22.5, QT 5.15.2
When I open the settings window I get weird overlaying text:
![2021-11-12_13-16](/uploads/8c8e8f63afc83a76ec2d6af4e9a7e7c7/2021-11-12_13-16.png)https://invent.kde.org/network/kaidan/-/issues/403Build Instructions for Ubuntu 20.04, incomplete?2022-06-04T20:16:11Zjake gBuild Instructions for Ubuntu 20.04, incomplete?Kaiden requires QT 5.14+ unfortunately Neon and Ubuntu 20.04 LTS is still on 5.12
I was following this: https://invent.kde.org/network/kaidan/-/wikis/building/linux-debian-based
I was able to get all the requirements met and it appears...Kaiden requires QT 5.14+ unfortunately Neon and Ubuntu 20.04 LTS is still on 5.12
I was following this: https://invent.kde.org/network/kaidan/-/wikis/building/linux-debian-based
I was able to get all the requirements met and it appears to build successfully without error but when I try to launch it I get an error:
```
~/source/kaidan/build$ bin/kaidan
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:33:1: module "org.kde.kirigami" is not installed
```
Please help if you know how to resolve the above error.
here is my install routine:
```
sudo add-apt-repository ppa:beineri/opt-qt-5.14.2-focal
sudo apt-get update
sudo apt-get install qt514-meta-full
source /opt/qt514/bin/qt514-env.sh
sudo apt install git cmake extra-cmake-modules build-essential \
qtdeclarative5-dev qttools5-dev qtbase5-dev qtmultimedia5-dev qtpositioning5-dev \
qtlocation5-dev qtquickcontrols2-5-dev libqt5svg5-dev libqt5multimedia5-plugins \
qml-module-qtquick-layouts qml-module-qtquick-dialogs qml-module-qtmultimedia \
qml-module-qtpositioning qml-module-qtlocation \
kirigami2-dev libkf5notifications-dev gstreamer1.0-plugins-bad \
breeze-icon-theme fonts-noto-color-emoji libzxingcore-dev \
qml-module-org-kde-kirigami2 kirigami2-dev libkf5i18n-dev libkf5coreaddons-dev \
gettext libkf5qqc2desktopstyle-dev qml-module-org-kde-qqc2desktopstyle
wget http://archive.ubuntu.com/ubuntu/pool/universe/k/kirigami/qml-module-org-kde-kirigami_1.1.0-2_amd64.deb
sudo dpkg -i qml-module-org-kde-kirigami_1.1.0-2_amd64.deb
source /opt/qt514/bin/qt514-env.sh
echo "export QT_QUICK_CONTROLS_STYLE=org.kde.desktop" >> ~/.profile
source ~/.profile
cd ~/source
git clone https://github.com/qxmpp-project/qxmpp
mkdir qxmpp/build && cd qxmpp/build
cmake ..
make -j$(nproc)
sudo make install
cd ~/source
git clone https://invent.kde.org/network/kaidan.git
mkdir kaidan/build && cd kaidan/build
cmake .. -DI18N=1
make -j$(nproc)
bin/kaidan
sudo make install
```
# Error:
```
~/source/kaidan/build$ bin/kaidan
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:33:1: module "org.kde.kirigami" is not installed
```https://invent.kde.org/network/kaidan/-/issues/402Add DOAP file URL to xmpp.org's clients file2021-11-30T10:45:05ZMelvin Keskinmelvo@olomono.deAdd DOAP file URL to xmpp.org's clients fileCreate a pull request that sets `https://invent.kde.org/network/kaidan/-/raw/master/misc/kaidan.doap` as the value for `doap` within Kaidan's entry in https://github.com/xsf/xmpp.org/blob/master/data/clients.json.
This should be done as...Create a pull request that sets `https://invent.kde.org/network/kaidan/-/raw/master/misc/kaidan.doap` as the value for `doap` within Kaidan's entry in https://github.com/xsf/xmpp.org/blob/master/data/clients.json.
This should be done as soon as !759 is merged.Melvin Keskinmelvo@olomono.deMelvin Keskinmelvo@olomono.de