D8636: Add support for downloading the 2nd or 3rd download link from a kde store product when fetching lookandfeel dependencies

[Chris Holland]

Zren edited the test plan for this revision.

REPOSITORY
  R252 Framework Integration

REVISION DETAIL
  https://phabricator.kde.org/D8636

To: Zren
Cc: #frameworks

D8636: Add support for downloading the 2nd or 3rd download link from a kde store product when fetching lookandfeel dependencies

[Chris Holland]

Zren created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  Implementing the feature request in BUG #385429.
  https://bugs.kde.org/show_bug.cgi?id=385429
  
  LookAndFeels introduced the ability to set dependencies, that are downloaded 
first before installing the look and feel package.
  https://userbase.kde.org/Plasma/Create_a_Look_and_Feel_Package
  
  Eg: X-KPackage-Dependencies=kns://plasmoids.knsrc/api.kde-look.org/1160672
  
  It will call:
  
/usr/lib/x86_64-linux-gnu/libexec/kf5/kpackagehandlers/knshandler 
kns://plasmoids.knsrc/api.kde-look.org/1160672
  
  Previously this file called `engine.install(entry);`
  the second argument (`linkId`) isn't supplied so it defaults to 1.
  
void install(KNSCore::EntryInternal entry, int linkId = 1);
  
  This means it downloads the first link, which for me is the oldest version of 
the widget typically.
  
  https://api.kde-look.org/ocs/v1/content/download/1160672/1
  tells it to download tiledmenu-v05-kde5.5.plasmoid
  
  while
  https://api.kde-look.org/ocs/v1/content/download/1160672/3
  tells it to download the latest version tiledmenu-v18-kde5.9.plasmoid
  
  This patch adds the ability to specify which link to download in the 3rd path 
section.
  
  Eg: `kns://plasmoids.knsrc/api.kde-look.org/1160672/3`

TEST PLAN
  Shorten the command call for testing since knshandler isn't in `$PATH`.
  
alias 
knshandler='/usr/lib/x86_64-linux-gnu/libexec/kf5/kpackagehandlers/knshandler'
  
  
  
knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672
// Installs tiledmenu-v05-kde5.5.plasmoid

knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/2
// Should error, since we didn't uninstall the previous version. Should log:
// Command ' "kpackagetool5 --install /tmp/tiledmenu-v05-kde5.5.plasmoid 
--type Plasma/Applet" ' failed with code 4

/tmp/tiledmenu-v05-kde5.5.plasmoid

knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/2
// Should error, since we didn't uninstall the previous version. Should log:
// Command ' "kpackagetool5 --install /tmp/tiledmenu-v11-kde5.6.plasmoid 
--type Plasma/Applet" ' failed with code 4

knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/3
// Should error, since we didn't uninstall the previous version. Should log:
// Command ' "kpackagetool5 --install /tmp/tiledmenu-v18-kde5.9.plasmoid 
--type Plasma/Applet" ' failed with code 4
  
  knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/3
  // Should error, since we didn't uninstall the previous version. Should log:
  // Command ' "kpackagetool5 --install /tmp/tiledmenu-v18-kde5.9.plasmoid 
--type Plasma/Applet" ' failed with code 4
  
  knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/test
  // linkId is not an integer 
QUrl("kns://plasmoids.knsrc/api.kde-look.org/1160672/test") 
("api.kde-look.org", "1160672", "test")
  
  knshandler kns://plasmoids.knsrc/api.kde-look.org/1160672/2/test
  // wrong format in the url path 
QUrl("kns://plasmoids.knsrc/api.kde-look.org/1160672/2/test") 
("api.kde-look.org", "1160672", "2", "test")
  
  knshandler kns://plasmoids.knsrc/api.kde-look.org/
  // wrong format in the url path 
QUrl("kns://plasmoids.knsrc/api.kde-look.org/") ("api.kde-look.org")

REPOSITORY
  R252 Framework Integration

REVISION DETAIL
  https://phabricator.kde.org/D8636

AFFECTED FILES
  src/kpackage-install-handlers/kns/main.cpp

To: Zren
Cc: #frameworks

D7828: fix createKMessageBox focus widget inconsistency

[Nathaniel Graham]

This revision was automatically updated to reflect the committed changes.
Closed by commit R236:19a313ecc90c: fix createKMessageBox focus widget 
inconsistency (authored by emateli, committed by ngraham).

REPOSITORY
  R236 KWidgetsAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7828?vs=21453=21820

REVISION DETAIL
  https://phabricator.kde.org/D7828

AFFECTED FILES
  src/kmessagebox.cpp

To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx, subdiff
Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks

D7828: fix createKMessageBox focus widget inconsistency

[Nathaniel Graham]

ngraham added a comment.


  I think we've got enough thumbs up. I'm gonna land this.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D7828

To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx, subdiff
Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks

D8633: KLauncher: remove dead code related to autostart.

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R303 KInit

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8633

To: dfaure, davidedmundson
Cc: #plasma, #frameworks

Re: Python bindings using cppyy (was: An update on Python bindings)

[Shaheed Haque]

Albert,

