Hello together,
thank you for pointing out your ideas!
I am currently working on ibreoffice/vcl/unx/gtk3/gtkframe.cxx.
As for the 'vscode/c_cpp_properties.json' file: If I delete the gtk-3.0 line entirely and restart VS Code, nothing changes; so I guess that - as Christian pointed out - the include paths of c_cpp_properties.json are indeed a fallback that do not get used because there is the corresponding entry in compile_commands.json.
So, so turned to compile_commands.json:
FYI I use the workspace file that is provided when compiling LO.
So I rebuilt compile_commands.json and searched for the file that I am currently editing and having problems with (libreoffice/vcl/unx/gtk3/gtkframe.cxx); you can find the entry here: https://pastebin.com/7DTibHqJ.
The interesting thing I can see from this entry are the following ones (ordered in order shown in the entry):
- -isystem /usr/include/gtk-3.0
- -isystem /usr/include/gtk-3.0
- -isystem /usr/local/include/gtk-4.0
So yes, the gtk-3.0 entry is doubled AND - what is probably more interesting - is that there is the gtk-4.0 entry in there aswell AND the gtk-4.0 entry comes after the gtk-3.0 entries. May it be the problem that the gtk-4.0 entry comes after the gtk-3.0 entries in the json entry?
As for the vcl plugin: I seem to be building both gtk-3.0 and gtk-4.0 versions; both 'instdir/program/libvclplug_gtk3lo.so' and 'instdir/program/libvclplug_gtk4lo.so' are present.
So after adding '--disable-gtk3' to 'autogen.input' - as M.
Weghorn pointed out - and recompiling compile_comands.json, the
entry in compile_commands.json for
libreoffice/vcl/unx/gtk3/gtkframe.cxx changes to
https://pastebin.com/8YXL1h8E; so no gtk-3.0 entries in there
anymore. I was also able to build LO again successfully. And -
finally - this also solved the problem of VS Code dimming the
mentioned sections. So this time, the GTK check seems to be true
for > 4.0.0 and therefore, VS Code IntelliSense works as
expected!!! Thank you for helping me out on that one!
Kind regards,
Christian
Hi *, On Sat, Dec 11, 2021 at 3:41 PM Christian Ohrfandl <christian.ohrfandl@xxxxxxxxx> wrote:Hi tl;dr see the discussion I created here https://github.com/microsoft/vscode-cpptools/discussions/8523.disclaimer: didn't read that yet :-)[…] So where does the vscode-cpptools know the GTK version from and therefore is able to judge `GTK_CHECK_VERSION(4,0,0)`?All "magic" comes from the compile_commands.json file that is generated by the "make vim-ide-integration" command. That file contains the invocation from which intellisense gets the defines and header include paths. So when not using that file intellisense will fall flat and struggle to find headers, etc. Now why it picks up a wrong version: no idea, would have to look at the specific file and what the commandline is for the file.I also looked into my project's `.vscode` folder into the `c_cpp_properties.json` file and added the GTK4 library install dir `"/usr/local/include/gtk-4.0"` as follows: ``` { "configurations": [ { "name": "Linux", "includePath": [ "${default}", "/usr/local/include/gtk-4.0", "/usr/include/gtk-3.0", "/usr/include/glib-2.0", "/usr/lib/x86_64-linux-gnu/glib-2.0/include", "/usr/include/pango-1.0" ], "defines": [], "cStandard": "c17", "intelliSenseMode": "linux-clang-x64" } ], "version": 4 }So it seems you're not using the sample workspace file with the compile-commands.json it seems. Or if you do: the include paths are only the fallback in case there is no entry in the compile_commands.json file, i.e. for externals that are built as part of a LO compile.[…] "So why not turn off the feature "Dim inactive regions"?", I thought. Well, this makes the code undimmed (yay) BUT IntelliSense STILL does not work (nay), which is a major problem for me.Cannot really help with that.Can you help me out or is it a bug that IntelliSense does not work EVEN if the "dim inactive regions" option is disabled?Define "does not work" - does code completion hints for the objects not work? then it is a bug in the vscode cpp plugin/nothing LO's integration can help with... ciao Christian