Superseded by https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/466.

From https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html:

The generated source file will be added to the variable with the name <sources_var_name>. If the given argument is a target though, instead both the generated header file and the generated source file will be added to the target as private sources (since 5.80). The target must not be an alias.

Doesn't seem to be relevant anymore.

The replacement merge request was just merged into release/22.04. Therefore this review is obsolete and should be abandoned.

Created the text/x-objc++src merge request here: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/158. But no one has even commented on it in 1.5 months. The maintainers of shared-mime-info don't review merge requests regularly lately.

@mswan, there is renewed interest in these fixes: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/277. But we no longer use Phabricator for code reviews. Would you like to convert this review into a merge request at KDE's GitLab instance yourself? Or let someone else do that?

Well, that's what I get for trusting my memory, I didn't even realise at first that you'd been jumping on a PR that I started. :-/

In D15532#678830, @rjvbb wrote:

Is text/x-objc++src the canonical name used in macOS or is there some other reason to select one of these names?

No idea to be honest, nor how I'd figure that out...

In D15532#678830, @rjvbb wrote:

Theoretically, Objective-C headers could be detected with #import magic, but that wouldn't be reliable, because Objective-C headers can start with a comment or with #include, which share C's syntax. So I am inclined to remove the references to text/x-objchdr from KDevelop.

I'm pretty certain I have a patch that improves ObjC support in KDevelop, and also that I put it up for review at some point. Maybe it was never incorporated because of the mime info not being in the mimeinfo database, I can't remember.

Here is your patch: D15530. One of your comments in that review is:

Removed the x-objchdr mimetype (to avoid additional confusion what a .h file could be) and added my current x-objc+src definition to kdevclang.xml .

This comment sort of resigns to remove mentions of x-objchdr from KDevelop's code.

Could you please cancel that email and paste its contents in a Phabricator comment?

In D15532#678827, @rjvbb wrote:

In the reply I thought I sent yesterday (it got held up for moderation for the kdevelop-devel ML; I assumed it was delivered to the other "reply-all" destinations):

René J.V. Bertin wrote on 20211009::22:00:04 re: "Re: D15532: [Astyle] Add Objective C to list of languages with formatters"

Igor Kushnir wrote on 20211011::17:30:08 re: "D15532: [Astyle] Add Objective C to list of languages with formatters"

In D15532#678825, @rjvbb wrote:

4. Will create a KDevelop merge request that removes all mentions of text/x-objchdr.

I already indicated why I think that's not a good idea (but I can always just patch it back)

Igor Kushnir wrote on 20211011::12:38:18 re: "D15532: [Astyle] Add Objective C to list of languages with formatters"

If no one has objections or suggestions on this topic, I am going to create a shared-mime-info merge request tomorrow: this patch plus tests

I would like to eliminate the following warnings from KDevelop's output:

Update for those watching: I have just posted a new version of the script to Invent which uses vswhere.exe to locate the installed versions of Visual Studio. I'll be abandoning this revision since IMO vswhere is the best way forward. Check it out here: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/259

In D18758#678707, @apol wrote:

Let's abandon it, I'd be wary of bringing in such a big dependency into our codebase just like that.

In D18758#678706, @arrowd wrote:

So, do we want to get this in?

Short recap:

• Project::open() executes KIO jobs synchronously at the moment.
• To make the code asynchronous we need some 3rd-party library implementing futures, like QtPromise.
• The original bug that made me work on this is fixed already.
  
  Should we abandon this?

So, do we want to get this in?

Indeed, that must have slipped me at the time. Will not wait for the next Monday now ;)

@kossebau Can this now be closed?

yes, I guess if you open a project that uses that in qtcreator, you also wouldn't be able to open the debug.h header then

ecm_qt_declare_logging_category adds only the debug.cpp file, but not the debug.h file. Is this a bug in ECM?

Generated files should usually be added to the corresponding cmake target - if you don't then yes they won't show up after filtering the build dir (or when using a totally different path for the build dir).

I just noticed that when the build directory is filtered out, auto-generated headers, like build/app/debug.h do not appear in the Quick Open list. Apparently these headers are not pulled in by CMake targets. I think that losing these particular headers is not a big deal. But could this filtering remove more useful files from the list and the project tree? I guess not - because the auto-generated files in the build directory are not supposed to be edited and should usually be uninteresting.

From https://community.kde.org/Infrastructure/GitLab: "Task management is transitioning to Invent/GitLab but most projects still use https://phabricator.kde.org for now."

AFAIK, Phabricator is being retired in favor of GitLab. Why not create an issue there? https://invent.kde.org/kdevelop/kdevelop/-/issues

What is missing:

