https://bugs.kde.org/show_bug.cgi?id=384880
Simon Andric changed:
What|Removed |Added
CC||simonandr...@gmail.com
--
You are receiving thi
https://bugs.kde.org/show_bug.cgi?id=384880
RJVB changed:
What|Removed |Added
See Also||https://bugs.kde.org/show_b
|
https://bugs.kde.org/show_bug.cgi?id=384880
RJVB changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
Resolution|WORKSFORME
https://bugs.kde.org/show_bug.cgi?id=384880
RJVB changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #16 from Sven Brauch ---
Well, we do distribute the AppImage for a reason.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #15 from RJVB ---
FWIW, none of my former employers (national scientific research institutions)
would buy software from vendors with that kind of attitude.
I'll propose the approach upstream and probably the lock too. But I'm not going
to a
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #14 from Milian Wolff ---
Yes.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=384880
Sven Brauch changed:
What|Removed |Added
CC||m...@svenbrauch.de
--- Comment #13 from Sven Brau
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #12 from RJVB ---
> Why not push that into KDirWatch to get the efficient lookup everywhere, not
> just in KDevelop?
And then what, let everyone who doesn't have the latest frameworks version
stick with the non-optimised version?
--
You
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #11 from Milian Wolff ---
If you want to have it reviewed, put it up on phabricator - attaching it here
isn't helping anyone and just wastes our time.
Regarding QSet (without reading the code): Why not push that into KDirWatch to
get the ef
https://bugs.kde.org/show_bug.cgi?id=384880
RJVB changed:
What|Removed |Added
Attachment #108017|0 |1
is obsolete||
---
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #9 from RJVB ---
Created attachment 108017
--> https://bugs.kde.org/attachment.cgi?id=108017&action=edit
on-demand set-up of dir-only dirwatching
This is a PoC implementation of my idea of deferring the dirwatcher feeding to
the worker th
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #8 from RJVB ---
Either way, KDirWatch *is* that old. Most code in it was last touched during a
Jenkins commit in 2013 (transition to KF5?). Some work has been done on it
recently but still it too checks each and every entry being added agai
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #7 from Milian Wolff ---
I didn't mean I write KDirWatch, only the usage of that API in KDevelop is
mostly my code nowadays. Still, I think I wrote that 5-7 years ago or so, while
it was still only part of the generic manager.
--
You are r
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #6 from RJVB ---
I see that KDirWatch was first written in '98. If you wrote this code that long
ago too, then it's probably past due that someone looks at it...
And the same can evidently be said about "well-preserved" APIs in Qt. Funny,
r
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #5 from Milian Wolff ---
a) if my memory serves me right (I've written this a long time ago), I think
the WatchFiles there may have been required to get notified about file deletion
events. Anyhow, I agree that this needs to be improved some
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #4 from RJVB ---
Created attachment 107916
--> https://bugs.kde.org/attachment.cgi?id=107916&action=edit
profiling overview on Mac, dirwatcher destruction
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #3 from RJVB ---
Created attachment 107915
--> https://bugs.kde.org/attachment.cgi?id=107915&action=edit
profiling overview on Mac, dirwatcher creation
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #2 from RJVB ---
If CMakeLists.txt files are to be monitored that should be an additional action
taken by the CMake project manager, not by a generic file manager. And that was
once necessary it should not be removed until support for older
https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #1 from Milian Wolff ---
Thanks for creating this report so we can track this properly.
Some notes:
a)
- kdev should only watch directories, CMakeLists.txt files and open files for
changes
- the CMakeLists.txt used to be required, now that
20 matches
Mail list logo
