1.6.2-rc.1 fileChooser uses the icon of the target mod

[Jaffe2718]

The file selector now uses the target mod's icon by default, or the midnightlib icon if there is no icon available.

[Jaffe2718]

Rewrote JFileChooser
Now to use it like this:

MidnightFileChooser fileChooser = new MidnightFileChooser(“currentDirectoryPath”, “modid”);

The icon for the mod modid will be used

[Motschen]

Looks great, but sadly, I cannot accept this.
MidnightConfig, by design, has to be fully contained in a single file. I only deviated from it when I added multiplatform support, but those methods are easily replaceable.
Even if you include the classes as subclasses, it increases file size drastically for only marginal returns.
I always aim for keeping the lib as small as possible, and sometimes, this results in compromises being made.
The file chooser is already perfectly usable, so this would only be a cosmetic gimmick.

[Jaffe2718]

Looks great, but sadly, I cannot accept this. MidnightConfig, by design, has to be fully contained in a single file. I only deviated from it when I added multiplatform support, but those methods are easily replaceable. Even if you include the classes as subclasses, it increases file size drastically for only marginal returns. I always aim for keeping the lib as small as possible, and sometimes, this results in compromises being made. The file chooser is already perfectly usable, so this would only be a cosmetic gimmick.

I heard you need to compress the size of the project, so why not remove eu.midnightdust.lib.util.MidnightColorUtil? Because this class isn't used in any other location at all?

[Jaffe2718]

MidnightLib-1.6.2-rc.2.zip
MidnightLib-architectury-1.21-1.6.2-rc.1.zip

And it is not the use of internal classes can be guaranteed to reduce the size of the compilation, for example, I provide you with two copies of the source code here, but the internal class will be separated from the size of the compiled jar is even smaller!
midnightlib-fabric-1.6.2-rc.x.zip

You can notice that rc.2 has a smaller compilation size.

[Motschen]

I heard you need to compress the size of the project, so why not remove eu.midnightdust.lib.util.MidnightColorUtil? Because this class isn't used in any other location at all?

MidnightColorUtil (just like the getDefaultValue function btw) is meant to be used by mods that depend on MidnightLib and want to avoid writing their own color try/catch.

[Motschen]

The one-file restriction is not for file size reasons.
The initial concept of MidnightConfig is that it can be easily copied and customized.

[Motschen]

Now that I'm thinking about it, it doesn't make sense to keep it this way, as I want people to use the whole library...
I'll leave this open and see if I can find a way to implement it more efficiently.

[Jaffe2718]

The main thing is that you can open the compiled jar with the compressed package browsing tool, and you will find that those internal classes will also generate independent class file, writing a large number of internal classes does not make any sense to compress the file size. And I remember that gradle could compile the jar without generating a javadoc, which further reduced the size of the jar.

[Jaffe2718]

The one-file restriction is not for file size reasons. The initial concept of MidnightConfig is that it can be easily copied and customized.

You mean copying the entire MidnightConfig class directly when users develop their own modules? But you can actually let the user use the Mixin feature. But you're right, this PR can't be merged immediately in a hurry.

[Motschen]

You mean copying the entire MidnightConfig class directly when users develop their own modules?

Yes, exactly