Updated TextEdit widget

[SinsofSloth]

• Fixed a lot of bugs with base code
  • Should be no bugs??
• Smart detection
• Shortcut to pull menu via ctrl+e
  • Use to pullup appropiate list for args since it won't pull up entire list when typing normally
• Dynamic menu (currently only a PoC with SetSpeaker() and NewSpeaker())

To-Do/Possible Features:

• Implement lists:
  • Emotions
  • Track
  • ?? Static int range for certain functions like Reposition()
• Remove case sensitivity but would have to check the prefix string to verify it

[SinsofSloth]

👀 I'll create a key/value for this. Should this be in JSON format or... Also, what are your thoughts on the color highlighting syntax, the syntax in general for the commands? Anything in mind? This is just an example.

[thane98]

Wow, that's looking awesome!

I think storing it in JSON would be a good idea. I'd prefer to keep text data like that out of code when possible.

[thane98]

For colors, what you have looks great. Might need a different set of colors for dark theme, but we'll cross that bridge later.

[SinsofSloth]

Just missing hints for $VisualEffect, $DramaticMusic, $CutsceneAction, $Color, $nl. I also threw the key/value in Modules\ServiceData\; not sure if that's appropiate, but just tell where it's not, so I can move it.

[thane98]

I wouldn't worry about those for now - that should be enough to get things started. The rewrite adds in some extra commands from Awakening and Echoes, so this will have to be expanded in the future anyways.

[SinsofSloth]

I'll just leave it blank then. The dark theme should use the same white bg tooltip, so dark theme shouldn't be a problem unless restyling it to give it the dark theme feel.

[SinsofSloth]

Last GUI update: we reached low level code editor IDE

Because SoV and Awakening will use different commands (or at least new ones), I'll make this current widget into a template class so it's inheritable and put it in ui/widgets

[SinsofSloth]

So, the character list in the conversation editor syncs up with edits in the parent window (character editor). But for other services, their abstraction is just lacking one thing--if they have an editor to watch the active editors. I just set conditionals for this, but I was wondering if the services has been reworked/updated, so I can design in accordance with the update.

[thane98]

I recently added a rewrite branch with the new code if you want to look at it, though what you have here is fine either way. Especially for things like the character and emotion lists, the dialogue service has methods for getting these. They may need some optimization so the lists don’t get rebuilt constantly, but that’s not something the UI should have to worry about.

I wouldn’t worry about what the parent window is doing - at least not in the rewrite. Is this needed outside of generating the character suggestions?

[SinsofSloth]

I should have clarified what the problem is; the problem is that changes in the character editor only sync up with it's child window. Other instances of the services (i.e chapter editor, generic conv) do not sync up with the changes of the character editor when active.

Edit: I looked at the rewrite branch, and AAH it looks good! I'll rebase and give an update later.

[SinsofSloth]

Closing as move changes to here