search

jessepeterson / margarita

Web frontend for reposado
The Unlicense
245 stars 40 forks source link

Hide deprecated updates unless in a branch #57

Open poundbangbash opened 6 years ago

poundbangbash commented 6 years ago

This change has been proposed a couple times quite a few years ago in https://github.com/jessepeterson/margarita/pull/18 and a related PR at https://github.com/jessepeterson/margarita/pull/25. Those PRs are out dated with the current code now but I still think there there is value to this change.

This PR addresses the same change in the previous PRs where deprecated updates that are not in any custom branches are hidden when "Hide commonly listed updates" is checked.

I understand wanting to see deprecated updates but aren't they only of visual value if they are still in a branch? If an update is deprecated and not in any custom branches I don't know why that would need to be seen all the time. I have lots of disk space so I rarely purge deprecated updates in case I need to reference them for historical reasons or for reference when assisting another admin. The unused, deprecated updates don't need to be seen they just need to be accessible which they are in the view when not hiding common updates.

-Eric

jessepeterson commented 6 years ago

Heya! Sorry for the delay. I'm not against this PR in principal. I think I might want to see some UX changes to support it though — mainly updating the wording on the hide/unhide button. Separately I'd be curious what others think of this idea. Personally I used the 'deprecated' indicator as a hint for me to go purge deprecated updates (to e.g. save space/keep things tidy) so seeing it regularly was handy.

As a future thing it would be neat to have all sorts of filtering/viewing options and save them the preferences to Local Storage.

poundbangbash commented 6 years ago

No worries. I saw your other reply previously stating the same thing in another conversation. I guess we have a conflict of needs. I’ve implemented my changes in my own instance and can continue on my own fork if needed.

The deprecated updates are still visible when common updates are unchecked. This just changes the default behavior to show all unique inclusions. I have enough cheap disk space for reposado that purging deprecated isn’t a concern yet.

-Eric

On Jun 26, 2018, at 6:02 PM, Jesse Peterson notifications@github.com wrote:

Heya! Sorry for the delay. I'm not against this PR in principal. I think I might want to see some UX changes to support it though — mainly updating the wording on the hide/unhide button. Separately I'd be curious what others think of this idea. Personally I used the 'deprecated' indicator as a hint for me to go purge deprecated updates (to e.g. save space/keep things tidy) so seeing it regularly was handy.

As a future thing it would be neat to have all sorts of filtering/viewing options and save them the preferences to Local Storage.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

jessepeterson commented 6 years ago

I guess we have a conflict of needs. I’ve implemented my changes in my own instance and can continue on my own fork if needed.

Sorry, I guess I wasn't very clear, @poundbangbash. :) I'm willing to merge this if the UI/button label text is updated somehow to indicate concisely and exactly what is being hidden — that was my biggest concern.

Obviously a one-size-fits-all approach necessarily means it doesn't fit for some folks, I'm okay with changing the semantics. Especially since there's now three issues of people trying to solve this particular thing. :)

poundbangbash commented 6 years ago

How about something like this:

I'd like to get unicode or some way to identify that a check = unique updates, versus unchecked = all in case it isn't obvious based on the items selected, etc.

-Eric 

On Jun 27, 2018, at 11:51 AM, Jesse Peterson notifications@github.com wrote:

I guess we have a conflict of needs. I’ve implemented my changes in my own instance and can continue on my own fork if needed. Sorry, I guess I wasn't very clear, @poundbangbash. :) I'm willing to merge this if the UI/button label text is updated somehow to indicate concisely and exactly what is being hidden — that was my biggest concern. Obviously a one-size-fits-all approach necessarily means it doesn't fit for some folks, I'm okay with changing the semantics. Especially since there's now three issues of people trying to solve this particular thing. :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

poundbangbash commented 6 years ago

I figured out the unicode. Is this too much? image