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.

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?

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.

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"

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)

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:

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

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."

Right, the Build Now action is present on https://build.kde.org/job/Administration/job/Dependency%20Build%20KDevelop%20kf5-qt5%20SUSEQt5.14/ when I'm logged in. Thank you.

There is a similar simpler review request here: https://git.reviewboard.kde.org/r/126856/diff/3#index_header
It was already reviewed by Milian Wolff. Feel free to pick anything useful from the old review diff into this one.

Rebasing on master.

Rebasing on master.

By the way, is building with QtWebKit supported if there are both QtWebKit and QtWebEngine installed? I had to change CMakeLits.txt to force-use QtWebKit:

-find_package(Qt5WebEngineWidgets)
-if(TARGET Qt5::WebEngineWidgets)
+#find_package(Qt5WebEngineWidgets)
+if(0)

Note that there are other recent regressions with both QtWebKit and QtWebEngine implementations.

This branch is based on a very old KDevPlatform revision. There are conflicts when rebasing on master. Should I rebase on master and update this review request? Or maybe rebase on some other branch?

• Minor cleanup

• Replace qCWarningS with Q_ASSERTs

Improve Ctrl+0 shortcut support, address review comments

In D3040#88407, @rjvbb wrote:

I guess that depends on the exact way you implement it, but I would assume that it should be possible to do it in such a way that the action applies only to the focussed widget. After all, the "Close" action doesn't close all widgets either, just the one that has focus.

In D3040#88399, @rjvbb wrote:

Wouldn't it be possible to define an application-wide "Reset Zoom" (or "Zoom 100%") action with a shortcut that can be configured via the usual mechanism? That way you wouldn't have to jump through hoops in your code, and the action would (ultimately) become available in the other contexts where it would be most welcome.

I guess everyone is OK with Ctrl+0 working only when the documentation widget has focus. This widget actually gets focus on scrolling, even though individual windows on my system don't get focus in such cases. So this should not be a problem.

Address review comments

ZoomController class serves two purposes:

1. Separates generic scaling/zoom logic from the unrelated StandardDocumentationView logic. If I had placed zoom logic (complete with storing to KConfig) into StandardDocumentationView.cpp, it would occupy more than a half of that file!
2. ZoomController class can be easily reused in another similar situation instead of duplicating generic scaling/storing logic.

Eliminate documentation zoom context menu actions

Eliminate documentation zoom context menu actions

In D3040#56430, @apol wrote:

Wouldn't it be better just to allow the documentation view to change size with ctrl+mouse wheel or ctrl+'+'?

I really don't see why we need all of this.

D2902 does not fix the original issue for me because I want larger font size for documentation, and my system default is too small.
Maybe it works well in Plasma, but not in XFCE and possibly some other environments.
Being able to increase/decrease documentation scale can be a useful feature in many use-cases.

Screenshots:

I tried to allow configuring documentation zoom actions shortcuts: