Overhaul the mods list screen#3073
Conversation
This aligns the tab order of the button to the natural order (left-right, top-down) of the buttons.
This overhaul has better visuals, better accessibility, and extensibility for mods to customize their mod entry on the list screen.
sciwhiz12
added
enhancement
Last commit published: 2ab33e5863b24e92f1408e7a6384cb1ebf3e103a - version: PR PublishingThe artifacts published by this PR:
Repository DeclarationIn order to use the artifacts published by the PR, add the following repository to your buildscript: repositories {
maven {
name = "Maven for PR #3073" // https://github.com/neoforged/NeoForge/pull/3073
url = uri("https://prmaven.neoforged.net/NeoForge/pr3073")
content {
includeModule("net.neoforged", "neoforge")
includeModule("net.neoforged", "testframework")
}
}
}MDK installationIn order to setup a MDK using the latest PR version, run the following commands in a terminal. mkdir NeoForge-pr3073
cd NeoForge-pr3073
curl -L https://prmaven.neoforged.net/NeoForge/pr3073/net/neoforged/neoforge/26.1.2.110-beta-pr-3073-feat-26.1-new-mods-list-screen/mdk-pr3073.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zipTo test a production environment, you can download the installer from here. |
|
@sciwhiz12, this PR introduces breaking changes.
|
|
Definitely looks like an improvement over the current screen, thanks! One quick question: Is there any reason why |
Hmmm. I've received quite a few suggestions to remove the default sorting method (which is, yes, a carryover from the old mod list screen and just the mod load order) and replace it with A-Z by default. Given the demand, I'll get rid of it and have A-Z and Z-A remain, with A-Z by default. |
The default sort is now A-Z.
The separator is only visible if there is a description to be rendered.
|
Load order seems like a useful thing to have for the sake of quick debug, as otherwise you have to dig through the logs for the same info. It makes sense having A-Z be default, but I think keeping load order around as an option would be helpful. |
Both are now in gray, non-underlined, with the mod ID in italics. The "mod ID" and "version" part of the strings are removed.
For the first two, I meant them to be additional information that was narratable and descriptive of their information. Upon a suggestion, I've removed them and left the mod ID and version plainly. For the last one, the button was named as such since forever I believe. I've corrected it now.
I briefly did consider it, but I decided not to because (a) I didn't want to populate the list with a lot of the same icon for mods that didn't bother to supply an icon, which is just visual noise to my eyes; (b) I didn't want to select such an icon; (c) I prefer having the full name be more visible in the case of having no icon. It should be trivial to add a default icon though, since the icon supports loading any arbitrary texture (without animation, or at least I didn't add any explicit support so I'd assume animations aren't supported).
Done. |
I don't think it would be useful. I think it is rare that a modder would check the mod load order from the mods list screen, much less an end-user who likely are the common users of the mods list screen. Even so, the mod sort order is also available in the logs as you've said, so it is a quick check there or in the console to figure out the mod load order. If it is wanted solely for the case of modders who may somehow need to reach that information conveniently, I could make it so it is available only if running in development. |
Replaced by new translations under the neoforge namespace.
|
This PR is now ready for review. For users, you can use the PR-published installer to try this out in your local environments. No mods should be broken by this change. |
| @FunctionalInterface | ||
| @ApiStatus.Internal | ||
| @VisibleForTesting | ||
| public interface ConfigurationScreenFactory { |
There was a problem hiding this comment.
What's the use case of extracting this out into a functional interface? As far as I can tell, only the default "impl" is ever used.
| @FunctionalInterface | ||
| @ApiStatus.Internal | ||
| @VisibleForTesting | ||
| public interface VersionCheckResultSupplier { |
There was a problem hiding this comment.
What's the use case of extracting this out into a functional interface? As far as I can tell, only the default "impl" is ever used.
| /// The logo is rendered with its original aspect ratio, bounded by the width of the info panel (ordinarily | ||
| /// {@value ModListScreen#INFO_PANEL_WIDTH} pixels) and a maximum height of {@value ModListScreen#LOGO_HEIGHT} pixels. | ||
| @Nullable | ||
| ImageResource logo(); // rendered as rectangle |
There was a problem hiding this comment.
I would prefer this and the associated mods.toml property to be called banner to make it more explicit what it's referring to and to disconnect it from the previous, rather ambiguous logo property (which should be deprecated).
Ideally the default implementations of icon() and this method would then fall back to the logo property if their respective primary property is absent and either both render said logo or check the aspect ratio to decide whether it should be used as an icon or banner.
| import org.slf4j.Logger; | ||
|
|
||
| @ApiStatus.Internal | ||
| class ChangelogScreen extends Screen { |
There was a problem hiding this comment.
Do you have an example of what this screen and the link to it looks like? I currently don't have any mods using the update checker at hand.
I'm also not sure how useful this is considering the update checker is being put into question in general.
4 participants
This PR overhauls the mods list screen with better graphics, better accessibility, and extensibility for mod developers.
The following is a visual side-by-side for comparison between the old mod lists screen and the new mod lists screen:
Taken from 26.1.1.8-beta.
Last updated: 12:23AM UTC+8, Apr 28
TO-DO list:
URLis better thanURI.See ifNot at the moment.logoBlurcan be reimplemented.TestingResourcesand associated data.Noteworthy changes
Here is a non-exhaustive list of noteworthy changes:
iconFilemod property.displayUrl) and issues (issuesUrl) URLs. Previously, these were raw links in the info panel, which could not be clicked or even copied.ModDisplayInfoextension point on their mod container to customize to some degree their entry on the mod list screen. The entries for the authors, license, credits, and description support full components, with hover events and click events working as expected.Modder-facing changes
The following newly-added properties to the
neoforge.mods.tomlare accessible to modders:[[mods]]:iconFileas a path to a root resource or pack resource to a suitable icon. The icon is rendered as a 24px × 24px square. (Can also be specified at the top-level, likelogoFile.)licenseURLas a URL to a link for the associated license.Logos (
logoFile) and icons (iconFile) can be specified in any of three ways:neoforged_icon.png. This is interpreted as a root resource, under the root of the mod's JAR.#, such asmod/neoforge#neoforged_icon.png. This is interpreted as a root resource, under the root of the specified pack. (A mod JAR that containsabchas a pack ID ofmod/abc; one that contains two modsxyzandfghhas a pack ID ofmod/xyz,fgh.)neoforge:textures/gui/bigsquirr.png. This is interpreted as a pack resource, searched in the active resource packs.Note
Due to a consequence of how logos are rendered,
logoBlurno longer has effect.Modders can supply a translation key of
neoforge.screen.mods.info.description.<modid>for localizing their mod descriptions.ModDisplayInfoextension pointFor better customizability, modders can register a new extension point of
ModDisplayInfo(viaModContainer#registerExtensionPoint) to customize the display of their mod's information. The defaults are available and extendible throughDefaultModDisplayInfo.Aside from the
displayNamecomponent, all other components support both click events and hover events.Examples of uses for
ModDisplayInfoare: translatable components, colors, seasonal changes (Christmas, April Fools, Halloween, etc.), clickable links for other resources or authors' profiles, and so on.Note
The search (or rather, 'filter') function of the mod list is case-insensitive and based on the display name of the mod display info. Therefore, modders are encouraged to not translate their display name, in order to provide a consistent searching experience.