| 21 Jul 2024 |
 nvrwhere | kitsune I created a shim in NeoChat to solve the RoomMember in QML issue, would be interested in your thoughts on the draft https://invent.kde.org/network/neochat/-/merge_requests/1816 | 15:44:25 |
| nvrwhere | I'd look to upstream later | 15:46:29 |
| 22 Jul 2024 |
 GitHub | ✳ KitsuneRal merged PR quotient-im/libQuotient#778: "Bug/regression fixes and some cleanup" | 08:28:24 |
 kitsune | @nvrwhere:kde.org that looks an awful lot like reverting to what User used to be, except now it’s created per-room and I have no idea where that dynamically created object is deleted, if at all. Why not a Q_GADGET with a change signal provided by the room?
| 15:10:44 |
| nvrwhere | In reply to @kitsune:matrix.org
@nvrwhere:kde.org that looks an awful lot like reverting to what User used to be, except now it’s created per-room and I have no idea where that dynamically created object is deleted, if at all. Why not a Q_GADGET with a change signal provided by the room?
It's intentionally designed to be held by QML anything that is done in cpp can still use RoomMember safely. The idea is to create something that can be handed over and then managed by QML. It should be deleted by the qml engine once the model is reset for a new room | 15:40:00 |
| kitsune | I’m not quite sure QML would take ownership of things returned by model roles. | 15:45:30 |
| kitsune | The docs say the ownership remains on the C++ side unless an object is obtained by a direct call to C++ | 15:46:07 |
| nvrwhere | Yeah may need to work on that. There is also a slight weakness that an object is created per event rather than user | 15:46:52 |
| kitsune | Yep | 15:47:02 |
| kitsune | Yeah, not per-room even. Woah… | 15:47:25 |
| kitsune | Definitely would go with a gadget in such case :) | 15:47:55 |
| kitsune | A room member list model would be the right answer | 15:48:26 |
| kitsune | But then again, that thing wouldn’t be managed by QML | 15:48:42 |
| nvrwhere | Still that's a Neochat issue to solve. The main intent of the object stands and it generally seemed worth it to have it self update. I could improve the management and change to update on a per user basis | 15:49:03 |
| kitsune | That part is certainly worth it yes | 15:50:16 |
| nvrwhere | * Still that's a Neochat issue to solve. The main intent of the object stands and it generally seemed worth it to have it self update. I could improve the management and change to create only on a per user basis | 15:50:16 |
| kitsune | I would certainly look at keeping all members of one room as QObjects.
| 15:51:47 |
| kitsune | Or alternatively just leave it to the client to create as many member objects as needed at a given point, like, depending on the displayed timeline/member list etc. | 15:53:03 |
| nvrwhere | I'll have a think and try some stuff | 15:53:40 |
| kitsune | ‘Cause again, you only need to pass a member ID to QML, and it can create that kind of a member object for its own then ;) | 17:13:08 |
| nvrwhere | In reply to @kitsune:matrix.org
‘Cause again, you only need to pass a member ID to QML, and it can create that kind of a member object for its own then ;) Well this is just a nice abstraction to do just that | 17:36:07 |
| 24 Jul 2024 |
|  Redstone changed their display name from redstone-menace to Redstone. | 10:15:09 |
| 25 Jul 2024 |
|  maemotest joined the room. | 16:23:23 |
| maemotest | I'm working on a chat client that uses libquotient 0.8.2, figuring out how to auto-join private 1:1 chats. I create a 1:1 chat in a web-interface (Element) that sends this to the Matrix server:
{"preset":"trusted_private_chat","visibility":"private","invite":["@some_user:utwente.io"],"is_direct":true,"initial_state":[{"type":"m.room.guest_access","state_key":"","content":{"guest_access":"can_join"}},{"type":"m.room.encryption","state_key":"","content":{"algorithm":"m.megolm.v1.aes-sha2"}}]}
Then on the libquotient side, I need to accept this invite somehow (I think?) - any tips what code in Quotient/connection.cpp handles this? I do notice that Connection::provideRoom() is being called. But it's not joining the "room".
| 16:27:52 |
| maemotest | * I'm working on a chat client that uses libquotient 0.8.2, figuring out how to auto-join private 1:1 chats. I create a 1:1 chat in a web-interface (Element) that sends this to the Matrix server:
{"preset":"trusted_private_chat","visibility":"private","invite":["@some_user:utwente.io"],"is_direct":true,"initial_state":[{"type":"m.room.guest_access","state_key":"","content":{"guest_access":"can_join"}},{"type":"m.room.encryption","state_key":"","content":{"algorithm":"m.megolm.v1.aes-sha2"}}]}
Then on the libquotient side, I need to accept this invite somehow (I think?) - any tips what code in Quotient/connection.cpp handles this? I do notice that Connection::provideRoom() is being called. But it's not joining the "room".
| 16:28:03 |
| kitsune | I wouldn’t really advise auto-joining 1:1 invitations, as it’s a common avenue for abuse. That being said, if you need to join a room you have to, obviously, do Connection::joinRoom()
| 16:31:41 |
| kitsune | And, thanks for using the library for your project! | 16:32:04 |
| maemotest | ah yes, I forgot about joinRoom 🤔 😅 | 16:33:39 |
| 26 Jul 2024 |
|  tom joined the room. | 10:23:09 |
| tom | Hello everyone. Please tell me if it is possible to make quaternion a little prettier?))
And I also wanted to clarify how to copy the entire text and not one or two lines? | 10:24:58 |
