User Details
- User Since
- Sep 22 2016, 5:18 PM (395 w, 6 d)
- Availability
- Available
Jul 22 2023
Dec 18 2022
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.
May 3 2022
The replacement merge request was just merged into release/22.04. Therefore this review is obsolete and should be abandoned.
Nov 27 2021
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.
Oct 31 2021
@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?
Oct 12 2021
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.
Oct 11 2021
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
Oct 9 2021
I would like to eliminate the following warnings from KDevelop's output:
Nov 4 2020
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.
Oct 19 2020
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."
Oct 18 2020
Oct 7 2020
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.
May 20 2020
May 18 2020
May 2 2020
Apr 21 2020
Mar 30 2020
Mar 29 2020
Mar 28 2020
Jan 17 2019
Aug 2 2017
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.
Mar 24 2017
Rebasing on master.
Rebasing on master.
Mar 22 2017
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?
Mar 19 2017
- Minor cleanup
Mar 8 2017
- Replace qCWarningS with Q_ASSERTs
Feb 25 2017
Improve Ctrl+0 shortcut support, address review comments
Feb 22 2017
Feb 21 2017
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.
Feb 19 2017
Address review comments
Oct 17 2016
ZoomController class serves two purposes:
- 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!
- ZoomController class can be easily reused in another similar situation instead of duplicating generic scaling/storing logic.
Oct 16 2016
Eliminate documentation zoom context menu actions
Eliminate documentation zoom context menu actions
Oct 13 2016
Oct 12 2016
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: