Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Show conflict messages in status bar #2442
If you try to install two mods that conflict with one another, they'll be highlighted red, but there are no hints as to the cause if they're not on-screen.
If you manually install a mod, and then attempt to install or upgrade a mod in CKAN that conflicts with it, the mod is not highlighted red and there are no other clues as to what's going on, see KSP-CKAN/NetKAN#6533.
Some effort was made toward creating a popup for this in #2237, but it was not completed. Part of the challenge is that a popup can be disruptive and is not something we would want to happen every time the user clicks a checkbox.
Conflicts previously were used to mark rows red, abort the creation of a change set, and leave the Apply button disabled, but specific descriptive messages weren't shown.
The code that highlights conflicts relies on
The changes in this pull request are somewhat high risk and should be subjected to close scrutiny. It's possible that I missed an important test case, so please try any obscure things you can think of and report problems!
Status bar shows conflict messages
Now if you select two conflicting mods for install, a short description of the conflict is shown in the status bar to explain why the rows are highlighted:
If more than one conflict is present, only one will be shown, because we stop looking once we find the first. If the displayed problem is fixed, then the other conflict will be shown. Hopefully this will be enough to help users figure out what to do.
Previously, clicking any row would clear the previous status bar message. This doesn't make sense anymore now that the status bar contains useful information about the current conflict. This is now removed, and instead the message is cleared if we are able to successfully calculate a change set without problems.
Conflicts with DLLs included in
Code looks good, although I haven't actually tested it yet. A few general remarks:
That used to be the case, C# 7.0 introduced a functional-style pattern matching syntax. The compiler is smart enough to recognize that an
For confirmation you can check the IL produced by these two pieces of code:
object o = null; if (o == null) Console.WriteLine();
object o = null; if (o is null) Console.WriteLine();
In the first case you get:
In the second case you get:
They're identical. In both cases the two operands are simply loaded onto the stack (lines 3-4) and then compared using the
I generally disagree, one of the benefits of static typing is that we can leverage tools like the IDE to aid the programmer. We know what type an object is because the compiler, and by extension the IDE, knows. We know what we're allowed to call on it because the compiler, and by extension the IDE, knows.
In general, the only time I wouldn't use
Good to know it wasn't actually misbehaving previously, but I think
That assumes that code is only ever viewed in an IDE with those specific features. Personally, I use a regular text editor, and I also frequently browse code on GitHub or in tools like Gitg. In such situations,
The only time I find