Op 1-3-2013 11:52, Konstantin Ritt schreef: > 2013/3/1 André Somers <an...@familiesomers.nl>: >> Op 1-3-2013 10:22, Иван Комиссаров schreef: >> >> I don't think it's a good idea to try to fix QStorageInfo. >> >> The main argument is that QStorageInfo is a monitor+info provider, but >> monitor should depend on a DBus in Linux; however info provider doesn't >> require that. Also, monitor requires internal thread on Mac. My point is >> that in many cases, when you doesn't need monitor itself, it's too heavy to >> create such a huge object just to receive volume info. >> >> I don't find that a convincing argument. The implementation could be such, >> that the heavy machinery is only instantiated when somebody actually >> connects to the monitoring signals. We have connectNotify and >> disconnectNotify available for that in QObject. >> >> That's why i separated my solution into 2 different classes; so QtDriveInfo >> doesn't require external dependencies, like DBus. >> >> I think I would prefer to have the controls and notification signals >> directly on the QDriveInfo class itself. That seems to be more consistent >> with the rest of the Qt API, where I can't think of other examples of a >> separate controller class. > Consistent with what API? To me, QDriveInfo is just like QFileInfo > (incl. the ability to control the cache) and the monitor is just like > QFileSystemWatcher that can send you a changed/added/removed driveinfo That's true, indeed. I did not think about QFileInfo (even though that's not my favourite part of the Qt API).
André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
