Bult-in early display stuff is not reusable

[ChiefArug]

When trying to implement an alternative display window, even to do something as simple as change the window's position, one must copy well over 1000 lines of code (from five class files) to do anything due to the large amount of methods that are private.
The 100 line methods don't particularly help either, but for something as functional as opening a window it makes sense so as to not get lost in method chains.

Could the access around these things be loosened so that making alternative early display windows based on the existing one is easier without having to copy all that code or spend ages rewriting essentially the same thing?

[shartte]

I am against making the internals of earlydisplay an API.

[shartte]

p.s.: You have not actually specified why you would want to make a full derivative of earlydisplay. Can you clarify why that is necessary?

[ChiefArug]

My usecase is attempting to change the initial monitor of the window (I do plan on turning it into a PR) but that is not particularly relevant as almost any change to the loading screen requires re-implementing everything.

I can see why from an API design perspective early display should not be a proper API because it is a very brittle thing. However from an actual usability perspective, anyone wanting to make a new early loading screen has to re-implement 90% of this stuff anyway, so it makes more sense to make it available, rather than having them copy it (as modders do) and not benefit from any fixes Neo might make to the code.