On 2 November 2017 at 21:43, Albert Astals Cid  wrote:
> El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va
> escriure:
>> A progress update...
>>
>> On 24 October 2017 at 13:05, Shaheed Haque  wrote:
>> > Hi all,
>> >
>> > I have a preliminary version of the Cppyy bindings generator CMake
>> >
>> > support available here:
>> > https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-ex
>> > perimental-version-of-a/diff>
>> > There are some TODOs yet to be addressed,
>>
>> The original TODOs and bugs have been resolved, and there is the
>> beginnings of support for packaging frameworks under a Python
>> namespace as in "KF5.KDCRAW". Also, as a significant datapoint, I'm
>> close [1] to being able to generate a *complete* set of bindings for
>> all of Akonadi driven from CMake with just 2-3 lines of custom logic.
>> This contrasts with the 549 SLOC of customisation needed to produce a
>> substantially slash-and-burned subset of Akonadi [2] with the
>> SIP-based approach.
>>
>> > but I would appreciate
>> > feedback on how easy it would be to integrate this with KDE's
>> > buildsystem, especially for the frameworks. I'm a CMake noob, but the
>> > basic idea I have is that the packager of some_framework might do
>> > something like this:
>> >
>> > find_package(cppyy)
>> > CPPYY_ADD_BINDINGS(
>> >
>> > ...
>> > LINK_LIBRARIES some_framework_LIBRARIES
>> > H_DIR some_framework_INCLUDE_DIRS
>> > H_FILES )
>>
>> In the course of working through the "KF5" namespace implementation,
>> it has become apparent to me that a framework-by-framework integration
>> of the binding generation logic (as previously pioneered by Steve)
>> probably cannot work in general because there are cases where multiple
>> frameworks contribute to to the same C++ namespace, for example:
>>
>> $ grep -r '^namespace Akonadi' /usr/include/KF5/Akonadi*
>> /usr/include/KF5/AkonadiAgentBase/resourcesettings.h:namespace Akonadi
>> ..
>> /usr/include/KF5/AkonadiCore/agentfilterproxymodel.h:namespace Akonadi
>> ..
>> /usr/include/KF5/AkonadiSearch/Debug/akonadisearchdebugsearchpathcombobox.h:
>> namespace Akonadi
>> ..
>> /usr/include/KF5/AkonadiWidgets/agenttypedialog.h:namespace Akonadi
>> ..
>> /usr/include/KF5/AkonadiXml/xmldocument.h:namespace Akonadi
>> ..
>>
>> The problem is that the Python implementation of these namespaces is a
>> class, and so treating these frameworks (let's not quibble over
>> whether KF5Akonadi* are truly KF5 frameworks, the point is more
>> general) as separate would result in multiple colliding Python class
>> definitions. The only solution I can see would be to bundle all of
>> KF5Akonadi* into a single set of bindings, e.g. KF5.Akonadi, and
>> AFAICS, this can only be done out of tree from the individual
>> frameworks, say in kde-bindings.git [3].
>
> Sincerely if you go with out ot tree bindings they will always be broken
> because people working on the frameworks won't even see them, if the problem
> is that frameworks have to be self-contained, this seems like a good general
> rule to me and maybe what we should do is fix the libs?

Thanks for the input, but...

Firstly, we have existence proofs in the form of PyQt and the PyKDE4
bindings that (even with the SIP support tax), that out of tree
bindings are possible, and I am hopeful that things will be much
easier with cppyy.

Also, I wonder how easy that will be given the need to keep source
compatibility? I've hardly done a comprehensive survey, but if the
Akonadi example is anything to go by, I don't think there is a short
term prospect of seeing a solution to this problem. If there is
developer effort available from framework owners, I'd much rather see
that put to productive use (there are plenty of point issues like
#includes broken-from-my-POV and the like).

Finally, not to put to fine a point on it, I've been working on this
for the best part of two years, and I am very keen to get to something
workable. (Not least because I hope to get a job at some point...and
then intensive effort from me at least might be much trickier to offer
up).

Cheers, Shaheed

> Cheers,
>   Albert
>
>>
>> The work to date attempts to maintain a clean separation such that all
>> C++ builds are done from CMake, and all Python builds are done using
>> setuptools/pip.
>>
>> Apart from working through bugs [1], the remaining work items I can
>>
>> think of are, as before:
>> >> - Need to look into the exact usage of Qt-specifics: signals/slots and
>> >> interoperability with SIP-based PyQt
>> >> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glu
>> >> e-ing-applications,
>> >> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html)
>> >>
>> >> - Need to figure out how any customisations which *are* required
>> >> should be handled.
>>
>> plus:
>>
>> - I'm working with upstream on how to support discovery (e.g. via
>> autocompletion in Python3). There is some 

D8336: Improve apidox of KJobTrackerInterface

[Elvis Angelaccio]

elvisangelaccio added a comment.


  @kossebau Ping?

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D8336

To: elvisangelaccio, kossebau, dfaure
Cc: apol, #frameworks

D8633: KLauncher: remove dead code related to autostart.

[David Faure]

dfaure created this revision.
dfaure added a reviewer: davidedmundson.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  ksmserver takes care of it (and no longer calls this code) since August
  2016, see 
https://phabricator.kde.org/R120:d9883511c92e448b3441d994170fa1d43eea4ff2
  in plasma-workspace.
  
  I have moved autostarttest.cpp to ksmserver just now.

TEST PLAN
  none, dead code

REPOSITORY
  R303 KInit

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8633

AFFECTED FILES
  CMakeLists.txt
  src/klauncher/klauncher.cpp
  src/klauncher/klauncher.h
  src/klauncher/klauncher_adaptor.cpp
  src/klauncher/klauncher_adaptor.h
  tests/CMakeLists.txt
  tests/autostarttest.cpp

To: dfaure, davidedmundson
Cc: #plasma, #frameworks

