Post Event PendingEventItems #861
Conversation
|
| @@ -850,7 +850,7 @@ public Q_SLOTS: | |||
| /// The event is about to be appended to the list of pending events | |||
| void pendingEventAboutToAdd(Quotient::RoomEvent* event); | |||
| /// An event has been appended to the list of pending events | |||
| void pendingEventAdded(const Quotient::RoomEvent* event); | |||
| void pendingEventAdded(const PendingEventItem& pendingItem); | |||
There was a problem hiding this comment.
I'm not sure it's a good idea; for one, you cannot use a queued connection with this signal because a reference cannot be copied; and besides, this reference is at risk of dangling if any slot connected to pendingEventAdded causes adding another pending event to the same room (I stumbled over it when writing Quotest, some time ago). At the very least, these caveats should be in the signal documentation.
| //! | ||
| //! The future will get finished just before this pending item is merged into its remote | ||
| //! counterpart that comes with /sync. The pending item will always be in ReachedServer state. | ||
| //! The future result has type implicitly convertible to std::pair with a `const RoomEvent&` and an `int`. | ||
| about_to_merge_future_type whenAboutToMerged() const { return _aboutToMergePromise.future(); } |
There was a problem hiding this comment.
Do you have code that would use it? Or at least can you give an idea of code that would use it? Futures are generally heavier than signal-slot connections.
Always return pending event items when posting events rather than transaction IDs
Also add a future for about to merge as it's useful when rearranging a timeline model (we need to know where the pending event was in the timeline to make sure it can be moved to the right place and this isn't available after merge)