[Feature] Show reverse relationships

[tjanke42]

Problem

One of my 267 installed mods is causing a problem. To narrow it down, I use a quasi binary search - delete half the mods, test. If the problem went away, the offending mod is in the half deleted, if not, it's in the half still installed. Rinse and repeat. In this way, even with very large modlists, you can find the offending mod in only 7 or 8 tries.

However, dependencies complicate this. In a large modlist, it's often the case that deleting half the mods will also remove a great many mods (that are dependent on some of the ones you deleted) from the group you wish to leave installed.

It would be great if information about which mods depend on a particular other mod were easily viewable. For example, ASET Props and ASET Avionics depend on ASET Agency. ASET Props and ASET Avionics both show this dependency in their relationship tab. ASET Agency, however, does not mention that there are two other mods that depend on it.

This information would be really useful when going through the modlist and deciding which mods to uninstall and which to leave as part of the quasi binary search.

I know you can search for e.g. "dep:ASETAgency" (which shows that CKAN has this information) but frankly, having to interact with a search bar and type in a search query for every single mod in the group I want to examine (133 mods in the first round of testing) is just way too much work and friction. Especially when there is an info tab labeled "Relationships" that seems tailor made for displaying just this sort of info.

Suggestions

I'd like the Relationships tab to display information on what other mods depend on this mod. I don't know what you'd call it; I think you already use "supports" to mean something different.

Describe alternatives you've considered
The search bar, but it's just too damn tedious for 100+ mods at a time.

Additional context
I asked about this on discord, and HebaruSan was kind enough to respond. In addition to educating me a bit (thank you!), he also gave some pushback. His argument against had to do with 'which mod logically "owns" a relationship', and metadata, and 'some modders complaining that the recommendations/suggestions screen shows things they didn't approve'.

Respectfully, that is a mod-author-centric, data-structure-centric argument. I'm a software engineer so I totally understand that viewpoint. But as a user, I have a very different point of view. My user-centric argument is this:

CKAN has this information, and as a user I really don't care where it came from or how CKAN knows, just that it does. But that information is currently only accessible through a tedious bit of UI, when there is an already-allocated bit of screen real-estate dedicated to displaying just this sort of information. I think it should go there.

[HebaruSan]

Displaying reverse relationships is definitely do-able; I thought I vaguely recalled considering it during #2226, but I made no note of it there, so maybe I'm imagining that. But if I did, then the main reason for leaving it out was that we lacked a use case for it. Thanks for giving us one.

My main concern with adding this would be user confusion; we need to present this information in a way that doesn't prompt users to report bugs because "ASETAgency doesn't really depend on ASETProps, CKAN is broken!!1" A "Reverse relationships" checkbox, defaulting to unchecked, could solve that nicely, but would that be too tedious for what you want to do with it?

[tjanke42]

I can see how labeling this would be tricky; describing this reverse dependency in a way that's clear, unambiguous and concise is, admittedly, a challenge. Phrases like "depends on this mod" could be interpreted either way, and "other mods that depend on this mod" is a bit long and wordy. I'm not sure I have any good suggestions.

Checkbox, tedious? Not at all (assuming you mean one checkbox somewhere for the UI as a whole, and not an individual checkbox for each mod). Check the box, the reverse-relationship info shows up in the relationship tab for each mod, perform my testing, then (if I find it annoying or something) uncheck the box to hide it again. Sounds wonderful.

[HebaruSan]

Checkbox tedious? Not at all (assuming you mean one checkbox somewhere for the UI as a whole, and not an individual checkbox for each mod). Check the box, perform my testing, then (if I find it annoying or something) uncheck the box to hide it again. Sounds wonderful.

Great! To make sure, what I had in mind was a new checkbox on the relationships tab, kind of like this (please forgive the rough mock-up):

Its state could be "sticky" or not when switching from one mod to another; I can see valid reasons for either of those options. If you were doing an exhausive search through a bunch of mods' reverse relationships, it would make sense to keep it checked, but if you were just quickly checking something for one mod it would be better to uncheck it.

[HebaruSan]

There is a performance difference here as well; it's much, much faster to just list the current mod's relationships as compared to searching all mods looking for mentions of the current mod. But in practice the existing search dep:whatever feature runs quickly enough, so that's unlikely to be a significant problem. Though I suppose the above checkbox would have to examine recommendations, suggestions, etc., and therefore presumably take longer.

[tjanke42]

Mockup looks good, would solve my problem. For my specific use case, sticky would be necessary (not-sticky would kinda defeat the purpose) but like you said, I can also imagine valid reasons for it being the other way.

Maybe a meta-checkbox in settings that governs whether it's sticky? Nah, that feels... silly.

I have a reasonably fast machine; ckan search results are usually displayed before I can finish typing the full query, and update in near-real time as I type, so I imagine performance for this feature would be similar. For those with older, slower rigs... would it be an issue? Who knows.

[HebaruSan]

It would be tempting to exploit tri-state checkboxes for this. The unchecked state could stay unchecked, clicking once could move to the indeterminate filled-in-box state that becomes unchecked, and the fully checked state could stick:

[HebaruSan]

I have a reasonably fast machine; ckan search results are usually displayed before I can finish typing the full query, and update in near-real time as I type, so I imagine performance for this feature would be similar. For those with older, slower rigs... would it be an issue? Who knows.

I have a prototype running now:

Unfortunately it's quite noticeably slower, taking several seconds to load some mods; it has to do a lot more work than a dep: search, both because it's always searching all 5 relationship types, and because it has to look two levels deep to know whether to show the + icon to expand the node. That's a lot of loops over the list of all mods.

[HebaruSan]

After some optimizing and parallelizing, it's not nearly so bad. Instead of freezing for what-felt-like-a-minute to load ModuleManager's reverse relationships, it now loads the immediate children almost instantaneously and then fills in the grandchildren and the + icons while you watch. There's more flickering now, but that's probably an acceptable trade-off.

[tjanke42]

You da man. Thanks so much!