Custom mod labels, favorites, hiding

[HebaruSan]

Motivation

A longstanding common request is to provide additional tools for organizing and managing mods. Some of the use cases from various issue descriptions:

• we may have to remove some mods from our list due to their incompatibilities, but we don't want to forget about it or would like to get and alert when they're updated

• for checking about release new version

• keep tabs on a mod that hasn't been updated yet

• a particular mod that we really want to try out, but just don't feel ready yet for all of their complications, settings, or learning curves

• for look into it later

• for testing in the future

• for keep in list nearby

• single out mods they use for particular playstyles

• mods that I ended up preferring not to have installed

• avoid reevaluating a mod they've already rejected

In short, the request is for a way to associate modules with an arbitrary number of user-defined groups with various configurable side effects.

Changes

Now the mod list right click has a new Labels submenu at the top:

The options above the separator are checkbox toggles. If you click one of them, a checkbox appears to indicate membership in the label:

Each label can have various additional optional properties (and the two default labels can be edited or deleted). If you click Edit labels..., a popup will appear:

Editing controls appear if you click a label name or the Create button, allowing you to define and customize labels that can be applied to groups of modules:

Option	Functionality
Background	Background color for rows of modules in this label
Instance	If this is populated, then this label is only available in the selected instance, otherwise it's available everywhere
Hide from other filters	If checked, this label will behave as a "hide" feature, removing its member modules from standard filters
Notify on updates	If checked, the user will receive a visual alert when modules from this label become compatible
Remove on updates	If checked, modules in this label will be removed automatically when they become compatible
Alert on install	If checked, then attempting to install a module in this label will generate a special red warning in the changeset:
Remove on install	If checked, then installing a module will automatically remove it from this label

Each label so defined will appear at the bottom of the filter dropdown as if it was a normal filter:

You can click them to view the mods in the associated label:

With this functionality, if a user finds a module they never wish to see again, they can right click it and select Labels > Hidden, and it will disappear. If they ever want it back, they can visit the Hidden filter and right click to toggle it again. If they want to make sure it isn't installed even as a dependency, they can edit the Hidden label and enable Alert on install.

If a user needs to uninstall a module because they have updated to a game version with which it is not compatible, they can right click it and select Labels > Favorites, and then uninstall without fear of forgetting it. If they edit the Favorites label and enable Notify on updates, then they will be notified when this module becomes compatible again.

UK, US, and German translations are provided, but the German one is from Google Translate and needs review by a fluent speaker. (I think I missed a few strings, will be looking for them shortly.)

Storage

All of the data associated with this functionality—label names, colors, module list, etc.—is stored in ~/.local/share/CKAN/labels.json or the equivalent path for each OS. I thought it was better to avoid mixing it with the registry or the settings, and the data here will be pretty small even for heavy users. And this way it will be easy for users to copy/transfer their labels.

Fixes #1021.
Fixes #1022.
Fixes #1677.
Fixes #1678.
Fixes #1902.
Fixes #2082.
Fixes #2155.
Fixes #2176.
Fixes #2180 (all that's left is mod marking and AD conversion, which isn't really related).
Fixes #2901.

[HebaruSan]

Added the list of of standard Tags from the metadata in the middle of the dropdown:

[HebaruSan]

Good point about background color conflicts, I'll have a look at that.

ModuleLabelList.LabelsMatchingModule was left over from an earlier implementation, will remove.

Re: GUI vs Core, I had the label classes in Core initially and moved them to GUI for a few reasons:

• ModuleLabel.Color's type is System.Drawing.Color, which seems GUI-specific
• I'm not sure that the concept of custom labels is as useful for other UIs; summarizing and organizing are not as much of a priority when you mainly interact by typing mod names directly as in ckan install GPP
• I wanted the default labels' names to be localized (Favorites vs Favourites); we do not translate strings in Core, and moving GetDefaultLabels to GUI by itself was weird
• We can move them to Core later if we have to

They're not overwhelmingly strong reasons, and I could agree with changing this back, but for now this seemed cleaner.

[HebaruSan]

In latest commit:

• Show/hide tags via the mod list header right click
  
  • Save/load from ~/.local/share/CKAN/tags.json just like labels
• Filter button says "Label (name)" or "Tag (name)"
  • The German translations for these are a huge mess because Google Translate seems to treat them as synonyms and I have no idea how to disambiguate them
• mainModList.IsVisible now short-circuits

Row background color conflict fix is still in progress.

[HebaruSan]

Latest commit should make the row backgrounds consistent.

[DasSkelett]

Re: GUI vs Core, I had the label classes in Core initially and moved them to GUI for a few reasons:

* `ModuleLabel.Color`'s type is `System.Drawing.Color`, which seems GUI-specific

* I'm not sure that the concept of custom labels is as useful for other UIs; summarizing and organizing are not as much of a priority when you mainly interact by typing mod names directly as in `ckan install GPP`

* I wanted the default labels' names to be localized (Favorites vs Favourites); we do not translate strings in Core, and moving `GetDefaultLabels` to GUI by itself was weird

* We can move them to Core later if we have to

They're not overwhelmingly strong reasons, and I could agree with changing this back, but for now this seemed cleaner.

This makes perfect sense. My primary concern were the tags, but you created the corresponding files in core for them, so that's fine.

• Save/load from ~/.local/share/CKAN/tags.json just like labels

The only setting that is saved in the file is hidden_tags[]. The tags themselves are part of the registry, unlike the labels.
Is a separate file for this setting useful? I can also imagine this being part of the config.json.

• The German translations for these are a huge mess because Google Translate seems to treat them as synonyms and I have no idea how to disambiguate them

I can confirm that this is very hard to translate. They are two very similar words each with several possible, partly common, translations, with rather different use cases.
But none of these seem to be made for the digital ages... Most of them are only used for physical sticky paper you put on something. And depending on why, where and how you pet them on there's a different German word...

For digital things often times the English words are used, especially the word tag/tags.

Maybe I'll go with Beschriftung for label and Tag or Kategorie for tag. I'll think about it a bit and do a PR then.

[HebaruSan]

The only setting that is saved in the file is hidden_tags[]. The tags themselves are part of the registry, unlike the labels.
Is a separate file for this setting useful? I can also imagine this being part of the config.json.

I had this in registry.json at first, which of course meant that saving the list of hidden tags paused the GUI for several seconds. Having seen labels.json work pretty well, this seemed like the way to go. If we need to save more info about Tags in the future, we'll already have an independent structure for it.

I'd rather leave config.json alone for now, this is more of a UI state thing than configuration.

[HebaruSan]

• Refresh rows after editing labels
• Put label and tag filters into submenus
• Ignore labels belonging to other instances
• Show modules for hidden tags when viewing their specific filter

[DasSkelett]

Okay, I think I'm done now review-wise. Looks good, and all the options for labels appear to do what they promise.

Do you want to want to include the display of a mods tags (and labels?) that we wrote about on Discord in this PR or in another one?

[HebaruSan]

Do you want to want to include the display of a mods tags (and labels?) that we wrote about on Discord in this PR or in another one?

I'll add it here. Might take a day or two.

[HebaruSan]

In the latest commit, the tags and labels show up between the name and abstract as gray text hyperlinks. Clicking them takes you to the filter for that tag or label.

[DasSkelett]

With the GUI part added and all active netkans tagged, I think this is good to go. In my testing, everything worked like it should. Thanks for implementing this @HebaruSan.

[TangentFoxy]

Thank you so much for this! <3