Created attachment 1930 [details] v4 Certain workflows require not to automatically mark mails as read; Not when viewing and also not when replying. This patch adds an option to turn off all such automatically marking as read. Also, in the preferences, change the hbox title from "Mark message as read" to "Automatically mark message as read" as suggested by Ticho.
Created attachment 1944 [details] v5, rebase after recent re-arrangements in summaries rebase after recent Display/Summaries/Message List changes in 411656df3122636a5ba0abc3952d678ace69de5a 7e1fec1467f2414c01d5cdac05e5cd2a25b16067 faee87fc98fdf322a3f493ecf8be26c9cf287581 No other changes wrt v4.
The v5 patch breaks the other options in the radio group (sensitivity of the spin widget as well as the impossibility to select the 2nd option). BTW, the patch applies fine against both GTK2 and GTK3.
Created attachment 2304 [details] v6: fix other options in the radio group (worth for gtk2/gtk3)
(In reply to wwp from comment #3) Are you sure? I just re-teste the other variants, i.e. "mark read after N seconds" and "mark read after reply in new window or..." and they all work just fine? For reference I'm attaching what i'm using ever since then, which does not necessitate all those the non-obvious changes in your v6 ?
Created attachment 2305 [details] Working version of the initial patch a.k.a v5 as tested and use ever since in my tree This patch adds an option to never automatically mark a mail as read. It retains the previous functionality of the other options to automatically mark a mail as read if it was either opened/viewed or replied-to/in a new window/...
Well, strange. I'll try your patch and dig around my changes again. Will get back to you later!
Please do. Don't get me wrong, if your version works in some way superiour and lets me upstream the thing for everybody, then i'm all for it! It's just that i don't see why you'd have to do all those changes that are in your patch that i definitely do not have to do to make it work properly (for me on gtk3 and gtk2..). I'm pretty confident that the v5 proposal, resp https://www.thewildbeast.co.uk/claws-mail/bugzilla/attachment.cgi?id=2305 works fine since i use all 3 modes in different use-cases, each as advertised, all based off that very same patch :) I'd be grateful if we could apply said functionality at last! cheers,
hmz, wait Is there a mismatch, i.e. copy'n paste? I.e. on top of the https://www.thewildbeast.co.uk/claws-mail/bugzilla/attachment.cgi?id=2305 diff --git a/src/prefs_summaries.c b/src/prefs_summaries.c index 9e1b0d380..d26c50c29 100644 --- a/src/prefs_summaries.c +++ b/src/prefs_summaries.c @@ -547,7 +547,7 @@ static void prefs_summaries_create_widget(PrefsPage *_page, GtkWindow *window, FALSE, FALSE, 0); radio_mark_as_read_on_select = gtk_radio_button_new_with_label_from_widget( - GTK_RADIO_BUTTON(radio_mark_as_read_on_never), + GTK_RADIO_BUTTON(radio_mark_as_read_on_select), _("when selected, after")); hbox1 = gtk_box_new(GTK_ORIENTATION_HORIZONTAL, 8); I.e. the read_on_select of couse should use the state of the on_select radio button, not the on_never radio button? WDYT? Odd that it still works fine for me though..
my keyboard sucks s/couse/course/g
About comment #8, it probably works for you because adding a radio widget to any element of a radio group works. It's more orthodox to add all items to the former elements. I'll need a bit more spare time to build 2 CM's w/ both patches and compare, make scenarii that show the (alleged) issues in the former one and make a detailed report to you :-) (or change my patch).
the former elements => the initial element
(In reply to Bernhard from comment #8) That comment #8 is of course very much wrong. In GTK, one usually chains the elements and that's what the patch in the attachment 2305 [details] in but 4113 does as well. https://docs.gtk.org/gtk3/class.RadioButton.html Either way, i don't really care _how_ the buttons are added. I just followed the pre-existing style, i think.