Bult-in early display stuff is not reusable
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?
I am against making the internals of earlydisplay an API.
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?
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.
anyone wanting to make a new early loading screen has to re-implement 90% of this stuff anyway
That's not necessarily true
While it is not ideal, it is possible with reflection: https://github.com/lukaskabc/SimpleCustomEarlyLoading
But I agree that this is a grey area and some methods are difficult or impossible to intercept without reimplementation.
For example in my implementation, it would help if at least the classes were public, so I could eliminate the need for dynamic proxies.
Earlydisplay was now made entirely internal, and I'm not aware of any plan to change that.