Re: Python bindings using cppyy (was: An update on Python bindings)

[Albert Astals Cid]

El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va 
escriure:
> A progress update...
> 
> On 24 October 2017 at 13:05, Shaheed Haque  wrote:
> > Hi all,
> > 
> > I have a preliminary version of the Cppyy bindings generator CMake
> > 
> > support available here:
> > https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-ex
> > perimental-version-of-a/diff> 
> > There are some TODOs yet to be addressed,
> 
> The original TODOs and bugs have been resolved, and there is the
> beginnings of support for packaging frameworks under a Python
> namespace as in "KF5.KDCRAW". Also, as a significant datapoint, I'm
> close [1] to being able to generate a *complete* set of bindings for
> all of Akonadi driven from CMake with just 2-3 lines of custom logic.
> This contrasts with the 549 SLOC of customisation needed to produce a
> substantially slash-and-burned subset of Akonadi [2] with the
> SIP-based approach.
> 
> > but I would appreciate
> > feedback on how easy it would be to integrate this with KDE's
> > buildsystem, especially for the frameworks. I'm a CMake noob, but the
> > basic idea I have is that the packager of some_framework might do
> > something like this:
> > 
> > find_package(cppyy)
> > CPPYY_ADD_BINDINGS(
> > 
> > ...
> > LINK_LIBRARIES some_framework_LIBRARIES
> > H_DIR some_framework_INCLUDE_DIRS
> > H_FILES )
> 
> In the course of working through the "KF5" namespace implementation,
> it has become apparent to me that a framework-by-framework integration
> of the binding generation logic (as previously pioneered by Steve)
> probably cannot work in general because there are cases where multiple
> frameworks contribute to to the same C++ namespace, for example:
> 
> $ grep -r '^namespace Akonadi' /usr/include/KF5/Akonadi*
> /usr/include/KF5/AkonadiAgentBase/resourcesettings.h:namespace Akonadi
> ..
> /usr/include/KF5/AkonadiCore/agentfilterproxymodel.h:namespace Akonadi
> ..
> /usr/include/KF5/AkonadiSearch/Debug/akonadisearchdebugsearchpathcombobox.h:
> namespace Akonadi
> ..
> /usr/include/KF5/AkonadiWidgets/agenttypedialog.h:namespace Akonadi
> ..
> /usr/include/KF5/AkonadiXml/xmldocument.h:namespace Akonadi
> ..
> 
> The problem is that the Python implementation of these namespaces is a
> class, and so treating these frameworks (let's not quibble over
> whether KF5Akonadi* are truly KF5 frameworks, the point is more
> general) as separate would result in multiple colliding Python class
> definitions. The only solution I can see would be to bundle all of
> KF5Akonadi* into a single set of bindings, e.g. KF5.Akonadi, and
> AFAICS, this can only be done out of tree from the individual
> frameworks, say in kde-bindings.git [3].

Sincerely if you go with out ot tree bindings they will always be broken 
because people working on the frameworks won't even see them, if the problem 
is that frameworks have to be self-contained, this seems like a good general 
rule to me and maybe what we should do is fix the libs?

Cheers,
  Albert

> 
> The work to date attempts to maintain a clean separation such that all
> C++ builds are done from CMake, and all Python builds are done using
> setuptools/pip.
> 
> Apart from working through bugs [1], the remaining work items I can
> 
> think of are, as before:
> >> - Need to look into the exact usage of Qt-specifics: signals/slots and
> >> interoperability with SIP-based PyQt
> >> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glu
> >> e-ing-applications,
> >> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html)
> >> 
> >> - Need to figure out how any customisations which *are* required
> >> should be handled.
> 
> plus:
> 
> - I'm working with upstream on how to support discovery (e.g. via
> autocompletion in Python3). There is some POC-level hackery in git as
> above, but there is work ongoing with upstream to find a robust
> solution.
> 
> - Flesh out how to make one set of bindings depend on another (e.g.
> tier 2 framework bindings might depend on tier 1 bindings, or maybe it
> is better to avoid PyQt and just produce cppyy-based bindings for Qt
> and depend on those).
> 
> As always, comments/ideas/suggestions are welcome.
> 
> Thanks, Shaheed
> 
> [1] There is a bug with namespaced externs being worked on with upstream.
> 
> [2]
> https://github.com/ShaheedHaque/extra-cmake-modules/blob/shaheed_master/fin
> d-modules/module_generation/PyKF5/Akonadi.py
> 
> [3] I attach an example CMakeLists.txt which shows now this can be
> driven from CMake for the case of KF5Akonadi*...the implementation is
> intended to serve as the basis for a generic solution usable across
> KF5 at least.
> 
> > On 16 October 2017 at 16:16, Shaheed Haque  wrote:
> >> As promised, here is an interim update on the investigation into the
> >> use of cppyy-based bindings for KF5 (and more...) instead of SIP-based
> >> bindings.
> >> 
> >> The first thing is that the 

D8632: kded: remove dbus calls to ksplash.

[David Faure]

dfaure created this revision.
dfaure added a reviewer: davidedmundson.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  Not needed anymore since June 2016 (b6058a0 in plasma-workspace, i.e. Plasma
  5.7).
  
  Originally at https://git.reviewboard.kde.org/r/129010/

TEST PLAN
  none, this is dead code

REPOSITORY
  R297 KDED

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8632

AFFECTED FILES
  src/kded.cpp

