Scintilla for ImGui

[emoon]

I wonder if there would be any interest in supporting Scintilla http://www.scintilla.org in ImGui. It would likely need to be some form of optional component as it's fairly big.

From my understand is that it's fairly abstracted and can have several backend implementations so this would be a quite advanced text control for ImGui.

[ocornut]

Having looked briefly my understanding it that it would be more a case of adding an ImGui backend for Scintilla ? aka porting porting Scintilla to a new "platform".

Also those two components for wxWidgets are probably good additional references
http://wxcode.sourceforge.net/showcomp.php?name=wxStEdit
http://wxcode.sourceforge.net/showcomp.php?name=wxScintilla
Second one looks more modern (184 KB of code though, ouch)

I might investigate more in the future but this looks like a fairly large piece of work and may be rather low in the priority list.

[emoon]

Yeah that is correct. It would be porting Scintilla to a new "platform" and yes it requires quite a bit of code.

Looking at http://svn.code.sf.net/p/wxcode/code/trunk/wxCode/components/wxscintilla/src/wxscintilla.cpp it looks like a big chunk of it is boiler-plate code doing SendMsg(...)

But needs work indeed.

I wonder how one would go about implementing it for ImGui. I guess ImGui would need to expose quite a bit more things in order for this to work (rendering of various primitives, etc)

[emoon]

Just a small note:

https://github.com/Gargaj/ScintillaGL

It seems that someone has ported it to OpenGL which would likely save quite a bit of work brining it to ImGui.

Most code is in here:

https://github.com/twinshadow/ScintillaGL/blob/master/Demo/ScPlatform.cxx

I have yet to test how well it works but if one only needs to implement that it doesn't look too bad.

[ocornut]

ImGui::GetWindowDrawList() allows you to render primitives but it may or not be totally suited. But yes I imagine it may requires ImGui it expose some more stuff.

[emoon]

Just managed to build the ScintillaGL code after some fixes and this is how it looks:

[emoon]

Alright. Good to know.

[emoon]

I'm going a head and implementing this but the rendering will likely use bgfx directly just to bring it up and running. That would at least give an idea of what's needed for a full implementation inside ImGui later on.

[ocornut]

Nice!

[emoon]

Just want some design ideas for this.

The way the underlying Scintilla code works is that it's based on sending messages.

Like this

SendCommand(SCI_ADDTEXT, textSize, text);
SendCommand(SCI_SETREADONLY, 1);
SendCommand(SCI_SETLEXER, SCLEX_CPP);
...

It's a bit hard to diverge from this and I wonder how to implement this in a good way for ImGui. One way would be something like this (untested)

ScEditorInterface* interface = 0;

ImGui::ScEditor(..., &interface, &myCallbacks); // myCallbacks gets call with messages from the editor

interface->SendCommand(...); // Send stuff to the editor

What I don't like of this approach is that it breaks the "statelessness" of ImGui. As for example

SendCommand(ADD_TEXT, ...);

Should only be sent when text is changed which means the app needs to track when it needs to be changed or not.

Suggestions?

[emoon]

Some more details about this:

https://github.com/emoon/ProDBG/blob/master/src/prodbg/ui/imgui_extra.inl#L117

This is how I create the Scintilla widget that is being used in ImGui. Because of the way Scintilla works you don't want to re-create this every frame because that would be expensive (and not likely work correctly)

So I cache it in the Storage section so I don't need to recreate it.

Now once we have the control the Scintilla code support many message you can send to it (set text, style, line, etc, etc)

And my question is how one should expose that from ImGui? That is why I suggested the idea above.

Does that make sense?

[ocornut]

Should only be sent when text is changed which means the app needs to track when it needs to be changed or not.

So you mean that the application needs to send those commands to the underlying Scintilla editor. Is your problem that you don't know what is a neat way to send the initial setup messages? or the subsequent "application/user is doing something" messages?

Your idea above sounds fine, I suppose lots of those messages are the responsibility of the application. The ImGui::ScEditor function could maybe send some of those messages for you. Does ADD_TEXT means "add the initial/current blob of text" or "keyboard input happened", or both? For the later this is the sort of thing the ImGui-side function could perhaps do for the user.

(
You have such a complex widget here you might even need to ask the user to do things in a certain order eventually. Like perhaps you want ScEditor() to only do the creation and placement, and the returned interface has a ->Draw() function that the user needs to call after some initial setup is done (so you don't have a 1-frame lag). Not ideal obviously but I imagine you may run into this sort of thing.
)

May not be a really useful answer, I'm still confused about the nature of the interactions involved here. But your initial approach sounds ok.

[emoon]

As you say both initial and user doing something is my problem here.

Because that the Scintilla code supports lots of things you can do during setup (themes, text, layout, etc, etc) it becomes a bit troublesome to put all these settings inside a struct/input params.

Yeah I thought about having it return an Interface also as otherwise you would get a frame lag.

I think that is almost the way to go. I think it may be a good trade-off and if the user want a "advanced edit" control with all the features I guess it may be ok to require a bit more from the user.

[ocornut]

Sounds good. When that's working and stable I suppose it could be revisited. I wouldn't suggest to try to wrap it all in a big data structure just to preserve the "one call" habit.

[emoon]

Agreed. I think it would be even more troublesome for the application to setup one big struct instead of providing an interface that can use the SendCommand(...) style and just do the calls needed.