After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 649597 - Option 'Mark messages as read after' gone in Evolution 3.0
Option 'Mark messages as read after' gone in Evolution 3.0
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.0.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 671522 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-06 19:41 UTC by Dmytro Taranovsky
Modified: 2013-03-01 00:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dmytro Taranovsky 2011-05-06 19:41:13 UTC
Evolution 2.32 (and previous versions), has 'Mark messages as read after' option in Preferences -> Mail Preferences -> General (-> Message Display),
but Evolution 3.0 (tested on Fedora 15 prerelease) does not.
Comment 1 Matthew Barnes 2011-05-06 22:45:41 UTC
Silly option.  It got the axe.  But there's still a GConf key for it:

    /apps/evolution/mail/display/mark_seen_timeout  (in milliseconds)
Comment 2 Dmytro Taranovsky 2011-05-07 01:18:19 UTC
(In reply to comment #1)
It is useful to set the mark_seen_timeout to 0 when one receives a substantial volume of email, only some of which has to be read.  There is also some value in the computer responding immediately to the user.
For comparison, Thunderbird defaults to marking messages as read immediately after opening, and with an option to set the timeout.
Comment 3 Oded Arbel 2011-09-23 13:05:21 UTC
(In reply to comment #1)
> Silly option.  It got the axe.

Can you please explain - what GNOME developers think the use case for users reading email and wanting to not get confused between new email and old email? Currently one has to manually mark each email as read, otherwise it is still considered "new".

I'm not saying this change doesn't make sense - I'm only saying that I don't understand the sense of it and would like to have it explained to me so that if there's a better user behavior for reading email, I can switch to it.
Comment 4 Oded Arbel 2011-09-29 19:52:53 UTC
Ok, I think I understand the issue here: if you don't use the message preview feature, then you will need to open the message to read it - and when you do so Evolution will automatically mark that you've read the message (this is regardless  of the setting of mark_seen in gconf, bug #651761).

The problem starts when you don't need to open messages to read them because you read them in the message preview. I think this is how most people are using Evolution, mostly as this is the default configuration of Evolution. In that mode, a timed mark_seen is the only way for users to manage email. 

Please return this option to the setup dialog: its not a power user option as its the only way to get automatic and intuitive "mark as read" in the default Evolution configuration. Also - every other email client does it this way and by not doing the same, Evolution can only alienate new users and cause them to choose other clients.
Comment 5 Matthew Barnes 2011-09-29 20:51:36 UTC
Automatic "mark as read" is already the default.
Comment 6 Oded Arbel 2011-10-01 22:45:22 UTC
Ah. I was under the impression that the feature itself was disabled by default. I've just tested it an indeed by default, "mark as read" is set at 1500 ms. 

Personally I'm thinking that removing this configuration is over simplification of the configuration interface and I can see people that would like to have this at a longer timeout, but its indeed not that important - its not like you're asking people to use the Windows registry editor - gconf is tons more usable and friendly.
Comment 7 Josh Triplett 2012-02-13 15:43:39 UTC
(In reply to comment #6)
> Ah. I was under the impression that the feature itself was disabled by default.
> I've just tested it an indeed by default, "mark as read" is set at 1500 ms. 
> 
> Personally I'm thinking that removing this configuration is over simplification
> of the configuration interface and I can see people that would like to have
> this at a longer timeout

I don't know about "longer"; the most common use case seems like "shorter".  When processing an inbox with 100, 1000, or more mails in it, 1500ms represents an eternity.  I've never seen another email client which imposes a delay like this, and as far as I can tell *anyone* dealing with a significant volume of email will need to change this setting to 0 so that they can process email quickly.  Furthermore, the ability to easily "mark as unread" seems like it solves the most common problem that would motivate this delay.

Based on the above, I'd personally argue for making 0ms the default.  I also think that default would make evolution feel significantly more responsive.  

However, in lieu of that, I have a suggestion for simplifying the option to avoid user confusion while not removing it entirely.  I do agree that making the timeout itself configurable seems unnecessarily complex.  What about a simple checkbox which just toggles the delay on/off, with the actual delay hidden under gconf/dconf?  Switching between a short delay and no delay seems sufficient to avoid forcing everyone handling a ton of email to go use gconf/dconf.
Comment 8 Oded Arbel 2012-02-13 19:19:03 UTC
Sounds reasonable.
Comment 9 Matthew Barnes 2012-03-07 03:25:39 UTC
*** Bug 671522 has been marked as a duplicate of this bug. ***
Comment 10 gnomebz 2013-02-28 20:58:55 UTC
1500 ms is very long when reading 100+ e-mails. I find it really confusing that this option was removed from the preferences. If the default were "immediately mark as read" or something close to 500ms it might have been more bearable.
Comment 11 Matthew Barnes 2013-02-28 21:51:41 UTC
"Mark messages as read" option returned in 3.6
https://mail.gnome.org/archives/evolution-list/2012-August/msg00047.html
Comment 12 Dmytro Taranovsky 2013-03-01 00:48:40 UTC
Changing resolution to FIXED since the bug is fixed in 3.6.