To: dfaure, davidedmundson
Cc: #plasma, #frameworks

D8348: Add a section for removable devices

[Renato Oliveira Filho]

renatoo updated this revision to Diff 21808.
renatoo added a comment.


  Updated parent branch

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8348?vs=21759=21808

REVISION DETAIL
  https://phabricator.kde.org/D8348

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp
  src/filewidgets/kfileplacesitem.cpp
  src/filewidgets/kfileplacesitem_p.h

To: renatoo, #dolphin, #frameworks, #vdg, ervin, ngraham
Cc: mlaurent, anthonyfieroni, ngraham, #frameworks

D8332: Added baloo urls into places model

[Renato Oliveira Filho]

renatoo marked an inline comment as done.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8332

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D8434: Created 'remote' section

[Renato Oliveira Filho]

renatoo updated this revision to Diff 21809.
renatoo added a comment.


  Updated parent branch

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8434?vs=21760=21809

REVISION DETAIL
  https://phabricator.kde.org/D8434

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp
  src/filewidgets/kfileplacesitem.cpp
  src/filewidgets/kfileplacesitem_p.h

To: renatoo, ngraham, #frameworks, #dolphin, mwolff, mlaurent
Cc: elvisangelaccio, mwolff, mlaurent, #frameworks

D8332: Added baloo urls into places model

[Renato Oliveira Filho]

renatoo updated this revision to Diff 21807.
renatoo added a comment.


  Added warning message for invalid search:// urls

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8332?vs=21758=21807

REVISION DETAIL
  https://phabricator.kde.org/D8332

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/kfileplacesmodeltest.cpp
  autotests/kfileplacesviewtest.cpp
  src/filewidgets/kfileplacesmodel.cpp
  src/filewidgets/kfileplacesview.cpp

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D6317: fix crash on Windows when deleting an instance of QtMultimediaExtractor

[Matthieu Gallien]

mgallien added a comment.


  Sorry for the delay, currently I have no easy access to a development 
computer running Windows.
  David, I am afraid I have not understood correctly your suggestion. Did you 
suggest to make mMetadataExtractor have its thread as Qt parent ?

REPOSITORY
  R286 KFileMetaData

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D6317

To: mgallien, #frameworks, davidedmundson
Cc: davidedmundson, #frameworks

Re: Python bindings using cppyy (was: An update on Python bindings)

[Shaheed Haque]

A progress update...

On 24 October 2017 at 13:05, Shaheed Haque  wrote:
> Hi all,
>
> I have a preliminary version of the Cppyy bindings generator CMake
> support available here:
>
> 
> https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimental-version-of-a/diff
>
> There are some TODOs yet to be addressed,

The original TODOs and bugs have been resolved, and there is the
beginnings of support for packaging frameworks under a Python
namespace as in "KF5.KDCRAW". Also, as a significant datapoint, I'm
close [1] to being able to generate a *complete* set of bindings for
all of Akonadi driven from CMake with just 2-3 lines of custom logic.
This contrasts with the 549 SLOC of customisation needed to produce a
substantially slash-and-burned subset of Akonadi [2] with the
SIP-based approach.

> but I would appreciate
> feedback on how easy it would be to integrate this with KDE's
> buildsystem, especially for the frameworks. I'm a CMake noob, but the
> basic idea I have is that the packager of some_framework might do
> something like this:
>
> find_package(cppyy)
> CPPYY_ADD_BINDINGS(
> ...
> LINK_LIBRARIES some_framework_LIBRARIES
> H_DIR some_framework_INCLUDE_DIRS
> H_FILES )

In the course of working through the "KF5" namespace implementation,
it has become apparent to me that a framework-by-framework integration
of the binding generation logic (as previously pioneered by Steve)
probably cannot work in general because there are cases where multiple
frameworks contribute to to the same C++ namespace, for example:

$ grep -r '^namespace Akonadi' /usr/include/KF5/Akonadi*
/usr/include/KF5/AkonadiAgentBase/resourcesettings.h:namespace Akonadi
...
/usr/include/KF5/AkonadiCore/agentfilterproxymodel.h:namespace Akonadi
...
/usr/include/KF5/AkonadiSearch/Debug/akonadisearchdebugsearchpathcombobox.h:namespace
Akonadi
...
/usr/include/KF5/AkonadiWidgets/agenttypedialog.h:namespace Akonadi
...
/usr/include/KF5/AkonadiXml/xmldocument.h:namespace Akonadi
...

The problem is that the Python implementation of these namespaces is a
class, and so treating these frameworks (let's not quibble over
whether KF5Akonadi* are truly KF5 frameworks, the point is more
general) as separate would result in multiple colliding Python class
definitions. The only solution I can see would be to bundle all of
KF5Akonadi* into a single set of bindings, e.g. KF5.Akonadi, and
AFAICS, this can only be done out of tree from the individual
frameworks, say in kde-bindings.git [3].

The work to date attempts to maintain a clean separation such that all
C++ builds are done from CMake, and all Python builds are done using
setuptools/pip.

Apart from working through bugs [1], the remaining work items I can
think of are, as before:

>> - Need to look into the exact usage of Qt-specifics: signals/slots and
>> interoperability with SIP-based PyQt
>> (https://root.cern.ch/root/htmldoc/guides/users-guide/PythonRuby.html#glue-ing-applications,
>> https://root.cern.ch/doc/v606_ORIG/guide/ROOTandQt.html)
>>
>> - Need to figure out how any customisations which *are* required
>> should be handled.

plus:

- I'm working with upstream on how to support discovery (e.g. via
autocompletion in Python3). There is some POC-level hackery in git as
above, but there is work ongoing with upstream to find a robust
solution.

