In D8208#591704, @ngraham wrote:

@fvogt "test.foo" becoming "test.foo copy" is intentional because .foo isn't a known valid extension, and it's valid for files to have dots in their names. In general the approach of using QMimeDatabase supports this, solves the problems of using QFileInfo that @pino pointed out, and also allows seamless support for filename extensions with two dots in them (e.g. tar.gz).

If I go back to using QFileInfo to chop up the file into filename + extension, then there's the difficult choice of what kind of file to fail on: If I use QFileInfo::suffix(), it will fail for extensions with two dots like .tar.gz; if I use QFileInfo::completeSuffix(), that fails for files with dots in their names outside of the extension.

Each approach has drawbacks. Which would you find acceptable?

If merging would clash then it's the recipe/package maintainer to clarify merging rules.
So yeah, by example by blacklisting some files.

I'm a bit surprised by all the bad comments concerning an useful feature.
Are you taking people for dumbs that can not understand duplicate would
copy/paste in one go in the source location? macOS has such feature for
years and nobody comes complaining disk would have failed. Also, it does
not mean people will use it many times per day. I personally use duplicate
feature a lot and really miss it from dolphin.

Better length checking.

Also check the socket file path length now

Removed the tmp name approach

Better mac os cmake code

To which branch should I rebase this change ?

In D19983#437962, @cfeck wrote:

Bug 401692?

Dropped reference to previous patch

Rework patches so they apply only on macOS

In D19982#437917, @dvratil wrote:

Would it make sense to think about Kontact on Mac in the terms of a singular bundle, similar to Kontact Flatpak/Appimage, and take a completely different approach in packaging Kontact for Mac?

Hm indeed, this would have to be tested from a windows user as well.
I did tested it on mac os and it works fine, akonadi resources can show their UI when requested.
Please add a widows reviewer if possible, i would not be able to test that on my own.

Works for me !

Confirmed working !

Unfortunately, no qmake does not provide that info AFAIK.

LGTM, did not checked though, in my opinion the minimal supported version should be the minimum target supported by Qt itself because most of the libs here are built mainly as dependencies for Qt / KDE apps, and settings something other than what Qt expect would not be good.

Ok, will wait the distro upgrade to latest upstream version then come back with new informations.

My distro is KaOS, which have Kube 0.6.0.
Screenshot:

Ok, I take note about the labels unsupported.
F5 is of course one of the shortcut I tested, without luck :/
Any idea on how i can produce something useful to attach to this bug report ?

Just saw this updated review - please see my comments in https://phabricator.kde.org/D8206.
Duplicate feature is something very interesting that i would like to see as well available in dolphin.
It's extremely useful for people to create copy so they can safety works on original and not using a version system like git or svn.
To be useful, the feature has to be able to operate on files and folders with one or many selected items in a passive way (ie, don't ask for user a file name).
Please, note that some people don't care of such feature because they don't need it, it does not mean that it is not useful for a lot of other people.

By the way, you can abandon again this one, the correct review is https://phabricator.kde.org/D8208

I personally would prefer this not go in craft for many reason:

• Some homebrew packages are specificly built for a partilar macos version
• Some homebrew packages might depends other hombrew libraries, making hard to handle the complete dependency tracking for create stand alone package
• I alreayd started work to make craft agnostic of homebrew (or anything like it) - ie, adding support for pkg config, cmake, bison, flex..., and low level libraries, see https://github.com/pasnox/craft-blueprints-kde/commits/master

My patches may require some small refactoring, but coupled with hanna in progress package overriding, it will then be extremely easy to build kde for mac without any external dependency, reducing complexity and dependency tracking of externals artifacts.
I would then prefer we continue to correctly polish the on going work, and don't rely on such package manager.