| Summary: | [4.81 beta1] akregator in kontact: read messages are removed from unread filter immediately | ||
|---|---|---|---|
| Product: | [Applications] akregator | Reporter: | qqqqqqqqq9 |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alvarenga, cfeck, christopherheiny, cornelis, darwin_te, d_corkrey, e8hffff, erik, francescvc666, gabrimonfa, Harald.Demian.Brunner, j.pigeot, jaak, javier.ramoshidalgo, jjm, jsamyth, j_kolberg11, j__n, kde, kde, kde, kde, kde, koalinux, lordheavym, luigi.toscano, manz, maql.nju, markus.zimmermann, martin.tlustos, mieszcz, moltonel, naughtypine, niflheimr, olaf.the.lost.viking, paul.noel1, porrascristian, rewarp, rynolangner, shai, smc+kdebugs, steve, sven, tahall256, thoppels, tom-kde.bugs, tonymt00, yyc1992 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=259813 | ||
| Latest Commit: | https://commits.kde.org/akregator/c2d31a56f0d45858706e9a0af9227a24f8e55483 | Version Fixed In: | |
| Attachments: | Patch to intercept and selectively ignore the 'Article Read' event | ||
|
Description
qqqqqqqqq9
2015-07-29 07:01:53 UTC
CONFIRMED As soon as you click an unread item all unread items are instantly marked as read. I've tried putting key shortcuts to default in case there was some strange mouse assignment to mark-all-feeds-as-read. CONFIRMED as well Also confirmed... This seems to specifically be a problem with the behavior around the "mark selected article read after..." advanced setting. I think this defaults to 0 seconds (i.e. immediately) which is what I used to have it set to. Previously, this just meant the article was marked "read" as soon as it was clicked, and if you had the unread filter set, it would then disappear from the list AFTER you clicked away from it to another article. Now the article is immediately removed from the list, causing the selection to automagically drop to the next, mark *it* unread, remove it, etc. You can watch it happen more slowly if you go to settings -> configure akregator -> advanced and set it to mark as read after, say, 5 seconds. Perhaps this bug should just read "Read articles should not be removed by the unread filter while the article is selected"? Also happens if the status filter is set to 'New', presumably because articles aren't new once they've been read. "Read articles should not be removed by the unread filter while the article is selected" sounds like a good solution. Confirmed here with akregator 5.0.2 and Kubuntu 15.10 (In reply to Martin Tlustos from comment #6) > Confirmed here with akregator 5.0.2 and Kubuntu 15.10 Same here. Data loss! I mean how is one later supposed to figure out which messages one missed to read after this happens?! ARGHH!! ;-[ (Voting for this one) (In reply to S Clark from comment #4) > Perhaps this bug should just read "Read articles should not be removed by > the unread filter while the article is selected"? That's a compromise, not an ideal solution. The ideal solution is akregator 4.x behavior -- the "unread" filter is not applied continuously, but only upon selection of a folder (or, of course, changing of filter). This means if you enter a feed and have 3 unread items, once you've read them all, you see 3 read items. *** This bug has been confirmed by popular vote. *** *** Bug 354531 has been marked as a duplicate of this bug. *** *** Bug 354721 has been marked as a duplicate of this bug. *** Still valid for Akregator included in 15.08.3 *** Bug 356978 has been marked as a duplicate of this bug. *** *** Bug 353958 has been marked as a duplicate of this bug. *** *** Bug 354746 has been marked as a duplicate of this bug. *** Same problem with Kubuntu 15.04 and Akregator 5.0.2 Still appearing in Akregator Version 5.1.1 KDE Frameworks 5.18.0 Manjaro/Arch repositories Running embedded within Kontact. Since this happens every single time, it pretty much makes it impossible to read feeds showing only unread posts, as they all disappear from view. Certainly, even volunteer developers can track this down in 6 months. (In reply to John Andersen from comment #17) > Still appearing in > Akregator Version 5.1.1 > KDE Frameworks 5.18.0 > Manjaro/Arch repositories > Running embedded within Kontact. > > Since this happens every single time, it pretty much makes it impossible to > read feeds showing only unread posts, as they all disappear from view. > Certainly, even volunteer developers can track this down in 6 months. You can go to Settings > Advanced and disable the automatic marking as read, then use Ctrl+E to do it manually. *** Bug 359543 has been marked as a duplicate of this bug. *** Still valid for Akregator from Applications 16.04. Same in gentoo until 16.04.2 (In reply to Mirek Mieszczak from comment #21) > Same in gentoo until 16.04.2 Is it fixed in 16.04.2 or you just haven't tested that version yet? (In reply to Jaak Ristioja from comment #22) > (In reply to Mirek Mieszczak from comment #21) > > Same in gentoo until 16.04.2 > > Is it fixed in 16.04.2 or you just haven't tested that version yet? It is not fixed yet. Yesterday I just compiled version 16.04.2 and tested. Of course without success. Just upgraded Fedora to FC24, the new akregator is on Version 5.2.2. After spending a long time trying to find where you newly hid the Unread/Important filter dropdown, the whole of all unread items quickly decreases to 0 when an unread new item headline is clicked for reading. *** Bug 365329 has been marked as a duplicate of this bug. *** Confirmed in akregator 5.2.3 on an archlinux system. :-( *** Bug 368324 has been marked as a duplicate of this bug. *** I can also confirm this bug using openSUSE Tumbleweed snapshot 20161003 akregator5-16.08.1-1.2.x86_64 Confirmed in 5.3.0 on Fedora 24, latest update. This pretty much renders akregator useless. Any chance to bump this 14 month old bug up in priority and get a fix? Still present in openSUSE Tumbleweed Snapshot 20161018 akregator5-16.08.2-1.1.x86_64 *** Bug 373018 has been marked as a duplicate of this bug. *** *** Bug 373229 has been marked as a duplicate of this bug. *** Is this fixed already? I am using kde neon 5.8.4. (Based on Ubuntu 16.04) Is this fixed already? I am using kde neon 5.8.4. (Based on Ubuntu 16.04) Is this fixed already? I am using kde neon 5.8.4. (Based on Ubuntu 16.04) Hitting this too after upgrading from 4.14 to 5.4.0 (package version 16.12.0). In 4.14 this only appened when when the interval fetching kicked in, which was not a show-stoper but was still annoying. Bug 114263 is related to this, although approaching it from the other side. IMHO articles should only be removed from the list after some human interaction, like clicking on a different feed or changing the search bar. Adding articles to the list should still happen ASAP. For what it's worth, disabling 'mark selected article read after X seconds' in the settings and using 'Crtl-E' to mark them read manually (instead of relying on auto 'mark as read') makes akregator usable again. Not sure how useful this is, but I've been testing - quite successfully - with below patch for the last few weeks. Although the patch itself is rather ugly (it basically intercepts the processing of the 'Read' event, bringing back 4.x comparable behaviour), I haven't seen any side effects of it yet. YMMV. I don't expect this to be applied to official sources, but might be useful for people building their own binaries. Created attachment 102908 [details]
Patch to intercept and selectively ignore the 'Article Read' event
Is this fixed already? I am using kde neon 5.8.5. (Based on Ubuntu 16.04) (In reply to darwin te from comment #40) > Is this fixed already? I am using kde neon 5.8.5. (Based on Ubuntu 16.04) No, Akregator 5.3.3 in FC25 still clears all items Uncheck "Mark selected article read after" under settings/advanced and use Ctrl+E to manually mark as read as you go through the feeds *** Bug 376649 has been marked as a duplicate of this bug. *** *** Bug 376807 has been marked as a duplicate of this bug. *** *** Bug 380218 has been marked as a duplicate of this bug. *** This is not fixed yet. Any solution or estimate? *** Bug 381425 has been marked as a duplicate of this bug. *** *** Bug 384256 has been marked as a duplicate of this bug. *** This is not fixed yet. Any solution or estimate? Patch submitted at https://phabricator.kde.org/D7928 Git commit 08fe30f0973b69101fdedce1a167f74792eb4c5f by Jonathan Marten. Committed on 29/09/2017 at 15:57. Pushed by marten into branch 'master'. Do not remove read messages from the unread filter immediately Otherwise, when using the filter, the next message will also be selected and immediately marked as read, until the feed is empty. Differential Revision: https://phabricator.kde.org/D7928 M +1 -1 src/article.cpp M +5 -3 src/feed/feed.cpp M +6 -3 src/feed/feed.h https://commits.kde.org/akregator/08fe30f0973b69101fdedce1a167f74792eb4c5f Git commit bb7f35c7938e8e18ac83dcc98b43b69ac2772f6c by Jonathan Marten, on behalf of Erik van 't Wout. Committed on 29/09/2017 at 16:30. Pushed by marten into branch 'master'. Do not remove read messages from the unread filter immediately Otherwise, when using the filter, the next message will also be selected and immediately marked as read, until the feed is empty. Differential Revision: https://phabricator.kde.org/D7928 M +1 -1 src/article.cpp M +5 -3 src/feed/feed.cpp M +6 -3 src/feed/feed.h https://commits.kde.org/akregator/bb7f35c7938e8e18ac83dcc98b43b69ac2772f6c Git commit c2d31a56f0d45858706e9a0af9227a24f8e55483 by Jonathan Marten, on behalf of Erik van 't Wout. Committed on 29/09/2017 at 16:39. Pushed by marten into branch 'Applications/17.08'. Do not remove read messages from the unread filter immediately Otherwise, when using the filter, the next message will also be selected and immediately marked as read, until the feed is empty. Differential Revision: https://phabricator.kde.org/D7928 M +1 -1 src/article.cpp M +5 -3 src/feed/feed.cpp M +6 -3 src/feed/feed.h https://commits.kde.org/akregator/c2d31a56f0d45858706e9a0af9227a24f8e55483 *** Bug 387883 has been marked as a duplicate of this bug. *** |