KMail: Menu options to toggle "Show Message Structure" #19

Closed
luke-jr wants to merge 3 commits from luke-jr/tdepim:kmail_msg_structure_checkbox into master
Collaborator

Been using this occasionally for about a year now.

Been using this occasionally for about a year now.
Owner

Hi Luke,

welcome to the TDE development team!! Your email address looks promising, so looking forward to see more from you 😄

Two small things.

  1. in order to merge your commits into the main repository, could you sign-off your commits with the "-s" flag? See the TGW guide section for further information if required.

  2. although it is ok to have personal repositories, here on TGW we prefer to work with the branch model rather than the fork model for TDE repositories. The reason is quite simple: disk space 😄 Not an issue for the moment, since there are few users, but if possible we would appreciate if you could also switch to such model (again, more info available on the TGW guide link above)

Good to see more people contributing to TDE, keep it up 👍

Hi Luke,<br> welcome to the TDE development team!! Your email address looks promising, so looking forward to see more from you :smile: Two small things. 1. in order to merge your commits into the main repository, could you sign-off your commits with the "-s" flag? See the [TGW guide](https://wiki.trinitydesktop.org/TDE_Gitea_Workspace#To_contribute_code_changes) section for further information if required. 2. although it is ok to have personal repositories, here on TGW we prefer to work with the branch model rather than the fork model for TDE repositories. The reason is quite simple: disk space :smile: Not an issue for the moment, since there are few users, but if possible we would appreciate if you could also switch to such model (again, more info available on the TGW guide link above) Good to see more people contributing to TDE, keep it up :+1:
Poster
Collaborator

Done

Done
Owner

Thanks Luke.

I have taken a look at the PR. The code looks very good and the new menu entry works as described by you.

I think there is a point that needs some improvement though. As you said, the menu always toggles between show and don't show. This introduces an inconsistent behavior in case the user has chosen to show the panel only for non-plain messages, since once the panel is triggered once (either on or off) for all subsequent messages the same behavior is used.

I see two possible ways forward:

  1. keep the current on/off behavior, but limit that for the current message being shown. E.g. once another message is displayed, start again from the general user settings.

  2. modify the code to have three options (like in the settings panel). When the user changes the selection, the new selection should apply to all messages and update the settings accordingly.

IMO, option 1 is easier and also make more sense, since the new menu entry is something that would be very useful to temporarily override the user settings on a specific message. Option 2 is already achieved from the settings page and I see no point in reinventing the wheel once again.

What are your thought?

Thanks Luke.<br> I have taken a look at the PR. The code looks very good and the new menu entry works as described by you. I think there is a point that needs some improvement though. As you said, the menu always toggles between show and don't show. This introduces an inconsistent behavior in case the user has chosen to show the panel only for non-plain messages, since once the panel is triggered once (either on or off) for all subsequent messages the same behavior is used.<br> I see two possible ways forward: 1. keep the current on/off behavior, but limit that for the current message being shown. E.g. once another message is displayed, start again from the general user settings. 2. modify the code to have three options (like in the settings panel). When the user changes the selection, the new selection should apply to all messages and update the settings accordingly. IMO, option 1 is easier and also make more sense, since the new menu entry is something that would be very useful to temporarily override the user settings on a specific message. Option 2 is already achieved from the settings page and I see no point in reinventing the wheel once again. What are your thought?
Poster
Collaborator

I agree option 1 makes sense, pushed a commit to reset to settings when displaying another message.

I agree option 1 makes sense, pushed a commit to reset to settings when displaying another message.
Owner

It seems you forgot to use Sign-off-by for the last commit 😸

It seems you forgot to use Sign-off-by for the last commit :smile_cat:
Poster
Collaborator

Oops

Oops
Owner

Hi Luke, thanks for the additional commit. It actually caused a FTBFS because the declaration of KMReaderWin::readConfigMimeTreeMode in the .h file was not included in the commit, but it was a small oversight.

I have prepared PR #25. This is based on your work, includes your second commit and make some improvements but keeps the same funcionality.

I have tested on my system and it seems to work ok. Could you please test on yours before I merge to master, to make sure I did not introduce any unwanted mistake/behavior?

Hi Luke, thanks for the additional commit. It actually caused a FTBFS because the declaration of KMReaderWin::readConfigMimeTreeMode in the .h file was not included in the commit, but it was a small oversight. I have prepared PR #25. This is based on your work, includes your second commit and make some improvements but keeps the same funcionality. I have tested on my system and it seems to work ok. Could you please test on yours before I merge to master, to make sure I did not introduce any unwanted mistake/behavior?
Owner

Hi Luke, kind reminder to test or comment on #25: same functionality but with some improvements. Slavek has already tested, so waiting for you to either test or give the go ahead for merging 😄

Hi Luke, kind reminder to test or comment on #25: same functionality but with some improvements. Slavek has already tested, so waiting for you to either test or give the go ahead for merging :smile:
Owner

This has been replaced by #25, which now has been merged.

Luke, thanks for your initial work, a good part of it has been included into #25.

This has been replaced by #25, which now has been merged. Luke, thanks for your initial work, a good part of it has been included into #25.
MicheleC closed this pull request 5 years ago
Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/tdepim#19
Loading…
There is no content yet.