- Flesh out how to make one set of bindings depend on another (e.g.
tier 2 framework bindings might depend on tier 1 bindings, or maybe it
is better to avoid PyQt and just produce cppyy-based bindings for Qt
and depend on those).

As always, comments/ideas/suggestions are welcome.

Thanks, Shaheed

[1] There is a bug with namespaced externs being worked on with upstream.

[2] 
https://github.com/ShaheedHaque/extra-cmake-modules/blob/shaheed_master/find-modules/module_generation/PyKF5/Akonadi.py

[3] I attach an example CMakeLists.txt which shows now this can be
driven from CMake for the case of KF5Akonadi*...the implementation is
intended to serve as the basis for a generic solution usable across
KF5 at least.

> On 16 October 2017 at 16:16, Shaheed Haque  wrote:
>> As promised, here is an interim update on the investigation into the
>> use of cppyy-based bindings for KF5 (and more...) instead of SIP-based
>> bindings.
>>
>> The first thing is that the underlying technology of cppyy,
>> cling/ROOT, has been under development at CERN for quite a while. It
>> directly reads regular C++ files (there is no intermediate format like
>> SIP).
>>
>> The bindings it generates from Python to C++ seem far more complete
>> and automatic than SIP. For example:
>>
>> - Template instantiation is done on the fly as needed.
>>
>> - Since it uses C++ directly, there is none the effort required to
>> decollide SIP's notion of forward and duplicate declarations.
>>
>> - Function overloads are cleanly handled, as are most (all?) operators.
>>
>> The net result is that so far, there is about 3 

D8544: KTextEditor : avoiding QML crashes

[René J . V . Bertin]

rjvbb updated this revision to Diff 21793.
rjvbb marked an inline comment as done.
rjvbb added a comment.


  Updated as requested.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8544?vs=21724=21793

REVISION DETAIL
  https://phabricator.kde.org/D8544

AFFECTED FILES
  src/utils/kateglobal.cpp

To: rjvbb, #frameworks
Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, 
head7, sars

D8544: KTextEditor : avoiding QML crashes

[René J . V . Bertin]

rjvbb set the repository for this revision to R39 KTextEditor.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D8544

To: rjvbb, #frameworks
Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, 
head7, sars

D8544: KTextEditor : avoiding QML crashes

[René J . V . Bertin]

rjvbb marked 2 inline comments as done.
rjvbb added inline comments.

INLINE COMMENTS

> kfunk wrote in kateglobal.cpp:106
> Minor: "... set to 1" would be sufficient. You're setting it yourself right 
> before, so you can presume it is set (=> no need for `qgetenv(...)`.

I know that of course, but figured that if I was adding a debug output I could 
just as well have it verify that we got what we asked for.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D8544

To: rjvbb, #frameworks
Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, 
head7, sars

D7828: fix createKMessageBox focus widget inconsistency

[Roman Gilg]

subdiff accepted this revision.
subdiff added a comment.


  Looked at the code and I think @rkflx explained the situation quite well (if 
we should force passing a parent or not - better - for the QDialogButtonBox).

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D7828

To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx, subdiff
Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks

KDE CI: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 - Build # 132 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20FreeBSDQt5.7/132/
 Project:
Frameworks kirigami kf5-qt5 FreeBSDQt5.7
 Date of build:
Thu, 02 Nov 2017 16:49:21 +
 Build duration:
1 min 11 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: TestSuite.qmltests

D7828: fix createKMessageBox focus widget inconsistency

[Emirald Mateli]

emateli added a comment.


  Ping @subdiff @abetts does this iteration work for you guys? It's marked as 
ready to land but I feel that we should get an overall opinion on this.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D7828

To: emateli, #frameworks, ngraham, aacid, #vdg, rkflx
Cc: elvisangelaccio, rkflx, abetts, subdiff, ngraham, aacid, #frameworks

D8332: Added baloo urls into places model

[Nathaniel Graham]

ngraham added a comment.


  @mlaurent would you mind changing your approval status then? :)

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8332

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D8348: Add a section for removable devices

[Nathaniel Graham]

ngraham requested changes to this revision.
ngraham added a comment.
This revision now requires changes to proceed.


  Could you add camera:/ devices to this section too? That way we could also 
take care of https://bugs.kde.org/show_bug.cgi?id=386060

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8348

To: renatoo, #dolphin, #frameworks, #vdg, ervin, ngraham
Cc: mlaurent, anthonyfieroni, ngraham, #frameworks

D8619: Refactor and remove duplicate code in kfileplacesview

[Laurent Montel]

mlaurent updated this revision to Diff 21779.
mlaurent added a comment.


  Remove virtual keyword when we have override

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8619?vs=21778=21779

REVISION DETAIL
  https://phabricator.kde.org/D8619

AFFECTED FILES
  src/filewidgets/kfileplacesview.cpp

To: mlaurent, #frameworks, ervin

D8619: Refactor and remove duplicate code in kfileplacesview

[Laurent Montel]

mlaurent updated this revision to Diff 21778.
mlaurent added a comment.


  Const'ify + use more static_cast

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8619?vs=21776=21778

REVISION DETAIL
  https://phabricator.kde.org/D8619

AFFECTED FILES
  src/filewidgets/kfileplacesview.cpp

To: mlaurent, #frameworks, ervin

