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.