This plugin is mainly useful for subscriptions to forum topics, (Reddit) conversations, and feeds that often include follow-up articles.
Upon opening any feed it will make sure that if 1) your view mode is set to Adaptive and 2) there are unread articles, the sort order will be set to Oldest first. This way the conversation of the topic can be read top-top-bottom (or follow-up articles will be presented below previous ones). If (1) or (2) is not the case, it will switch back to the default sort order, so you can quickly find the articles that you have read last.
A small issue remains with this plugin though: upon first load (or a browser refresh/F5), the unread count may read ‘0’ when checked by the plugin, even though later on the unread count turns out to be >0 when actually calculated. In this case, I can either wrongfully set the order to ‘Default’, or not do anything at all. So, as a workaround, I’ve specified that the plugin shouldn’t change the order upon first load when the unread count is 0.
What I would like is to be able to force a calculation somehow, wait for that and set the order accordingly.
Yes I know. Unfortunately there is no distinction between “counter is not ready yet” and “no unread messages”: in both instances, the returned value is ‘0’. Would be great if the returned value is ‘-1’ or null in case the calculation hasn’t been done yet, or if there’s a hook after calculation has been finalized.
i haven’t found any other places where unread is assumed to be equal to zero, but it’s possible that this could introduce some minor issues. if something goes weird, report back.
Thanks! I found that using Feeds.getUnread() somehow still returns 0 if the unread counts are not yet calculated, so I can’t really use that. I would rather make use of a -1 than of the HOOK_COUNTERS_PROCESSED, since - now it’s implemented - my tests indicate that it has a big delay: the feed is fully displayed first, then rendered again in the changed order.
However, I found that HOOK_FEED_SET_ACTIVE is triggered a second time upon load, and that the unread count is properly set that time. So I simply ignore the very first trigger, then start setting the order from the second trigger on.
So, what could be done is
Implement that Feeds.getUnread() does return -1 when not calculated yet
Or just revert the changes
e: when I select a non-virtual feed without unread articles, I see that HOOK_FEED_SET_ACTIVE is triggered 3 times (without my plugin intervening). The first 2 times the count is 0, then it’s -1. A bit odd.
that’s strange, initial value should be set as -1 as per getfeedtree. what kind of feed were you testing on?
e: some feeds (i.e. contents of Special category) may have their initial value set to 0 (or an actual unread amount) simply because counters are assigned on load already. counters are then loaded lazily for the rest of the tree.
maybe that’s because of lazy loading? i can change it so that hook is only invoked if feed actually changes although that would mean it is only being called when feed is requested asynchronously and no headlines are available (yet)
Here is some console output with comments:
Example of problem:
Fresh articles feed (18 unread articles):
HOOK_FEED_SET_ACTIVE | unread count = 0 // First time is ignored
HOOK_FEED_SET_ACTIVE | unread count = 0 // Second time should at least be -1, it's not
plugin: setOrder([-3, false]) | Unread = 0 // So I set the order according to a wrong unread count
HOOK_FEED_SET_ACTIVE | unread count = 0 // Count is still wrong
HOOK_FEED_SET_ACTIVE | unread count = 18 // There it is... But it's ignored by the plugin, because it already set the order according to the wrong unread count right before. I need to do that, because otherwise a manual change of order wouldn't be possible anymore (that also triggers HOOK_FEED_SET_ACTIVE).
Example of correct process:
Category ‘Uncategorized’ with 1 unread article:
HOOK_FEED_SET_ACTIVE | unread count = 0 // First time is ignored by plugin
HOOK_FEED_SET_ACTIVE | unread count = -1 // Now that it's -1, I register HOOK_COUNTERS_PROCESSED (sometimes the counter is already correct, so I'm not gonna register HOOK_COUNTERS_PROCESSED by default. Also, there's no way to UNREGISTER a hook.
HOOK_COUNTERS_PROCESSED | unread count = 1 // There we go, it's 1
plugin: setOrder([0, true]) | Unread = 1 // Order is set accordingly
HOOK_FEED_SET_ACTIVE | unread count = 1 // Triggered by the reorder, ignored by the plugin
The full (JavaScript part of the) plugin right now:
if there’s hash parameters in the URL setActive() is called before tree has loaded, i suppose, that’s why there’s no data (yet). maybe this should happen later when loading.
looks like in this situation (tree and model is available but no data has been received) FeedStoreModel.getFeedUnread() falls back to 0, it should return -1.
you can try changing FeedStoreModel.js:34 to return -1 instead of 0 and see if that fixes things.
i made a small change which should stop Feeds.setActive() to be called multiple times by moving hash handling later during startup (to feedlist init) which simplifies things a little bit.
I found that -3 is often availabe quickly (so the new counts hook wouldn’t be used by the plugin then), while feed counts lower than -3 aren’t available for a while. But I’ll check if your changes in a moment. In the meantime I added the following to my test instance, simplifies things afterwards:
Added to Pluginhost.js:
unregister: function (name, callback) {
for (var i = 0; i < this.hooks[name].length; i++)
if (this.hooks[name][i] == callback)
this.hooks[name].splice(i, 1);
}
This way, the plugin hook that only has to be run once can unregister itself with PluginHost.unregister(PluginHost.HOOK_COUNTERS_PROCESSED, functionVar);
There’s an issue with that latest commit: it tends to default to feed 0 (archived articles), even though another feed was selected / in the URL. Just switch feeds a couple of times and refresh in between, it’ll start jumping to archived articles after a while.
I’m using Waterfox (i.e. Firefox v56) as daily driver and disabled this plugin (and later on all plugins) to be sure it wasn’t an interaction between the plugin and the commit.
Perhaps it’s a race condition issue that happens to show on my specific system.
e: No, the same happens on two other systems. The installation is as vanilla as it gets, no plugins, and it exhibits this behavior ONLY in the latest commit.
no, we’re not doing that. the way it is now is cleaner and easier to understand, if there’s a race condition it’s better to figure out why it happens. in any case it’s not a high priority issue, restoring active feed on ctrl-r is mostly useful for debugging, it’s not like you need to reload tt-rss all the time.
it seems that something is calling Feeds.open() before feedlist init, so hash parameters get reset. not sure what it could be tbh, a trace would probably help.