D8173: Use readelf to find project dependencies

[Aleix Pol Gonzalez]

apol updated this revision to Diff 21777.
apol added a comment.


  Make sure we get the dependencies from the prefix as well

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8173?vs=20434=21777

BRANCH
  arcpatch-D8173

REVISION DETAIL
  https://phabricator.kde.org/D8173

AFFECTED FILES
  tests/CMakeLists.txt
  tests/ECMToolchainAndroidTest/CMakeLists.txt
  tests/ECMToolchainAndroidTest/main.c
  tests/ECMToolchainAndroidTest/testlinkfile/CMakeFiles/testtarget.dir/link.txt
  tests/ECMToolchainAndroidTest/testlinkfile/outputfake.json
  toolchain/Android.cmake
  toolchain/specifydependencies.cmake

To: apol, #frameworks, #build_system, aacid

D8619: Refactor and remove duplicate code in kfileplacesview

[Laurent Montel]

mlaurent created this revision.
mlaurent added reviewers: Frameworks, ervin.

REVISION SUMMARY
  Remove duplicate code. 
  Use static_cast when we don't test result from dynamic_cast
  Remove unused variable

TEST PLAN
  compile/test

REPOSITORY
  R342 KIO AudioCD

REVISION DETAIL
  https://phabricator.kde.org/D8619

AFFECTED FILES
  src/filewidgets/kfileplacesview.cpp

To: mlaurent, #frameworks, ervin

D8332: Added baloo urls into places model

[Ömer Fadıl Usta]

usta added inline comments.

INLINE COMMENTS

> kfileplacesview.cpp:1348
> +searchUrl = searchUrlForType(QStringLiteral("Video"));
> +}
> +

won't be nice to add an else statement? (for the sake of searchUrl )

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8332

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D8332: Added baloo urls into places model

[Laurent Montel]

mlaurent added a comment.


  +1 for me

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8332

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D8434: Created 'remote' section

[Laurent Montel]

mlaurent accepted this revision.
mlaurent added a comment.


  Seems good for me

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8434

To: renatoo, ngraham, #frameworks, #dolphin, mwolff, mlaurent
Cc: elvisangelaccio, mwolff, mlaurent, #frameworks

D8366: Factoring out lists of url data within KFilePlacesModelTest

[Renato Oliveira Filho]

renatoo added a comment.


  In https://phabricator.kde.org/D8366#163427, @ngraham wrote:
  
  > Is this dependent on any of the other patches floating around?
  
  
  Probably not, but that will affect (possible conflicts) with all patches

REVISION DETAIL
  https://phabricator.kde.org/D8366

To: mlaurent, renatoo, ervin, franckarrecot
Cc: ervin, ngraham, mlaurent, #frameworks

D8366: Factoring out lists of url data within KFilePlacesModelTest

[Nathaniel Graham]

ngraham added a comment.


  Is this dependent on any of the other patches floating around?

REVISION DETAIL
  https://phabricator.kde.org/D8366

To: mlaurent, renatoo, ervin, franckarrecot
Cc: ervin, ngraham, mlaurent, #frameworks

D8544: KTextEditor : avoiding QML crashes

[Dominik Haumann]

dhaumann added a comment.


  By limited amount of time I mean we can remove it once the required Qt 
version of KDE Frameworks is 5.9. (I thought this was obvious :))

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D8544

To: rjvbb, #frameworks
Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, 
head7, sars

D8544: KTextEditor : avoiding QML crashes

[Kevin Funk]

kfunk added inline comments.

INLINE COMMENTS

> kateglobal.cpp:104
> +// disable the QML JIT compiler as a protection against an unknown bug
> +// in Qt's V4 engine which can provoke a crash in certain of our scripts.
> +qputenv("QV4_FORCE_INTERPRETER", QByteArrayLiteral("1"));

Please add a reference to the bug reports (Qt JIRA, KDE Bugzilla) here.

> kateglobal.cpp:106
> +qputenv("QV4_FORCE_INTERPRETER", QByteArrayLiteral("1"));
> +qCDebug(LOG_KTE) << "QV4_FORCE_INTERPRETER set to" << 
> qgetenv("QV4_FORCE_INTERPRETER");
> +#endif

