Also, the refactoring/expansion of the VariableInspector - which now lets you populate script-defined inspector fields that can hook back to object fields or global vars, rather than explicitly inspecting a single object. This one in particular has a lot of potential.
That's very interesting (If I understand correctly). I remember wasting a lot of time into attempting to add script-defined field into the variable inspector listing during my last TorqueLab work.
I also want to try and better standardize the 'interfacing with the editor' itself, like having a standard API for adding a new button to the tool bar, or easily add a listing in the editors popup menu list,etc.
In that vein, I'm sure you've got some thoughts and notions for ideas that would make doing the stuff you were before way less of a hassle, so if you've got thoughts on ways the editor could be streamlined and made easier to expand, I'm game to hear it, because it's definitely still pretty messy to expand the editors and I think it shouldn't be.
It was a bit my goal when I start TorqueLab, any little modification was difficult to make without breaking something. I wanted to make it modular so anyone could write or modify a plugin that fit better his development needs. At start it seemed quite simple but more I digged into the Tools scripts I realized it was not written to make the task simple.
I have been thinking about TorqueLab all day and I think I will give it a rebirth because all that work cannot be wasted... I'm trying to build a limited development plan so it don't become a Monster to manage and also I will try to work on it so it become the official editor by sticking to conventional scripting and other rules. (If you have some documents/infos/directive to share relative to Torque3D scripting standard, I'd like to have a look at those).
Again, no promises for now but here my initial global plan for next TorqueLab work so you have a better idea and you could give suggestions/feedback. (
Green = Features already there,
Orange= Features Half-Implemented)
Modular/customisable UI
- Allow to rerrange Toolbars and buttons in a toolbar
- add new butttom (linked to script I guess)
- Drag and drop panels working with TabBook
General System
- Replacing the settings system using Setting Class which store in xml with a basic system that use standardized Prefs (Ex: Tools::Editor::Variable)
Unless there's a reason to use the Setting Class. TorqueLab prefs are only saved when exiting so no prefs which cause a crash are stored.
- Make all editor/plugin independant and allow to add new plugin simply
- Make it possible to use GuiEditor to customize the Tools (Main editor, plugins, Dialogs). (Currently you have to be very careful and mostly add changes Manually to .gui)
- Remove all old/unused functions/scripts (There's a lot)
That's just a quick list and I will try to define it better in incoming weeks. Might be a good idea to start a thread about it and hear about what the community want. Also, as you can see in the list, I want to avoid specific tools enhancements for now but would still keep some that I judge usefull and which can't hurt anything. There's also some heavier functionality that I plan to cleanup and propose. For example, I have work on a MaterialEditor Replacement that work as a dialog so it's always accessible without switching Plugin so it can be use by all plugins that need it (ShapeEditor, RoadEditor, SceneEditor, etc)
Sooo, I will keep thinking about it and would make a post about it soon to get the community feedbacks and suggestions. For now, I haven't even tried it since last March...
Quickly about a basic Dark Theme, a problem I remember is that some editors UI element use the GameProfiles so when you edit them to look fine in Dark UI, they are not good for Game use, I think it could be a good thing to start by removing those conflicts from Stock editor. I think all profiles used in editor should start by Tools to avoid confusion. There's not much problematic profiles and a quick FindReplace in tools scripts can fix those. I would do it but I'm still affraid of the Pull Request stuff and how it should be made... I don't think someone would see problems since the Game profiles won't be affected and it will remove the issue when someone modify the GameButtonProfile to see some editor buttons affected by the changes.