[Feature Request] Alert between unread/read article

[bilekt3]

When I use detail of feed there is no indication that I am reading already read article. It might be good to somehow indicate this for example:

• Alert that I am going from read to unread
• Other label than next (i.e. next (already read)) etc.

[fguillot]

The latest stable version shows a little notification when you mark an entry as read/unread/favorite.

[bilekt3]

@fguillot Sorry, I haven't express myself so clearly.

I'm talking about situation when you see detail of article and it is your last unread article, there is no way (as far as I know) how to know that you going to article that you have already read by pressing next button. Only way is to look on the top of page and see if unread counter is decrementing or not. Which I see inconvenient.

[juanbretti]

Any trick I am missing to know if the next entry was previously read? Or maybe when the entry is open, to know if was previously read?

Thanks!

[juanbretti]

I understand this requires a change at https://github.com/miniflux/v2/blob/main/storage/entry_pagination_builder.go And make the query to pull [entries].[status] (as I can read at https://github.com/miniflux/v2/blob/main/storage/entry_query_builder.go).

To be 100% honest, this feature is the one that is stopping me from switching tt-rrs to miniflux.

Thank you for considering this feature request.

[juanbretti]

Any chance this FR goes to consideration by the developers?

[juanbretti]

Any considerations for this feature request?

[shizunge]

I have a difficulty to understand the question. But I may get it, the problem seems about entries opened from a "feed" page or a "category" page.

I usually open entries from the "unread" page or "history" page. For article in the "unread" page, "next" and "previous" always lead you to a new article. For article opened from the "history" page, it is always an old article.

[juanbretti]

@shizunge , thank you for your comment.

Sadly, my process of reading starts from the "category" or an individual "feed". So, for example, when I click on a particular "feed":

• I see unread entries.
• I start scrolling along the unread entries.
• But when the unread finishes, the application keeps displaying the already-read entries.
• Sadly, I don't have a way to know the item was previously-read, or better I don't have a way to filter the previously-read items.

Or am I missing something?

Some solutions, could be:

• As mentioned on the original post of this FR, a part-solution could be to replace the "Next »" with something like "Next read »".
• Or an option to skip to the next unread item. Something like: "Next unread » Next read »".
• Or to have a filter to not show the previously-read.
• Or a label at the item header saying that the item was read before.

Thank you for your feedback.

[shizunge]

Or sort the unread page by category and feed first?

[juanbretti]

I was thinking a good solution could be a filter. Like what's available here: https://apps.apple.com/us/app/tiny-reader-rss/id689519762

Or here: https://apps.apple.com/us/app/inoreader-news-rss-reader/id892355414

Or here: https://apps.apple.com/us/app/reeder-5/id1529445840

Or here: https://voidstern.net/fiery-feeds-user-guide https://apps.apple.com/us/app/fiery-feeds-rss-reader/id1158763303

Sadly, I don't know Go nor the codebase from MiniFlux to propose this PR.

[shizunge]

Is this related to https://github.com/miniflux/v2/issues/1212?

[juanbretti]

Is this related to #1212?

Not exactly, this FR is to have a global filter for the READ/UNREAD, so all the other features like Starred, Feeds and Categories are also limited to show READ or UNREAD items.

So, for example, when I open a particular Feed, I only scroll through unread items.

[shizunge]

Are https://github.com/miniflux/v2/issues/533#issue-540963721 and https://github.com/miniflux/v2/issues/533#issuecomment-1837444931 requesting different things?

#1212 is about building an API /category/<category_id>/unread/entry/<entry_id> to show only unread items of a category or feed. https://github.com/miniflux/v2/issues/1212#issuecomment-903213487

Is that not what you want?

[juanbretti]

@shizunge , comment https://github.com/miniflux/v2/issues/533#issue-540963721 and comment https://github.com/miniflux/v2/issues/533#issuecomment-1837444931, I think are requesting the same thing. What both comments are requesting is a way to filter/hide/know if an entry was already read. I don't want to double read an entry.

As I mentioned on https://github.com/miniflux/v2/issues/533#issuecomment-1836628522, to achieve this, I think there are multiple ways. Personally, I think the solution other platforms/apps has done could be a solution. Having a global filter for read/unread/starred.

Commenting about https://github.com/miniflux/v2/issues/1212#issuecomment-903213487: Having an API like: /category/<category_id>/entry/<entry_id>?unread=true or /category/<category_id>/unread/entry/<entry_id>: I don't think is the same exact thing. Let's consider <entry_id>=101 is unread. If I request this URL /unread/entry/101 ... what sense it makes the usage of /unread

Maybe, something more like: /unread/category/<category_id>/entry/ (unread should go first). And then, when I flip over entries, all the entries recovered from the database, should be from <category_id> and unread.

Does it make sense? Thanks!

[shizunge]

Firstly, we are now discussing the implementation details. Yet I don't think we have answered whether #533 and #1212 are the same problem. Does #1212 solve the problem "avoid reading already read article"?

Secondly would you answer why you need a way to filter/hide/know if an entry was already read? I understand is to avoid reading already read article. Or you might have a different answer?

Thirdly, there is already a switch in each feed/category page to show all/unread article. #1212 tries to solve the problem that articles view does not following that filter. Unread is the default view I believe. If you think the switch on each feed/category page is not enough, there need to be a global switch/setting, that should be another PR. But I think it is out of scope of the original issue, at least not captured by the title.

Sorry personally I don't see a differece between your proposal and https://github.com/miniflux/v2/issues/1212#issuecomment-903213487. I am not working on it, yet there is already a PR for #1212. You probably should address your concerns there.

[juanbretti]

@shizunge, thank you very much for your answer and taking time to discuss this FR. I been reading PR #2138, and the title ("limit feed/category entry pagination to unread unless 'all' query param is specified") describes another very good way to "avoid reading already read article".

#2138 goes beyond #1212, because limits "unread" for feeds and categories. Which is great.

Trying to answer your questions:

• a way to filter/hide/know if an entry was already read? Just to avoid reading already read article. As you said.

• there is already a switch in each feed/category page to show all/unread article Yes, but when I start reading and flipping through entries, the application displays unread and then already-read articles. As you mention, the "articles view does not follow the filter".

• Unread is the default view I believe. Yes, it is. At least for me. Which is great.

• #533 and #1212 are the same problem? I was not aware the issue described on #533 and https://github.com/miniflux/v2/issues/1212#issue-972530520 were related. I mean, I was not aware the application was scrolling through all the items because there was an unread element at the very end of the list; and the "filter" for "Show only unread entries" was not taking into consideration on the entry scrolling.

• Does #1212 solve the problem "avoid reading already read article"? As is described on the issue, I don't think they are the same thing. But from what I had read on the #2138, yes it could solve the same issue.

• the switch on each feed/category page is enough Yes. This is more than enough. The default "Show only unread entries" is enough.

As I said before #2138 looks like it is solving the issue of "avoid reading already read article". Thanks!

Sorry for getting into the implementation details. Just wanted to support the idea there must be a reasonable and "easy" solution. Thank you for working on #2138.