Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-19 Thread David Faure 


> On Dec. 10, 2016, 4:36 a.m., Anthony Fieroni wrote:
> > filenamesearch/kio_filenamesearch.cpp, line 113
> > 
> >
> > Or we must keep KIO::UDSEntry::UDS_URL in new patch ?
> 
> Anthony Fieroni wrote:
> David, any suggestion? Am i on right way?

I don't know off hand. This needs serious thinking / design with full context 
in mind, which a RR doesn't really help me with.
We should do an IRC session with Emmanuel, maybe.

We solved similar issues in kio-stash recently, so assuming the purpose is 
similar in terms of what the user can do with the listed items (which is what I 
would need a design document or IRC session about), you could try 
UDS_TARGET_URL instead.
That is the URL that is opened when clicking on the file. It doesn't change the 
"structural URL", which is the one in the KDirLister tree (on the app side).

What does "view does not contain paths" mean? There is a column with the orig 
paths?

If I had time I would test and debug this myself, but there are so many other 
things to debug (some of which affect me so they get priority) :(


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101351
---


On Dec. 5, 2016, 8:04 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> (Updated Dec. 5, 2016, 8:04 p.m.)
> 
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/CMakeLists.txt 774d79e 
>   filenamesearch/filenamesearchdbusinterface.h PRE-CREATION 
>   filenamesearch/filenamesearchdbusinterface.cpp PRE-CREATION 
>   filenamesearch/kded/CMakeLists.txt 48160ed 
>   filenamesearch/kded/filenamesearchdbusadaptor.h PRE-CREATION 
>   filenamesearch/kded/filenamesearchdbusadaptor.cpp PRE-CREATION 
>   filenamesearch/kded/filenamesearchmodule.h 4fa6bb1 
>   filenamesearch/kded/filenamesearchmodule.cpp f12626d 
>   filenamesearch/kio_filenamesearch.h 0920394 
>   filenamesearch/kio_filenamesearch.cpp f124f02 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-18 Thread Anthony Fieroni 


> On Дек. 10, 2016, 6:36 преди обяд, Anthony Fieroni wrote:
> > filenamesearch/kio_filenamesearch.cpp, line 113
> > 
> >
> > Or we must keep KIO::UDSEntry::UDS_URL in new patch ?

David, any suggestion? Am i on right way?


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101351
---


On Дек. 5, 2016, 10:04 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> (Updated Дек. 5, 2016, 10:04 след обяд)
> 
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/CMakeLists.txt 774d79e 
>   filenamesearch/filenamesearchdbusinterface.h PRE-CREATION 
>   filenamesearch/filenamesearchdbusinterface.cpp PRE-CREATION 
>   filenamesearch/kded/CMakeLists.txt 48160ed 
>   filenamesearch/kded/filenamesearchdbusadaptor.h PRE-CREATION 
>   filenamesearch/kded/filenamesearchdbusadaptor.cpp PRE-CREATION 
>   filenamesearch/kded/filenamesearchmodule.h 4fa6bb1 
>   filenamesearch/kded/filenamesearchmodule.cpp f12626d 
>   filenamesearch/kio_filenamesearch.h 0920394 
>   filenamesearch/kio_filenamesearch.cpp f124f02 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-09 Thread Anthony Fieroni 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101351
---




filenamesearch/kio_filenamesearch.cpp (line 113)


Or we must keep KIO::UDSEntry::UDS_URL in new patch ?


- Anthony Fieroni


On Дек. 5, 2016, 10:04 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> (Updated Дек. 5, 2016, 10:04 след обяд)
> 
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/CMakeLists.txt 774d79e 
>   filenamesearch/filenamesearchdbusinterface.h PRE-CREATION 
>   filenamesearch/filenamesearchdbusinterface.cpp PRE-CREATION 
>   filenamesearch/kded/CMakeLists.txt 48160ed 
>   filenamesearch/kded/filenamesearchdbusadaptor.h PRE-CREATION 
>   filenamesearch/kded/filenamesearchdbusadaptor.cpp PRE-CREATION 
>   filenamesearch/kded/filenamesearchmodule.h 4fa6bb1 
>   filenamesearch/kded/filenamesearchmodule.cpp f12626d 
>   filenamesearch/kio_filenamesearch.h 0920394 
>   filenamesearch/kio_filenamesearch.cpp f124f02 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-09 Thread Anthony Fieroni 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101350
---



David, this patch has many disadvantages:
1. Search view does not contain paths anymore
2. It cannot open file from it
3. Search view rejects completely all actions

- Anthony Fieroni


On Дек. 5, 2016, 10:04 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> (Updated Дек. 5, 2016, 10:04 след обяд)
> 
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/CMakeLists.txt 774d79e 
>   filenamesearch/filenamesearchdbusinterface.h PRE-CREATION 
>   filenamesearch/filenamesearchdbusinterface.cpp PRE-CREATION 
>   filenamesearch/kded/CMakeLists.txt 48160ed 
>   filenamesearch/kded/filenamesearchdbusadaptor.h PRE-CREATION 
>   filenamesearch/kded/filenamesearchdbusadaptor.cpp PRE-CREATION 
>   filenamesearch/kded/filenamesearchmodule.h 4fa6bb1 
>   filenamesearch/kded/filenamesearchmodule.cpp f12626d 
>   filenamesearch/kio_filenamesearch.h 0920394 
>   filenamesearch/kio_filenamesearch.cpp f124f02 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-05 Thread Albert Astals Cid 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101305
---



I just saw "When is fixed new kio-extras realease is needed for 16.08 branch." 
(i understand this is 3 weeks old), but there's no more 16.08 branches, so 
commit to 16.12 or master, depending where you want it to go.

- Albert Astals Cid


On Dec. 5, 2016, 8:04 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> (Updated Dec. 5, 2016, 8:04 p.m.)
> 
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/CMakeLists.txt 774d79e 
>   filenamesearch/filenamesearchdbusinterface.h PRE-CREATION 
>   filenamesearch/filenamesearchdbusinterface.cpp PRE-CREATION 
>   filenamesearch/kded/CMakeLists.txt 48160ed 
>   filenamesearch/kded/filenamesearchdbusadaptor.h PRE-CREATION 
>   filenamesearch/kded/filenamesearchdbusadaptor.cpp PRE-CREATION 
>   filenamesearch/kded/filenamesearchmodule.h 4fa6bb1 
>   filenamesearch/kded/filenamesearchmodule.cpp f12626d 
>   filenamesearch/kio_filenamesearch.h 0920394 
>   filenamesearch/kio_filenamesearch.cpp f124f02 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-05 Thread Anthony Fieroni 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/
---

Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
Pescosta.


Changes
---

NOTE: If we have more than one filenameseach process, dbus module will fail - 
epic


Repository: kio-extras


Description
---

Bug is introduced in https://git.reviewboard.kde.org/r/129297/
When is fixed new kio-extras realease is needed for 16.08 branch.


Diffs (updated)
-

  filenamesearch/CMakeLists.txt 774d79e 
  filenamesearch/filenamesearchdbusinterface.h PRE-CREATION 
  filenamesearch/filenamesearchdbusinterface.cpp PRE-CREATION 
  filenamesearch/kded/CMakeLists.txt 48160ed 
  filenamesearch/kded/filenamesearchdbusadaptor.h PRE-CREATION 
  filenamesearch/kded/filenamesearchdbusadaptor.cpp PRE-CREATION 
  filenamesearch/kded/filenamesearchmodule.h 4fa6bb1 
  filenamesearch/kded/filenamesearchmodule.cpp f12626d 
  filenamesearch/kio_filenamesearch.h 0920394 
  filenamesearch/kio_filenamesearch.cpp f124f02 

Diff: https://git.reviewboard.kde.org/r/129394/diff/


Testing
---

No big ram usage but still not works as expected.
1. Perform search in Dolphin
2. Delete one result item
3. View must be update, but it's not


Thanks,

Anthony Fieroni

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-04 Thread David Faure 


> On Nov. 21, 2016, 8:34 a.m., David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
> But if

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-04 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101273
---



Sure, ship the RAM-usage fix, even if we still need to think about making all 
this actually work.

- David Faure


On Nov. 14, 2016, 11:44 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-12-04 Thread Anthony Fieroni 


> On Ноев. 21, 2016, 10:34 преди обяд, David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-30 Thread Anthony Fieroni 


> On Ноев. 21, 2016, 10:34 преди обяд, David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-26 Thread David Faure 


> On Nov. 21, 2016, 8:34 a.m., David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
> But if

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-25 Thread Anthony Fieroni 


> On Ноев. 21, 2016, 10:34 преди обяд, David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-25 Thread David Faure 


> On Nov. 21, 2016, 8:34 a.m., David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
> But if

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-24 Thread Anthony Fieroni 


> On Ноев. 21, 2016, 10:34 преди обяд, David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.
> 
> David Faure wrote:
> Ah but then KDirLister never sees that URL with a query in it, it's only 
> used for the app->slave communication (listDir).
>(don't look for handling of queries in kdirlister, there isn't any. 
> kdirlister thinks of dirs with items in them, that's it).
> 
> And to make things more confusing, I wasn't talking about the KDirLister 
> used by the slave itself (this is rather unusual and could be much more 
> optimized by using KIO::listDir directly; KDirLister is the backend for 
> views, it puts items into a cache and keeps watching them to mark them as 
> dirty so it knows to update the cache when going to that directory again... 
> all this is overkill for a kioslave who just wants to do a listDir).
> 
> But that's a separate issue. For now let's forget about those 
> KDirListers. The one that I was talking about was the one on the Dolphin 
> side, that one that triggers the listDir in filenamesearch itself in the 
> first place. I think what's happening is that it lists filenamesearch: and in 
> return gets items with UDS_NAME=".zshrc" and 
> UDS_URL="file:///home/dfaure/.zshrc" (random example), so it stores it as if 
> it was filenamesearch:/.zshrc (it's a file inside the listed directory). 
> Which opens the question about what happens if two search results have the 
> same filename.
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-21 Thread David Faure 


> On Nov. 21, 2016, 8:34 a.m., David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103
> 
> Anthony Fieroni wrote:
> I and David, i guess, it's not clear how KDirlister handles url with 
> queries, i'm searching for this code, but i don't found it.

Ah but then KDirLister never sees that URL with a query in it, it's only used 
for the app->slave communication (listDir).
   (don't look for handling of queries in kdirlister, there isn't any. 
kdirlister thinks of dirs with items in them, that's it).

And to make things more confusing, I wasn't talking about the KDirLister used 
by the slave itself (this is rather unusual and could be much more optimized by 
using KIO::listDir directly; KDirLister is the backend for views, it puts items 
into a cache and keeps watching them to mark them as dirty so it knows to 
update the cache when going to that directory again... all this is overkill for 
a kioslave who just wants to do a listDir).

But that's a separate issue. For now let's forget about those KDirListers. The 
one that I was talking about was the one on the Dolphin side, that one that 
triggers the listDir in filenamesearch itself in the first place. I think 
what's happening is that it lists filenamesearch: and in return gets items with 
UDS_NAME=".zshrc" and UDS_URL="file:///home/dfaure/.zshrc" (random example), so 
it stores it as if it was filenamesearch:/.zshrc (it's a file inside the listed 
directory). Which opens the question about what happens if two search results 
have the same filename.
But if this analysis is correct, then the URL that the kded module has to emit 
is

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-21 Thread Anthony Fieroni 


> On Nov. 21, 2016, 10:34 a.m., David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results
> 
> Emmanuel Pescosta wrote:
> Peter wrote the filenamesearch slave.
> 
> Filenamesearch URLs are only used to initiate a search. The URL contains 
> the search start-folder, the pattern used for matching and an optional 'check 
> contents' query item which can be yes or no. The filenamesearch ioslave uses 
> all this query items to perform the search. It recursively opens each folder 
> via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
> and iterates trough the item list of the directory, every matching item is 
> then listed via `listEntry` by using the UDSEntry of the matching item (see 
> 1). So kio_filenamesearch can only return items with an empty path if the 
> underlying ioslave (local, smb, ftp, ...) returns items with an empty path.
> 
> [1] 
> https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103

I and David, i guess, it's not clear how KDirlister handles url with queries, 
i'm searching for this code, but i don't found it.


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101007
---


On Nov. 14, 2016, 1:44 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-21 Thread Emmanuel Pescosta 


> On Nov. 21, 2016, 9:34 a.m., David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }
> 
> David Faure wrote:
> Maybe, but I'm still in the dark about something. How can KDirLister cope 
> with listing such URLs? It wants a directory URL and files inside that 
> directory. Such a filenamesearch URL doesn't look like it's a file inside a 
> directory, in terms of paths. Ideally I would look into the code to 
> understand what is being done but I'm short on time.
> 
> Does kio_filenamesearch really return items from listDir(), which have an 
> empty path too, just like the listed directory? I would assume this breaks 
> many things in KDirLister.
> 
> Please clarify with the dolphin people (or whoever wrote the 
> filenamesearch KIO) about the URL structure, then it will be straightforward 
> to do the URL conversions in this code.
> 
> Anthony Fieroni wrote:
> I'm invited Emmanuel, who knows? 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L123
>  url("filenamesearch:?search=file=file:///path/to/file") in slot 
> https://github.com/KDE/dolphin/blob/1710304e9ba926d2aec4226d00974b826f9bcbc0/src/kitemviews/kfileitemmodel.cpp#L77
>  comes results

Peter wrote the filenamesearch slave.

Filenamesearch URLs are only used to initiate a search. The URL contains the 
search start-folder, the pattern used for matching and an optional 'check 
contents' query item which can be yes or no. The filenamesearch ioslave uses 
all this query items to perform the search. It recursively opens each folder 
via KCoreDirLister (starting with the start-folder of the filenamesearch URL) 
and iterates trough the item list of the directory, every matching item is then 
listed via `listEntry` by using the UDSEntry of the matching item (see 1). So 
kio_filenamesearch can only return items with an empty path if the underlying 
ioslave (local, smb, ftp, ...) returns items with an empty path.

[1] 
https://github.com/KDE/kio-extras/blob/master/filenamesearch/kio_filenamesearch.cpp#L103


- Emmanuel


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101007
---


On Nov. 14, 2016, 12:44 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-21 Thread David Faure 


> On Nov. 21, 2016, 8:34 a.m., David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?
> 
> Anthony Fieroni wrote:
> This is a big misunderstanding mainly by me. Emitted url should contains 
> query with new path ?
> for (const QString  : files) {
> const QUrl url(file);
> if (!url.isLocalFile()) {
> continue;
> }
> const QString urlPath = url.path();
> for (const QUrl  : m_searchUrls) {
> QUrlQuery urlQuery(dirUrl);
> QString str = urlQuery.queryItemValue(QStringLiteral("url"));
> if (urlPath.startsWith(QUrl(str).path())) {
> QUrl temp;
> temp.setScheme(QStringLiteral("filenamesearch"));
> urlQuery.removeQueryItem(QStringLiteral("url");
> urlQuery.addQueryItem(QStringLiteral('url"), url);
> temp.setQuery(urlQuery);
> fileList << temp;
> }
> }
> }

Maybe, but I'm still in the dark about something. How can KDirLister cope with 
listing such URLs? It wants a directory URL and files inside that directory. 
Such a filenamesearch URL doesn't look like it's a file inside a directory, in 
terms of paths. Ideally I would look into the code to understand what is being 
done but I'm short on time.

Does kio_filenamesearch really return items from listDir(), which have an empty 
path too, just like the listed directory? I would assume this breaks many 
things in KDirLister.

Please clarify with the dolphin people (or whoever wrote the filenamesearch 
KIO) about the URL structure, then it will be straightforward to do the URL 
conversions in this code.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101007
---


On Nov. 14, 2016, 11:44 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-21 Thread Anthony Fieroni 


> On Ноев. 21, 2016, 10:34 преди обяд, David Faure wrote:
> > filenamesearch/kded/filenamesearchmodule.cpp, line 84
> > 
> >
> > Well, if dirUrl looks like 
> > "filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() 
> > is empty, and this code is incorrect (it should use the query item "url", 
> > not the path). What am I missing?

This is a big misunderstanding mainly by me. Emitted url should contains query 
with new path ?
for (const QString  : files) {
const QUrl url(file);
if (!url.isLocalFile()) {
continue;
}
const QString urlPath = url.path();
for (const QUrl  : m_searchUrls) {
QUrlQuery urlQuery(dirUrl);
QString str = urlQuery.queryItemValue(QStringLiteral("url"));
if (urlPath.startsWith(QUrl(str).path())) {
QUrl temp;
temp.setScheme(QStringLiteral("filenamesearch"));
urlQuery.removeQueryItem(QStringLiteral("url");
urlQuery.addQueryItem(QStringLiteral('url"), url);
temp.setQuery(urlQuery);
fileList << temp;
}
}
}


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101007
---


On Ноев. 14, 2016, 1:44 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-21 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review101007
---




filenamesearch/kded/filenamesearchmodule.cpp (line 84)


Well, if dirUrl looks like 
"filenamesearch:?search=file=file:///path/to/file" then dirUrl.path() is 
empty, and this code is incorrect (it should use the query item "url", not the 
path). What am I missing?


- David Faure


On Nov. 14, 2016, 11:44 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-21 Thread Anthony Fieroni 


> On Nov. 15, 2016, 6:40 p.m., David Faure wrote:
> > This fix makes sense to me (well, I suggested it) ;)
> > 
> > As to why it doesn't work, that requires more info about how filenamesearch 
> > URLs are actually being used. Is this documented somewhere, or does it 
> > require testing and debugging?
> 
> Anthony Fieroni wrote:
> I don't see documementation, in Dolphin it is used 
> KDirLister::openUrl(QUrl("filenamesearch:?search=file=file:///path/to/file"))
> 
> Anthony Fieroni wrote:
> https://git.reviewboard.kde.org/r/129141/

This to ship it and to search solution in Dolphin? Is there need any other 
improvements?


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review100862
---


On Nov. 14, 2016, 1:44 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-16 Thread Anthony Fieroni 


> On Ноев. 15, 2016, 6:40 след обяд, David Faure wrote:
> > This fix makes sense to me (well, I suggested it) ;)
> > 
> > As to why it doesn't work, that requires more info about how filenamesearch 
> > URLs are actually being used. Is this documented somewhere, or does it 
> > require testing and debugging?
> 
> Anthony Fieroni wrote:
> I don't see documementation, in Dolphin it is used 
> KDirLister::openUrl(QUrl("filenamesearch:?search=file=file:///path/to/file"))

https://git.reviewboard.kde.org/r/129141/


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review100862
---


On Ноев. 14, 2016, 1:44 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-16 Thread Anthony Fieroni 


> On Ноев. 15, 2016, 6:40 след обяд, David Faure wrote:
> > This fix makes sense to me (well, I suggested it) ;)
> > 
> > As to why it doesn't work, that requires more info about how filenamesearch 
> > URLs are actually being used. Is this documented somewhere, or does it 
> > require testing and debugging?

I don't see documementation, in Dolphin it is used 
KDirLister::openUrl(QUrl("filenamesearch:?search=file=file:///path/to/file"))


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review100862
---


On Ноев. 14, 2016, 1:44 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-15 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/#review100862
---



This fix makes sense to me (well, I suggested it) ;)

As to why it doesn't work, that requires more info about how filenamesearch 
URLs are actually being used. Is this documented somewhere, or does it require 
testing and debugging?

- David Faure


On Nov. 14, 2016, 11:44 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129394/
> ---
> 
> Review request for KDE Frameworks, Anthony Fieroni, David Faure, and Emmanuel 
> Pescosta.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Bug is introduced in https://git.reviewboard.kde.org/r/129297/
> When is fixed new kio-extras realease is needed for 16.08 branch.
> 
> 
> Diffs
> -
> 
>   filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 
> 
> Diff: https://git.reviewboard.kde.org/r/129394/diff/
> 
> 
> Testing
> ---
> 
> No big ram usage but still not works as expected.
> 1. Perform search in Dolphin
> 2. Delete one result item
> 3. View must be update, but it's not
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Review Request 129394: [filenamesearch] Fix huge ram usage in kded module

2016-11-13 Thread Anthony Fieroni 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129394/
---

Review request for KDE Frameworks and David Faure.


Repository: kio-extras


Description
---

Bug is introduced in https://git.reviewboard.kde.org/r/129297/
When is fixed new kio-extras realease is needed for 16.08 branch.


Diffs
-

  filenamesearch/kded/filenamesearchmodule.cpp 3f9f582 

Diff: https://git.reviewboard.kde.org/r/129394/diff/


Testing
---

No big ram usage but still not works as expected.
1. Perform search in Dolphin
2. Delete one result item
3. View must be update, but it's not


Thanks,

Anthony Fieroni