> On Aug. 28, 2013, 3:31 p.m., Kevin Ottens wrote: > > tier1/solid/src/declarative/devices.h, line 73 > > <http://git.reviewboard.kde.org/r/111964/diff/2/?file=178383#file178383line73> > > > > Should be "empty" for the property name. > > Ivan Čukić wrote: > I took it from QList and QString - both have isEmpty, while QList has > empty() for STL compatibility. > > Sure it should be without 'is'?
I know the C++ API uses the "is" prefix. But the QML one not (go figure) and since that's intended to be used there. - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111964/#review38799 ----------------------------------------------------------- On Aug. 29, 2013, 10:57 a.m., Ivan Čukić wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111964/ > ----------------------------------------------------------- > > (Updated Aug. 29, 2013, 10:57 a.m.) > > > Review request for Solid, Àlex Fiestas, Aleix Pol Gonzalez, David Edmundson, > and Kevin Ottens. > > > Description > ------- > > revision 0: > > This one will need more review and discussion - it exposes some of Solid > functionality to QML. > > The reason Solid classes are not exported directly is that they don't tend to > have a no-arg constructor, and some of them are not QObjects. > > It registers a class (org.kde.solid.)Devices (initially modelled after > DeviceNotifier) that contains the following features: > - ability to list all devices or just those that match a defined query > (Solid::Predicate) > - signals for when devices that match the query are added or deleted > - isEmpty property - are there no devices that match the query? > - count property - the number of devices that match the query > - devices property - a list of udis of the devices that match the query > - device method that returns a QObject interface to the device. > > The things I'm in doubt about: > > 1. devices property and device(...) method are similarly named, while one > gets udis, and the other actual DeviceInterface object. > > Possible solutions: > - devices -> udis or deviceUdis > - device(...) -> deviceInterface(...) or something else > > 2. If the user creates two instances with the same query, both instances will > contain a query and a Solid::Predicate, the query will be parsed two times > and similar. > > The implementation could be complicated a bit by creating private parts of > instances with the same queries to be shared, but is it worth it? > > revision 1: > > Shared backends when two Devices objects have a same query. > > > Diffs > ----- > > tier1/solid/src/CMakeLists.txt c3c462f > tier1/solid/src/imports/CMakeLists.txt PRE-CREATION > tier1/solid/src/imports/devices.h PRE-CREATION > tier1/solid/src/imports/devices.cpp PRE-CREATION > tier1/solid/src/imports/devices_p.h PRE-CREATION > tier1/solid/src/imports/qmldir PRE-CREATION > tier1/solid/src/imports/solidextensionplugin.h PRE-CREATION > tier1/solid/src/imports/solidextensionplugin.cpp PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/111964/diff/ > > > Testing > ------- > > Yes. Created a test QML application. > > > Thanks, > > Ivan Čukić > >
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
