Some of my recommendations for Rosalina

[Dynamic-Pistol]

So I have some nitpicks with Rosalina, I am going to be more direct than formal so here they are

Use generics instead of casting

when I checked the generated partial classes, they seemed to be cast instead of being Qed with generics, is there a reason for not using
generics and casting instead? I think generics will help in the long run

Support for Editor Inspectors, Property drawers and etc

as it says, support for these would be helpful

(Maybe?) support for the new runtime binding

unity recently released runtime binding, but it's for the 2023 beta/alpha so it can be delayed, also if it would be better to be done manually, then ignore this point

Manual generation

basically instead of having automatic generation for files, have an option to manually generate for them or select which files to generate specifically (maybe even choosing what kind of generation it is like runtime, editor window, etc)

Custom file path

choosing a custom file path would be a QOL change, also having the Rosalina settings SO be in the packages part would be better if possible

[Eastrall]

Thank you for these suggestions, I will try to answer these the best I can.

Use generics instead of casting

According to the UIToolkit extension code, the Visual Element Q(string name, string className) and TElement Q<TElement>(string name, string className) methods does the same thing.
I used the casting approach when building this library to be closed to the official documentation. Using casting or generics doesn't change much imo.
The only thing that could change is that with the generic method, the result is "casted" using the as keyword, which will result in a null element if the cast fails.
I don't mind changing to the generics approach,

Support for Editor Inspectors, Property drawers and etc

Currently, Rosalina supports editor windows using the editor-extension-mode attribute. To support editor inspectors and more, we'll need to rework this process and maybe add some extra configuration to the settings file to indicate wether it's an editor or inspector extension.
Or, wait for next version of UIToolkit and UI Builder that will add some UI Builder extensions capabilities, thus we could add an extra parameter to the inspector to define the UXML document as an editor inspector / drawer / window.

(Maybe?) support for the new runtime binding

I need time to study this point and try the new runtime binding system.

Manual generation

Good idea, maybe using right-click on a UXML file, and showing a toggle menu item to add/remove the file from the Rosalina's generation system.

Custom file path

Are you talking about the settings file or the "auto genearted" code path ?

[Dynamic-Pistol]

for the last point, sorry for the misunderstanding, I should have made them 2 different points, but basically, it would be nice to choose a custom output path for the auto-generated files, and I feel like it would be better if the Rosalina settings SO was at least moveable so I could put it in a plugins folder, but if that is not possible it would be at least better if it could be put somewhere a user normally wouldn't edit, perhaps in the packages part of the project?

[Eastrall]

for the last point, sorry for the misunderstanding, I should have made them 2 different points, but basically, it would be nice to choose a custom output path for the auto-generated files, and I feel like it would be better if the Rosalina settings SO was at least moveable so I could put it in a plugins folder, but if that is not possible it would be at least better if it could be put somewhere a user normally wouldn't edit, perhaps in the packages part of the project?

I understand, in a sense, moving the generated files folder shouldn't be that hard to do. As for the settings, I'll need to do some testing, but I believe it's better to have the settings in a unique place.

[Eastrall]

After some tests, I have changed the settings provider mechanism and store the RosalinaSettings.asset file in the ProjectSettings folder. It will be stored along the other project settings like AudioManager.asset, InputManager.asset, etc...

Furthermore, I've started working on the "Manual Generation" system, which allows you to select which UXML you want to include into the automatic generation process. Also, I took the opportunity to include the suggestion made on PR #25 and added the type of generation you want to apply to the document:

I could also include the "Custom generation path" within the settings and make the generators use this path instead of a hardcoded one.