Minor: "... set to 1" would be sufficient. You're setting it yourself right 
before, so you can presume it is set (=> no need for `qgetenv(...)`.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D8544

To: rjvbb, #frameworks
Cc: kfunk, dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, 
head7, sars

D8544: KTextEditor : avoiding QML crashes

[René J . V . Bertin]

rjvbb added a comment.


  Good, I'll push this sometime tonight (I'm waiting for some feedback via the 
Qt bug report ticket, but won't mind if someone beats me to it0.
  
  >   I agree with this patch. It will not hurt and is clearly only relevant 
for a limited amount of time. So +1 from me.
  
  By limited you mean "until we start requiring Qt 5.9"? That won't be too 
soon, I hope (it's already a pity support for 5.6LTS had to be dropped)!

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D8544

To: rjvbb, #frameworks
Cc: dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, 
kfunk, sars

D8544: KTextEditor : avoiding QML crashes

[Dominik Haumann]

dhaumann added a comment.


  I agree with this patch. It will not hurt and is clearly only relevant for a 
limited amount of time. So +1 from me.
  
  And thanks a lot René and Christoph for this work. It will make the next 
Frameworks release better, which is alraedy tagged in 2 days.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D8544

To: rjvbb, #frameworks
Cc: dhaumann, cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, 
kfunk, sars

D8566: Add API to retrieve the screen id for a screen name

[Kevin Ottens]

ervin accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8566

To: amantia, #plasma, ervin, dvratil, mlaurent, hein, davidedmundson
Cc: broulik, plasma-devel, dhaumann, apol, #frameworks, ZrenBot, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, mart

D8366: Factoring out lists of url data within KFilePlacesModelTest

[Renato Oliveira Filho]

renatoo accepted this revision.

REVISION DETAIL
  https://phabricator.kde.org/D8366

To: mlaurent, renatoo, ervin, franckarrecot
Cc: ervin, ngraham, mlaurent, #frameworks

D8348: Add a section for removable devices

[Renato Oliveira Filho]

renatoo updated this revision to Diff 21759.
renatoo added a comment.


  Updated parent branch

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8348?vs=21648=21759

REVISION DETAIL
  https://phabricator.kde.org/D8348

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp
  src/filewidgets/kfileplacesitem.cpp
  src/filewidgets/kfileplacesitem_p.h

To: renatoo, #dolphin, #frameworks, #vdg, ervin
Cc: mlaurent, anthonyfieroni, ngraham, #frameworks

D8434: Created 'remote' section

[Renato Oliveira Filho]

renatoo updated this revision to Diff 21760.
renatoo added a comment.


  Updated parent branch

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8434?vs=21757=21760

REVISION DETAIL
  https://phabricator.kde.org/D8434

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp
  src/filewidgets/kfileplacesitem.cpp
  src/filewidgets/kfileplacesitem_p.h

To: renatoo, ngraham, #frameworks, #dolphin, mwolff
Cc: elvisangelaccio, mwolff, mlaurent, #frameworks

D8332: Added baloo urls into places model

[Renato Oliveira Filho]

renatoo updated this revision to Diff 21758.
renatoo added a comment.


  Fixed code style

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8332?vs=21647=21758

REVISION DETAIL
  https://phabricator.kde.org/D8332

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/kfileplacesmodeltest.cpp
  autotests/kfileplacesviewtest.cpp
  src/filewidgets/kfileplacesmodel.cpp
  src/filewidgets/kfileplacesview.cpp

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D8332: Added baloo urls into places model

[Renato Oliveira Filho]

renatoo marked 5 inline comments as done.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8332

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D8434: Created 'remote' section

[Renato Oliveira Filho]

renatoo updated this revision to Diff 21757.
renatoo added a comment.


  Fixed code style

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8434?vs=21697=21757

REVISION DETAIL
  https://phabricator.kde.org/D8434

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp
  autotests/kfileplacesviewtest.cpp
  src/filewidgets/kfileplacesitem.cpp
  src/filewidgets/kfileplacesitem_p.h

To: renatoo, ngraham, #frameworks, #dolphin, mwolff
Cc: elvisangelaccio, mwolff, mlaurent, #frameworks

D8367: Hidding place groups implementation in KFilePlacesModel

[Laurent Montel]

mlaurent updated this revision to Diff 21755.
mlaurent added a comment.


  Remove commented code. Rename methods

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8367?vs=21752=21755

REVISION DETAIL
  https://phabricator.kde.org/D8367

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp
  src/filewidgets/kfileplacesitem.cpp
  src/filewidgets/kfileplacesitem_p.h
  src/filewidgets/kfileplacesmodel.cpp
  src/filewidgets/kfileplacesmodel.h

To: mlaurent, renatoo, ngraham, franckarrecot, ervin
Cc: ngraham, mlaurent, #frameworks

D8367: Hidding place groups implementation in KFilePlacesModel

[Laurent Montel]

mlaurent marked 2 inline comments as done.

REVISION DETAIL
  https://phabricator.kde.org/D8367

To: mlaurent, renatoo, ngraham, franckarrecot, ervin
Cc: ngraham, mlaurent, #frameworks

D8450: User can now hide an entire places group from KFilePlacesView

[Kevin Ottens]

ervin accepted this revision.
This revision is now accepted and ready to land.

REVISION DETAIL
  https://phabricator.kde.org/D8450

To: mlaurent, ngraham, renatoo, franckarrecot, ervin
Cc: #frameworks

D8367: Hidding place groups implementation in KFilePlacesModel

[Kevin Ottens]

ervin requested changes to this revision.
ervin added a comment.
This revision now requires changes to proceed.


  Couple more changes needed.

INLINE COMMENTS

> kfileplacesmodel.cpp:79-83
> +//static const QHash 
> s_groupTypeToStateName
> +//{
> +//return *s_groupTypeToStateName;
> +//}
> +

This can go away now

> kfileplacesmodel.h:71-72
>  bool isHidden(const QModelIndex ) const;
> +bool isPlaceGroupHidden(const GroupType type) const;
> +bool isPlaceGroupHidden(const QModelIndex ) const;
>  bool isDevice(const QModelIndex ) const;

Just realized now that it'd better be named "isGroupHidden". Otherwise it'll 
get confusing (especially since one of the types is "PlacesType"!)

> kfileplacesmodel.h:89
>  void setPlaceHidden(const QModelIndex , bool hidden);
> +void setPlaceGroupHidden(const GroupType type, bool hidden);
>  

Likewise: setGroupHidden.

REVISION DETAIL
  https://phabricator.kde.org/D8367

To: mlaurent, renatoo, ngraham, franckarrecot, ervin
Cc: ngraham, mlaurent, #frameworks

D8366: Factoring out lists of url data within KFilePlacesModelTest

[Kevin Ottens]

ervin accepted this revision.
This revision is now accepted and ready to land.

REVISION DETAIL
  https://phabricator.kde.org/D8366

To: mlaurent, renatoo, ervin, franckarrecot
Cc: ervin, ngraham, mlaurent, #frameworks

D8367: Hidding place groups implementation in KFilePlacesModel

[Laurent Montel]

mlaurent updated this revision to Diff 21752.
mlaurent added a comment.


  Rebase against master + other top patchs :)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8367?vs=21645=21752

REVISION DETAIL
  https://phabricator.kde.org/D8367

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp
  src/filewidgets/kfileplacesitem.cpp
  src/filewidgets/kfileplacesitem_p.h
  src/filewidgets/kfileplacesmodel.cpp
  src/filewidgets/kfileplacesmodel.h

To: mlaurent, renatoo, ngraham, franckarrecot, ervin
Cc: ngraham, mlaurent, #frameworks

Re: Test failures with krunner 5.39.0

[David Edmundson]

If the external process gets started then it is indeed weird.

Dbus-monitor (or bustle) will be the best tools here, they'll show the
traffic between the test and test helper.

On 1 Nov 2017 23:18, "Hartmut Goebel"  wrote:

> Hallo,
>
> I'm packaging krunner 5.39.0 for GNU Guix [1]. GNU Guix builds all
> software in an isolated environment (a container), which includes only
> the packages and tools specified explicitly.
>
> When running the tests, dbusrunnertest faills, with this notable warning
> and the error show below:
>
>DBusRunnerTest::testMatch() org.kde.krunner: Invalid entry: "DBus
> runner test"
>
> Any idea what may be missing, what needs to be set up (env-var,
> directory, package, paths)? Any idea hos to debug this further?
>
> All required packages and all optional/feature packages (except of QCH)
> are installed. I tried running the tests with both dbus-launch and
> without. The external program "testremoterunner" gets started. strace -e
> trace=file" shows nothing relevant (as far as I can tell).
>
> * Start testing of DBusRunnerTest *
> Config: Using QtTest library 5.9.2, Qt 5.9.2 (x86_64-little_endian-lp64
> shared (dynamic) release build; by GCC 5.4.0)
> PASS   : DBusRunnerTest::initTestCase()
> QWARN  : DBusRunnerTest::testMatch() inotify_add_watch("/etc/mtab")
> failed: "No such file or directory"
> QWARN  : DBusRunnerTest::testMatch() inotify_add_watch("/etc/fstab")
> failed: "No such file or directory"
> QWARN  : DBusRunnerTest::testMatch() org.kde.krunner: Invalid entry:
> "DBus runner test"
> FAIL!  : DBusRunnerTest::testMatch() 'spy.wait()' returned FALSE. ()
>Loc:
> [/tmp/guix-build-krunner-5.39.0.drv-0/krunner-5.39.0/autotes
> ts/dbusrunnertest.cpp(82)]
> PASS   : DBusRunnerTest::cleanupTestCase()
> Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 4931ms
> * Finished testing of DBusRunnerTest *
>
> --
> Regards
> Hartmut Goebel
>
> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
> | www.crazy-compilers.com | compilers which you thought are impossible |
>
>
>

D8544: KTextEditor : avoiding QML crashes

[Christoph Cullmann]

cullmann added a comment.


  I could live with that change.
  It at least will avoid random crashs for the time being until we perhaps have 
a better solution.
  Other opinions?

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D8544

To: rjvbb, #frameworks
Cc: cullmann, kde-frameworks-devel, kevinapavew, demsking, head7, kfunk, sars, 
dhaumann

D8366: Factoring out lists of url data within KFilePlacesModelTest

[Laurent Montel]

mlaurent updated this revision to Diff 21750.
mlaurent added a comment.


  Rebase it

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8366?vs=21646=21750

REVISION DETAIL
  https://phabricator.kde.org/D8366

AFFECTED FILES
  autotests/kfileplacesmodeltest.cpp

To: mlaurent, renatoo, ervin, franckarrecot
Cc: ervin, ngraham, mlaurent, #frameworks

D8332: Added baloo urls into places model

[Laurent Montel]

mlaurent added inline comments.

INLINE COMMENTS

> kfileplacesviewtest.cpp:2
> +/*  This file is part of the KDE project
> +Copyright (C) 2007 Kevin Ottens 
> +

? I don't think that you are kevin ottens :) and we are in 2017 :)

> kfileplacesviewtest.cpp:20
> +
> +#include 
> +#include 

QtCore/ is not necessary

> kfileplacesviewtest.cpp:30
> +
> +#include 
> +#include 

QtTest/ not necessart too

> kfileplacesviewtest.cpp:70
> +}
> +void KFilePlacesViewTest::testConvertUrl_data()
> +{

new line before it

> kfileplacesviewtest.cpp:111
> +
> +QSignalSpy urlChangedSpy(, SIGNAL(urlChanged(QUrl)));
> +const QModelIndex targetIndex = pv.model()->index(row, 0);

use new connect api for QSignalSpy

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8332

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks

D8332: Added baloo urls into places model

[Laurent Montel]

mlaurent requested changes to this revision.
This revision now requires changes to proceed.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D8332

To: renatoo, #frameworks, #dolphin, #kde_applications, dvratil, #vdg, ngraham, 
ervin, mlaurent
Cc: ervin, usta, mlaurent, dvratil, ngraham, #frameworks