aacid added a comment.
It's kind of harmless i guess, but when doing a rename via F2 in dolphin we
do stopDirScan on the url twice, one in CopyJobPrivate::startRenameJob and
another in CopyJobPrivate::createNextDir
that means you get the following warning
org.kde.kcoreaddons: doesn't kno
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130128/
---
(Updated May 14, 2017, 10:43 p.m.)
Status
--
This change has been ma
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130128/#review103213
---
Ship it!
Ship It!
- Aleix Pol Gonzalez
On mai. 14, 201
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130128/
---
Review request for KDE Frameworks, Aleix Pol Gonzalez and David Edmundson.
dfaure added a comment.
Yes, if this is confirmed to work we can deprecate stopDirScan/restartDirScan.
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D5856
To: dfaure, aacid
Cc: #frameworks
aacid added a comment.
Do we want to mark the "old" methods as deprecated?
Update the docu?
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D5856
To: dfaure, aacid
Cc: #frameworks
On dimanche 14 mai 2017 19:46:16 CEST Albert Astals Cid wrote:
> Should we simply mark stopDirScan as deprecated and make it call
> removeDir?
Ah, yes, that's an option.
Overall it will make things faster compared to unwanted notifications indeed.
https://phabricator.kde.org/D5856 seems to work.
dfaure created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
REVISION SUMMARY
This fixes notifications happening against our will given that inotify
is async.
TEST PLAN
copying/deleting files in dolphin still update
El dissabte, 13 de maig de 2017, a les 14:00:15 CEST, David Faure va escriure:
> On lundi 8 mai 2017 17:51:06 CEST Albert Astals Cid wrote:
> > El dilluns, 8 de maig de 2017, a les 17:32:35 CEST, David Faure va
escriure:
> > > On lundi 8 mai 2017 16:14:47 CEST Albert Astals Cid wrote:
> > > > > I
graesslin added a comment.
In https://phabricator.kde.org/D5851#109478, @davidedmundson wrote:
> It makes absolutely no sense to have a pidChanged signal and then say
clients shouldn't be using it.
>
> Either window has no reason to have a pidChanged signal or we should
connect to it
dfaure added a comment.
In that case you might want to look at the fixes I just committed for
https://bugs.kde.org/show_bug.cgi?id=208625
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D4552
To: broulik, emmanuelp, hein, dfaure
Cc: abika, #frameworks
davidedmundson added a comment.
It makes absolutely no sense to have a pidChanged signal and then say clients
shouldn't be using it.
Either window has no reason to have a pidChanged signal or we should connect
to it. It has to be one or the other.
REPOSITORY
R127 KWayland
REVISION DE
graesslin added inline comments.
INLINE COMMENTS
> plasmawindowmodel.cpp:84
>
> +QObject::connect(window, &PlasmaWindow::pidChanged, q,
> +[window, this] { this->dataChanged(window, PlasmaWindowModel::Pid); }
In the original report I critized that we connect to a pid changed signal
abika added a comment.
File preview is also used in Krusader. Please add us to subscribers for
behaviour changes. Thanks.
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D4552
To: broulik, emmanuelp, hein, dfaure
Cc: abika, #frameworks
davidedmundson created this revision.
Restricted Application added projects: Plasma on Wayland, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.
REVISION SUMMARY
Fixes https://phabricator.kde.org/D5747
TEST PLAN
Tests now pass
REPOSITORY
R127 KWayland
BRANCH
intelfx added a comment.
In https://phabricator.kde.org/D5802#109416, @mwolff wrote:
> For solarized you showed the screenshots in your original mail. I'm more
concerned about backwards compatibility with other schemes. I.e. yes - we do
care about the status quo. Can you give an example
mwolff added a comment.
For solarized you showed the screenshots in your original mail. I'm more
concerned about backwards compatibility with other schemes. I.e. yes - we do
care about the status quo. Can you give an example for a color scheme where
this would break stuff? Then I can also ap
intelfx added a comment.
In https://phabricator.kde.org/D5802#109403, @mwolff wrote:
> Hey there,
>
> sorry for the long delay. In general this sounds like a good idea. But what
do you mean by "However, just making that change will make Kate/KDevelop
incompatible with all existing co
mwolff added a comment.
Hey there,
sorry for the long delay. In general this sounds like a good idea. But what
do you mean by "However, just making that change will make Kate/KDevelop
incompatible with all existing color schemes"? Can you show some before/after
screenshots for an existi
hein added a comment.
FWIW I did run make test on an earlier revision of the patch during the
sprint while doing work on top of it; it must have regressed after.
REPOSITORY
R127 KWayland
REVISION DETAIL
https://phabricator.kde.org/D5747
To: sebas, #plasma, hein, graesslin
Cc: apol, davi
20 matches
Mail list logo
