Gi sci methods #935
Gi sci methods #935
Conversation
The scintilla_object_* functions are handled specially by g-ir-scanner and enable calling them as object methods for ScintillaObject (in GI using code).
|
See https://github.com/kugel-/peasy/blob/master/plugins/modeline.py#L130 for an example |
The script parses sciwrappers.c and outputs scintilla_object_* functions calling the respective sci_* function. The scintilla_object_* ones are going to be scanned for gobject-introspection and are automatically detected as true object methods. configure checks for pycparser accordingly and travis should be fine too.
scimethods, generated by gen-sci-methods.py, contains the scintilla_object functions which just wrap sci_* functions. The wrapper have to exist to work properly with gobject-introspection.
geany-scintilla-gtkdoc.h contains all scintilla_object_* methods. It is intended that they are going to be exposed through a separate .gir file, therefore a separate header makes things easier.
|
Travis is on Ubuntu 12.04, while pycparser is available in 14.04 and later. How we can resolve this? |
|
If pycparser as a build dependency is not an option currently let me suggest to simply check the generated scimethods.c in for a few releases. |
|
I don't like the idea of generating a source file to create alias symbols, just because the GIR generator tool can't be properly told to put those as methods of the object. Can't you, instead of actually adding the symbols, trick the tool to understand what you want? Basically, rename the symbols it parses, and then fix them back in the output so they refer the actual name. Maybe something roughly around those lines: TEMP_HEADER=geany-gtkdoc-sciobjected.h
sed 's/sci_/scintilla_object_/' geany-gtkdoc.h > $TEMP_HEADER
g-ir-scanner ... $TEMP_HEADER
sed 's/cname="scintilla_object_/cname="sci_/' -i Geany-1.0.gir |
Do you really need another tool to parse the C code? Isn't the Doxygen stuff enough, as it's already used to generate some C header? |
|
Am 06.03.2016 um 16:14 schrieb Colomban Wendling:
I'd like to treat the .gir like a black box as far as possible because I also don't want to lose access to the actual sci_* functions.
Might be doable with the doxygen too. The problem with a doxygen-based Also, pycparser was quicker for me since the release is so soon. If we can agree on shipping the symbols then I'd suggest to actually Best regards. |
I don't consider the format possible instability (which is rather theoretical as there are more than one tool that deal with it, so it's unlikely to change enough to break much things) not really a reason enough to drop in what I see as useless symbols. And that we should maintain either manually or trusting a generation script that will parse C to generate actual code in the library. And as a proof of concept, although it's indeed somewhat hacky, I successfully generated what looks like a proper GIR simply replacing a few symbols before and after: https://gist.github.com/b4n/75806eaaa87f3b0990a7
Fair point.
Possibly, but I really would rather avoid that. |
This PR implements generation of scintilla_object_* wrappers for each exported sci_* function. The intention is that scintilla_object_* can be used as true object methods for GeanyScintilla.
e.g. python: text = sci.get_text() instead of text = Geany.sci_get_text(sci)