search

IBBoard / cawbird

A fork of the Corebird GTK Twitter client that continues to work with Twitter
https://ibboard.co.uk/cawbird/
GNU General Public License v3.0
309 stars 37 forks source link

Display reply restrictions on tweet #429

Open schmittlauch opened 2 years ago

schmittlauch commented 2 years ago

Since a while, Twitter allows restricting who can reply to a tweet. The 2 more restrictive settings are Only people I [the tweet author] follows and Only accounts mentioned in the tweet. Unfortunately, these restrictions are not visually reflected so far in Cawbird. If such a restriction prevents you from posting, at least the error message popup you get when attempting to submit a reply post tells what is going on. But if this restriction is somehow reflected in the API data, it'd be preferrable to know about not being able to reply before taking the time to phrase a reply, click send, and only then find out.

Describe the solution you'd like Each post shall display an additional logo or text hint in case any reply restrictions are active for the post. I am uncertain whether that shall be the case already for the timeline overview of posts or only in the details view. Additionally, the reply button shall change its active state depending on whether the user falls into the permitted group under the specified reply restrictions or not. This shall happen for all views/ layouts, wherever such a reply button can appear.

Describe alternatives you've considered If this information cannot be extracted from the API, then that is the way it is. I'd reject any brittle workaround like web scraping to overcome that restriction.

IBBoard commented 2 years ago

Yeah, I'd love to have this in. But I'm fairly sure this isn't possible in the v1 API. Hopefully they'll add it in v2.

[Edit] There's a reply_settings property in v2 Tweet objects but nothing equivalent in v1 Tweet objects

CodedOre commented 2 years ago

Yes, this is something we can (and should) get into the Twitter Platform on the new Backend.

It isn't yet included though. I as of now plan to add it to PostFlag, which is not implement yet.

Given it is a NewCaw-ToDo, would it make sense to move this issue to the NewCaw repository?

IBBoard commented 2 years ago

Everything that's tagged libhandy redesign was something that I'm not planning until NewCaw 🙂 They're all tickets that are dependent on the v2 API, a significant UI improvement, or some messy bit of the code that it'd be easier to rewrite rather than patch up.