Robert Roessler: > You keep saying this (or close variations), but while Windows messages > and messaging are things I find easy to use, my app is using the GTK > widget version of Scintilla, and I do not really have a clear picture > of a) how async messaging would work in this environment, or b) if any > approach would work on all the platforms where GTK is nominally > supported. Besides, explicitly asynchronous control logic can be > headache-inducing (particular when not really necessary).
This is subject to the law of headache conservation. By refusing to allow reentrance in some areas of Scintilla, my potential headaches are instead pushed to you ;-) A common way to queue an asynch job on GTK+ is gtk_idle_add. See scintilla/gtk/ScintillaGTK.cxx ScintillaGTK::SetIdle for an example. For polling jobs there is gtk_timeout_add as used in SciTE. These have been deprecated in favour of g_idle_add and g_timeout_add but Scintilla is still trying to be compatible with GTK+ 1.x. http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html > OTOH, you *could* consider allowing *style* modifications to nest > (like markers) - the code (in Document::SetStyleFor() and > Document::SetStyles()) didn't look too far from being workable already > - I just am a bit unclear about how to handle endStyled. As am I and the code that tries to avoid restyling and redrawing the whole window could also cause trouble. If Scintilla had a styling cursor (endStyled) for each styling 'channel' (indicator or base styles) then this would be more tractable. But then you wouldn't really want reentrance as Scintilla could call all the stylers (one for each channel) in some order that would allow one channel to depend on the results of another. > Key to both of these, of course, is to still track enteredCount, and > be smart about issuing notifications - maybe only allow one level of > recursion, and decide to call NotifyModified a) the first time, or b) > both times, depending on how things will work with nesting (or not) > Redraw() or InvalidateRange() calls... we certainly do not want any > endless loops. :) I think implementing this as minor changes is doomed to many bugs. I'm imagining the movie version of Starship Troopers here. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