• Declaration with alias into grouped namespace are not processed: use Foo\ { const C as FooC };
• There is no test
• The mix between UseImportType, ParserUseImportType, DeclarationType is not clean

Or anything directly in the zone of the active coding, like the konsole and code browser, to retain its active and focused status.

Maybe have a couple of panels take precedent like the project tab in use and anything vertical of the zone, breaking off any lateral distraction.

Better? It is using the active but unfocused color. It leads me to a question, how is what known to be active and focused, on my crappy mock up is seems rather arbitrary.

Yeah... Maybe use the lighter hover blue from other mock ups in sections that aren't focused on, like if I'm using the left panel I expect the UI to focus on the panels interface and not have the screaming deep blue in other sections. It's 3am so I'll sketch it up tomorrow and see how it turns out.

Seeing a main window with several tab bars (some toolviews, some multi-document views) makes me feel like there's too much blue. I feel like my eyes are being pulled in multiple directions.

Updated. check images on description.

Yeah, I've been intrigued as what to do with it. Since this mock up is a straight rip off of @manueljlin I didn't give it much thought but now that I'm setting which styles are for what and where I need to update them.

I'm noticing that we have two tab styles here which do not appear to be used consistently:

Edit: Will update tab style to use full area.

In D17908#674690, @Petross404 wrote:

Is vswhere included when VS is installed? Unless the user explicity installs it, it shouldn't exist. Am I wrong here?

In D17908#674686, @sredman wrote:

I suspect it's not necessary to ship with KDevelop: Either Visual Studio >= 2017 is installed, in which case the vswhere tool should be on the path, or VS is not installed, in which case the tool wouldn't do us any good.

I have installed Build Tools for VS2019 and the installation is at

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools

I found this string inside HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\1eb19443 which honestly doesn't seem the proper key to extract this value but anyway.

In D17908#674685, @Petross404 wrote:

Do we want to ship this with KDevelop? So that the .bat script can rely on this utility?

In D17908#492410, @sredman wrote:

Actually, a pleasant surprise for today is that this whole mess of registry keys and environment variables is mostly unnecessary as of VS 2017, since Microsoft provides a tool which does all the locating work for us: https://github.com/microsoft/vswhere

The test output:

2: FAIL!  : Php::TestDUChain::classMemberVar() 'var->type<IntegralType>()' returned FALSE. ()
2:    Loc: [/home/hmitonneau/kde/src/kdev-php/duchain/tests/duchain.cpp(449)]

I had a look at this again. Updated to latest master of both kdevelop and kdev-php just to make sure I didn't miss a commit in kdevelop that might have influenced this, but my tests still pass just fine. Furthermore, I don't see what your patch would fix. The change you made is in a code-path that's unaffected by property types, and if there is a crash there it should've triggered just the same before the change.

In D29444#663891, @zhigalin wrote:

Are the trailing commas from T6804 supported?

Are the trailing commas from T6804 supported?

https://invent.kde.org/kde/kdevelop/-/commit/66253c6df81fb29f60df5f88e30dc29f57cdb36e

Where?

I've now pushed another patch which will suspend TUs to reduce memory consumption further.

I've been addressing issues related to controller proxy instances surviving too long during shutdown and accessing stale memory.

I have compiled from scratch with kdesrc-build (with cmake-options -DCMAKE_BUILD_TYPE=RelWithDebInfo). The duchain test still doesn't pass.
After some debug, it seems that m_gotTypeFromTypeHint is not always initialized correctly.
The following patch fix the problem for me:

Don't just stop parsing files when shutting down, also ignore new document add requests.

Updated and improved version:

• the registration with the ProcessController is done "JIT", just before enqueing the first document for actual parsing
• keep track of documents via the QUrls of IndexedStrings

Hmm, this is odd.

Sorry for the very late comment...
Before this commit, the type of properties were deduced from the assign default value:

Pushed in commit 4097c98f90020f4cf9990a0cf472fd5d34ff970f

This addresses a few issues, notably by using a queued signal to trigger url (un)registering from the requesting (weaver) thread in the thread where the JobController lives too.

https://invent.kde.org/kde/kdevelop/-/merge_requests/114

I have started updating some of the photos and some text changes. I am really looking over what is there and what can be improved where.

Following https://cgit.kde.org/kdev-css.git/log/parser/CMakeLists.txt, it should fix Windows build and not fail Linux one

Our discussion is about when to create the preamble for open documents. If I were to stop that job, I wouldn't get the AST, but I want the AST. I just don't want the preamble before I've started editing the file.

In D18551#623098, @rjvbb wrote:

As I said, I thought the possibility to cancel jobs could be a comprise (I don't get the impression you've been able to find one yet), but OK.