- User Since
- Jan 30 2018, 10:27 AM (73 w, 3 h)
Fri, Jun 21
Thu, Jun 13
Tue, Jun 11
Better length checking.
Also check the socket file path length now
Removed the tmp name approach
Fri, Jun 7
May 24 2019
May 21 2019
May 20 2019
May 7 2019
May 6 2019
Better mac os cmake code
To which branch should I rebase this change ?
Mar 25 2019
Dropped reference to previous patch
Rework patches so they apply only on macOS
Mar 24 2019
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.
Mar 22 2019
Mar 8 2019
Mar 6 2019
Mar 4 2019
Works for me !
Sep 15 2018
Confirmed working !
Sep 9 2018
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.
Aug 16 2018
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.
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 ?
Apr 22 2018
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
Mar 22 2018
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.