Built-in Style Editor

[undisassemble]

Description

Adds a style editor directly to the editor, so you don't need to open a separate text editor to modify styles. Changes are applied live, instead of needing to refresh the style to see differences. The style saves with the rest of the project, e.g. via Ctrl+S or the save button.

Also fixes a compilation error I was experiencing on GCC 14.2.0 from a missing #include <algorithm>.

Considerations

• I did my best to make the style editor window match the appearance of the events/properties windows, but the actual editing widgets (specifically the color picker) can probably be improved.
• May be beneficial to reorder/categorize the style elements into more than just color/style categories.
• Currently, switching styles/tabs will cause unsaved style changes to be discarded. It may be useful to add a warning popup beforehand.
• This likely makes the existing Edit Style button redundant, could be removed or repurposed to something like Open Style Folder.

Additional feedback would be appreciated!

Images

[tpecholt]

Hi. As for the missing include for gcc-14 that's a real issue thanks for reporting it. But instead of adding <algorithm> to imrad.h I rewrote the single std::find call with a loop. <algorithm> is known for slow compile times since the committee added ranges into it so I think it's better to avoid it.

[tpecholt]

As for the style editor I get your points. Currently if you edit the variables in an external editor and save it it will not automatically refresh until you reselect the style from the combo. That should be improved. But adding style editor as a third tab doesn't feel like the right thing to me.

Firstly properties and event tabs relate to the selected widgets but the style tab relates to the whole window and windows in other files as well since the styles are shared. So it shouldn't be edited from the same panel. For the same reason global style implementation should not go into UINode class.

Secondly the INI file style description contains other important sections like fonts definition which allows for font merging and other settings and I am not convinced editing it in a tabular form is an improvement over editing the INI file directly.

Perhaps better and simpler solution would be if ImRAD can watch for INI file change and reload the style automatically. It already does something similar for the source code change although that is less interactive than the style change should be.

[undisassemble]

That's fair. I looked into other places to put the UI (namely a popup similar to the settings button) and found a tab to be the best option, though I agree it's not ideal and does not fit with the other tabs. Closing this PR now, cheers!