-
Notifications
You must be signed in to change notification settings - Fork 37
Display replies below tweet #16
Comments
Any progress on this? |
No, not yet. You'll see commits appear in this ticket or a branch called "bug-16-blah-blah-blah" when I start working on it. I've looked at it before in the Corebird days but never took it too far because Baedert didn't want it. In some ways it should be quite easy, but in others then I think it needed some reasonable thought to be done properly. |
The check to see if something is a reply is a bit odd (tweet vs RT) so make a helper method to check it for us
This allows us to keep the same model for timelines and replies (because it's a lot of ugly C code) while continuing to sort timelines newest-first and replies/replied to as oldest-first
* Renamed widgets to be more representative * Set sort order of model * Remove "reply indicator" because a) replies are now below and b) "in reply to" shows there's a replied thread above the tweet
This makes more sense when making replied to tweets appear above a tweet (we work up the chain)
Okay, I think that branch fixes it. I'm just running it locally for a while to make sure. Any feedback on it is welcomed (e.g. whether we need more of an indicator that there's "replied to" tweets above, even though the tweet says "in reply to X") |
The old method was very implementation-centric rather than intent-centric. It's now better but not perfect.
Oh, just remembered what I wanted to ask for a while. cawbird doesn't load all the replies for a tweet when you open one. For example, link |
That's more relevant to #17. The short answer is that a) there's no official way to get the replies to a tweet (limitations) and b) the best approximation we have uses the search and is limited to 7 days of history and a few other constraints (again, limitations!). The time limit isn't relevant here, but I imagine some of the other constraints area. Hashtag-Blame-Twitter-API-Again |
Also fixes two bugs in removing tweets and removing "old" tweets when ordered
"Oldest" is more meaningful than "last" when we have different sort orderings
Fixed and merged when we merged #17 |
The check to see if something is a reply is a bit odd (tweet vs RT) so make a helper method to check it for us
This allows us to keep the same model for timelines and replies (because it's a lot of ugly C code) while continuing to sort timelines newest-first and replies/replied to as oldest-first
* Renamed widgets to be more representative * Set sort order of model * Remove "reply indicator" because a) replies are now below and b) "in reply to" shows there's a replied thread above the tweet
This makes more sense when making replied to tweets appear above a tweet (we work up the chain)
The old method was very implementation-centric rather than intent-centric. It's now better but not perfect.
Also fixes two bugs in removing tweets and removing "old" tweets when ordered
"Oldest" is more meaningful than "last" when we have different sort orderings
Baedert chose to put replies above the tweet in tweet view, so you have to scroll up to see them. This seems odd and is the opposite of what Twitter (and almost every other threaded UI) does.
I should finally get round to making the change to flip it so that it reads the "right" way (scroll up to see previous posts in thread, replies are automatically visible).
(Reported by @jacobmischka as baedert/corebird#369 and backed by me but rejected in Corebird)
The text was updated successfully, but these errors were encountered: