Bug 340698 - Composer: Inconsistent UI indication when setting a reply mode when the original message disappeared
Summary: Composer: Inconsistent UI indication when setting a reply mode when the origi...
Status: RESOLVED FIXED
Alias: None
Product: trojita
Classification: Unmaintained
Component: Desktop GUI (show other bugs)
Version: git
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Trojita default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-06 23:02 UTC by Jan Kundrát
Modified: 2014-12-19 21:14 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kundrát 2014-11-06 23:02:52 UTC
- start replying to a message,
- change the replying mode to "hand-picked recipients"
- go offline
- go back online (this invalidates the QPersistentMessageIndex)
- change the replying mode to something else
- note that the combobox still shows "hand-picked recipients" (which is correct as the index is no longer valid), but upon expanding the menu, the entry which you selected is shown as checked
Comment 1 Thomas Lübking 2014-12-14 11:44:15 UTC
Is there intent to ever support reply modes across offline sessions?

Otherwise imo the proper fix was to catch the connection loss (or general invalidation of m_replyingToMessage) and switch to handpicked + disabling the button.
Comment 2 Jan Kundrát 2014-12-14 11:54:33 UTC
I think it "would be great", but there's a substantial amount of code which needs deep changes to make it happen.

As you said on Gerrit -- intercepting a failure of the setReplyMode followed by a check for index validity and if it's gone, switching unconditionally to the handpicked mode and disabling others should do the trick.
Comment 3 Thomas Lübking 2014-12-14 14:46:00 UTC
handling the item is trivial - i link to the models dataChanged signal and when the index is invalid afterwards, fix the GUI.

About preserving the message:
is it too naive to simply store model, mailbox name and UID and when the model changes (for the better ;-) try to lookup the index as ImapMessageAttachmentItem does?
Comment 4 Jan Kundrát 2014-12-14 14:53:04 UTC
(In reply to Thomas Lübking from comment #3)
> is it too naive to simply store model, mailbox name and UID and when the
> model changes (for the better ;-) try to lookup the index as
> ImapMessageAttachmentItem does?

Right now, the whole tree gets invalidated during reconnect, and this is needed due to the way we handle TreeItem::UNAVAILABLE, LOADING and any other errors. Mailbox discovery happens asynchronously, and each level of mailbox nesting gets discovered on demand.

I'm not saying this isn't doable, but I do say that it's hard.
Comment 5 Jan Kundrát 2014-12-19 21:14:17 UTC
Git commit 46f79b80fbe1aae3f1d3f45851644bc07630dbf2 by Jan Kundrát, on behalf of Thor Nuno Helge Gomes Hultberg.
Committed on 16/12/2014 at 21:30.
Pushed by gerrit into branch 'master'.

Fix inconsistent checkbox state

Solves contradiction regarding information about replying mode when the
message that is being replied to disappears.

Change-Id: I66b265d33711107fd16cfd13192f848228f6adcb

M  +19   -9    src/Gui/ComposeWidget.cpp

http://commits.kde.org/trojita/46f79b80fbe1aae3f1d3f45851644bc07630dbf2