<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello together,</p>
<p>thank you for pointing out your ideas!</p>
<p>I am currently working on ibreoffice/vcl/unx/gtk3/gtkframe.cxx.</p>
<p>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.</p>
<p>So, so turned to compile_commands.json:</p>
<p>FYI I use the workspace file that is provided when compiling LO.<br>
</p>
<p>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: <a class="moz-txt-link-freetext" href="https://pastebin.com/7DTibHqJ">https://pastebin.com/7DTibHqJ</a>.</p>
<p>The interesting thing I can see from this entry are the following
ones (ordered in order shown in the entry):</p>
<ul>
<li>-isystem /usr/include/gtk-3.0</li>
<li>-isystem /usr/include/gtk-3.0</li>
<li>-isystem /usr/local/include/gtk-4.0</li>
</ul>
<p>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?</p>
<p>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.</p>
<p>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
<a class="moz-txt-link-freetext" href="https://pastebin.com/8YXL1h8E">https://pastebin.com/8YXL1h8E</a>; 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!<br>
</p>
<p><br>
</p>
<p>Kind regards,</p>
<p>Christian<br>
</p>
<div class="moz-cite-prefix">On 13.12.21 11:31, Christian Lohmaier
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOPHaVSjdp6x4J9CG0Xr+c+5PiJx0VojdZZN7-b6beHqchRWkw@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi *,
On Sat, Dec 11, 2021 at 3:41 PM Christian Ohrfandl
<a class="moz-txt-link-rfc2396E" href="mailto:christian.ohrfandl@gmail.com"><christian.ohrfandl@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Hi
tl;dr see the discussion I created here
<a class="moz-txt-link-freetext" href="https://github.com/microsoft/vscode-cpptools/discussions/8523">https://github.com/microsoft/vscode-cpptools/discussions/8523</a>.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
disclaimer: didn't read that yet :-)
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">[…]
So where does the vscode-cpptools know the GTK version from and
therefore is able to judge `GTK_CHECK_VERSION(4,0,0)`?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
}
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">[…]
"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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Cannot really help with that.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Can you help me out or is it a bug that IntelliSense does not work EVEN
if the "dim inactive regions" option is disabled?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
</body>
</html>