Closing as kdescr-build has moved to Gitlab.

Split followDirectories option into followNewDirectories and followSelectedDirectories options. followSelectedDirectories only applies to tree views. Let me know if you want the option name to include that information.

The use case is showing a project tree view in an application where we want the root of the KDirOperator to stay fixed. The initial motivation for this change was replicating the File Explorer from Visual Studio Code (text editor) where one opens a folder and the file explorer stays fixed at that specific folder until another folder is opened. KDirOperator almost fit this use case except when creating new directories or selecting existing directories, that directory would be made the top level directory in the KDirOperator. When the new option is enabled, the top level directory stays the same when selecting directories or creating new directories which makes KDirOperator behave more like the File Explorer in Visual Studio Code.

Added default value to documentation.

Remove extra unnecessary '&'

According to the documentation they should both achieve the same effect. However, Qt::WA_OpaquePaintEvent takes precedence if both are used.

When selecting directories, only disable following directories if a tree view is used (normal or detail).

That is something I hadn't considered yet. Would it be acceptable to only apply this option when the KDirOperator is configured as a tree view?

Now, with followDirectories set to false, directories simply expand on double click which is what I wanted to achieve. The general behaviour I want to get with this change is to have a project tree view where the root folder stays fixed.

Email: daan.j.demeyer@gmail.com (added to my profile as well)

I changed the option to apply to directories that are double clicked as well. Previously, double clicking a directory would also change the listed url which now depends on whether the option is enabled. Since it applies to both new and existing directories, followDirectories seemed more apt. I'm open to other name suggestions but your suggestions seem to only consider the new directory case (perhaps you missed the added behaviour in the latest revision?).

• Address comment
• Apply option when selecting directories as well
• Rename to followDirectories

KF6 is a long time out so I'm abandoning this.

KF6 is a long time out so I'm abandoning this.

Use REQUIRED_QT_VERSION to specifiy required Qt version.

Ping

Ping

Ping

To give an example of how the addition would improve KDE CMake build scripts, let's look at part of Kate's CMake build script.

Ping

#TypeameMacros: [Q_PROPERTY] should be #TypenameMacros: [Q_PROPERTY]

Accidentally uploaded the wrong diff.

OK, thanks for the information. I'm still getting familiar with this whole process.

@alexmerry I think I added the wrong reviewer for this. I noticed your name in the git blame of k18n_wrap_ui, perhaps you know who I should add as a reviewer for ki18n revisions?

Diff to latest master as requested.

The new revision should fix the compile error

Replace leftover source list variable with an empty string.

My bad, I forgot to replace a source list variable with the empty string.
This does not cause errors on the latest CMake versions because it is now
allowed to pass no sources to an add_executable call so I didn't have any
problems locally. The issue is solved by replacing ${ProjectPluginSrc} in
addons/project/autotests/CMakeLists.txt by the empty string ("")

@cullmann I think this revision is good to merge now. I was thinking of making a second revision with the changes to the global, kwrite and kate CMake scripts to keep things a bit more manageable. However, those changes depend on this revision so ideally this revision would be merged before I make the second one. Does that sound good to you or should I add the other changes to this revision as well?

I want to keep the changes in KDE Frameworks focused on what's necessary to clean up Kate's CMake scripts. I'll leave the general cleanup for another revision.

@turbov This is exactly what I've already proposed, See https://phabricator.kde.org/D22698. I've also proposed similar patches for ecm_add_app_icon and ecm_qt_declare_logging_category (https://phabricator.kde.org/D22709, https://phabricator.kde.org/D22699)

Update CMake minimum required version to 3.1 (for target_sources).

This may be a stupid question but is the TRANSLATION_DOMAIN stuff actually used somewhere? I'm not familiar with how it works. However, I find it strange that its not defined for kwrite and kate but is defined for all plugins.

• Switched to new recommended style for multi-line commands.
• Removed escaping from TRANSLATION_DOMAIN definitions as this is done automatically by CMake.
• Added a few missing PRIVATE's and removed some extra whitespace where needed.

I

Removed the cmake_minimum_required call

I'm not sure if its beneficial to use cmake_parse_arguments here. It seems like it would make the macro harder to understand compared to the current change. I'm also not entirely sure how it would work? I haven't worked with cmake_parse_arguments before.