search

privatenumber / snap-tweet

Snap a screenshot of a tweet 📸
MIT License
333 stars 19 forks source link

More parameters #38

Closed FelixDubois closed 1 year ago

FelixDubois commented 1 year ago

Hi ! I have added some commands :

Jolly-Pirate commented 1 year ago

Increasing the scale to 2 is a good idea, it yields better and cleaner resolutions. However, keep in mind that when using the --width parameter, the final width is doubled because of the scaling.

Is it possible to remove the "Follow" string next to the user's account? image

FelixDubois commented 1 year ago

Here you go @Jolly-Pirate. I hadn't noticed the thing about the scale so thanks 👍

Jolly-Pirate commented 1 year ago

Awesome, removing the Follow button works.

Jolly-Pirate commented 1 year ago

About the scaling, it could be passed on as a cli parameter instead of hard coding it.

Jolly-Pirate commented 1 year ago

Thanks for adding the scale option, but it conflicts with the current one -s, --show-comments Show comments Gives an error Error: Duplicate flags named "s"

May I suggest changing it to x (as in multiplier) and don't forget to update the readme :)

Jolly-Pirate commented 1 year ago

@FelixDubois I found a little bug, when the --show-thread and --hide-follow-button options are enabled, the Follow button appears in the parent tweet.

snap-tweet-AlfrescoDent-1604069387664760832-thread

privatenumber commented 1 year ago

Thanks for the PR @FelixDubois

Ideally each feature:

  1. Has a feature request associated with it so the use-cases, motivations, and alternatives are clear
  2. Are introduced in it's own PR so they're they're easily reviewable and mergable

Right now I'm not clear on what changes you're introducing and why.

FelixDubois commented 1 year ago

So I have to make a PR for each parameter I need to add?

privatenumber commented 1 year ago

In open source projects, you should start by creating an Issue describing the feature request. The feature request should include the motivations for the request, use-cases, and alternatives. The Issue thread can host a discussion about the feature before it's approved. Once approved, anyone can open a PR to address the request.

By making a PR for each feature request, they can be easily reviewed and merged without being blocked by unrelated concerns in the PR.