Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday 13 January 2014 22:00:53 abba...@gmail.com wrote: But I think maybe we should get the C++ APIs into qtbase, so that QtQuick.Controls.FileDialog doesn't depend on qtsystems. Let me rewind a bit here... I thought QtCore would have query stuff, not mount functionality - which most apps don't need. Is this because you want to offer mounting devices in QFileDialog? But in practice QFileDialog is reimplemented on almost all platforms via the QPA, or should be, right? So that seems a bit pointless. And QtQuick.Controls.FileDialog might not be currently reimplemented via the QPA, but then that's a bug - it should be, to provide consistent dialogs to the user. So e.g. KDE can provide the same mounting capabilities (via the Solid framework) in both dialogs. Hmm, OK, on Windows I suppose embedding the native file dialog into QtQuick is not so great? -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On 13 Jan 2014, at 8:06 PM, David Faure wrote: On Monday 13 January 2014 22:00:53 abba...@gmail.com wrote: But I think maybe we should get the C++ APIs into qtbase, so that QtQuick.Controls.FileDialog doesn't depend on qtsystems. Let me rewind a bit here... I thought QtCore would have query stuff, not mount functionality - which most apps don't need. Is this because you want to offer mounting devices in QFileDialog? But in practice QFileDialog is reimplemented on almost all platforms via the QPA, or should be, right? So that seems a bit pointless. If a volume shows up in the list, the FileDialog should be able to examine its contents. On Windows, the removable-media drives appear even if there is not a disk in the drive. But the mounting/unmounting is a loose concept anyway right? On OSX and Linux, the removable-media drives do not appear if there is no disk, so maybe we can do without mounting on-demand from the file dialog; although it would be an improvement if one could e.g. plug in a USB thumbdrive and have it appear in the dialog right away, whether or not it was mounted. But I at least need notification from somewhere that a drive has been mounted, so when the user opens the dialog and then mounts the drive from elsewhere in the OS, the dialog can see it. With QDriveInfo and my patch as they are now, you have to restart the Qt application because FileDialog only gets the list of QDriveInfo objects once. But maybe the watcher could use a QFileSystemWatcher on /dev/disk/by-label instead of d-bus? I verified that it's possible to get a directoryChanged() signal when I plug in a thumb drive. (But it doesn't tell what new link appeared.) But volume mounting notification does seem like a good thing to add to QPA as long as it can be done without big dependencies like d-bus. And QtQuick.Controls.FileDialog might not be currently reimplemented via the QPA, but then that's a bug - it should be, to provide consistent dialogs to the user. Yes it has been preferring the QPA dialog since the beginning. So far the QML dialog is just for cases where neither a QPA dialog nor a QFileDialog is possible (e.g. on tablets and embedded devices, in applications which do not link the widget module). The 5.1 DefaultFileDialog.qml is feature-poor, just a fallback to make sure that you will always get something when you set a FileDialog visible. In 5.3 it will be using QtQuick Controls, so it becomes possible to have more features, such as a list of shortcuts for available volumes, favorites which can be stored in the application's settings, a ComboBox for the filters, etc. So e.g. KDE can provide the same mounting capabilities (via the Solid framework) in both dialogs. Hmm, OK, on Windows I suppose embedding the native file dialog into QtQuick is not so great? It works fine; it's not really embedding, just using QPA to manage the OS-created dialog. It's the same with GTK on Linux and the OSX file dialog. There is some trouble to use the KDE 4 dialog from Qt 5 though: Qt versions can't be mixed within the same process, so that dialog would have to be in a different process if we were to use it. Maybe it's not worth the effort if KDE will be using Qt 5 soon enough anyway. On KDE, Qt 5 apps use a plain QFileDialog by default. The QML dialog might end up being an improvement over that if we add enough features. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
Here are the QDrive APIs that Tony mentioned below: https://codereview.qt-project.org/#change,75336,patchset=1 Regards, Alvin From: Иван Комиссаров [abba...@gmail.com] Sent: Friday, January 10, 2014 3:49 PM To: Tony Van Eerd Cc: Константин Ритт; Matt Broadstone; David Faure; Alvin Yulo; development@qt-project.org; Rutledge Shawn; Alan Alpert Subject: Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) I also had a drive monitor class https://gitorious.org/qdrive/qdrive/source/bf9f993ec64781534169a7ac630632805ef34374:src/driveinfo/qdrivecontroller.h but it needs a bit polishing Иван Комиссаров 11 янв. 2014 г., в 0:28, Tony Van Eerd tvane...@blackberry.commailto:tvane...@blackberry.com написал(а): We will put up our stuff into a review next week. Currently it is mostly header/API only, no implementation files. We are just trying to get the API designed. We looked at QDriveInfo (either that one or similar one of the same name) and, basically, stole many ideas from it. Ours was also called QDriveInfo until we decided to add non-info stuff like mounting. But maybe it should be kept separate. We should definitely bring all the work together into a consistent API. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote: Here are the QDrive APIs that Tony mentioned below: https://codereview.qt-project.org/#change,75336,patchset=1 Cool. But I think maybe we should get the C++ APIs into qtbase, so that QtQuick.Controls.FileDialog doesn't depend on qtsystems. So does that mean we need the watchers added on top of https://codereview.qt-project.org/#change,73945 ? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote: Here are the QDrive APIs that Tony mentioned below: https://codereview.qt-project.org/#change,75336,patchset=1 Cool. But I think maybe we should get the C++ APIs into qtbase, so that QtQuick.Controls.FileDialog doesn't depend on qtsystems. So does that mean we need the watchers added on top of https://codereview.qt- project.org/#change,73945 ? Yes. To decide: - does it all into qtbase (ie yes!) - do we want QDrive and QDriveInfo separate or together as one class - naming - ie use the same naming throughout - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
1) well, it can go to qt base, but what module? We can't add mount and monitor to qtcore, because Linux implementation will require dbus. 2) separate, see above. Drive info should belong to qt core, IMHO. Иван Комиссаров 13 янв. 2014 г., в 21:53, Tony Van Eerd tvane...@blackberry.com написал(а): On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote: Here are the QDrive APIs that Tony mentioned below: https://codereview.qt-project.org/#change,75336,patchset=1 Cool. But I think maybe we should get the C++ APIs into qtbase, so that QtQuick.Controls.FileDialog doesn't depend on qtsystems. So does that mean we need the watchers added on top of https://codereview.qt- project.org/#change,73945 ? Yes. To decide: - does it all into qtbase (ie yes!) - do we want QDrive and QDriveInfo separate or together as one class - naming - ie use the same naming throughout - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
1) well, it can go to qt base, but what module? We can't add mount and monitor to qtcore, because Linux implementation will require dbus. I'm not familiar with the details there, can you briefly explain why dbus is necessary and why it is a bad thing for qtcore? 2) separate, see above. Drive info should belong to qt core, IMHO. Иван Комиссаров To decide: - does it all into qtbase (ie yes!) - do we want QDrive and QDriveInfo separate or together as one class - naming - ie use the same naming throughout - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On segunda-feira, 13 de janeiro de 2014 18:04:24, Tony Van Eerd wrote: 1) well, it can go to qt base, but what module? We can't add mount and monitor to qtcore, because Linux implementation will require dbus. I'm not familiar with the details there, can you briefly explain why dbus is necessary and why it is a bad thing for qtcore? To get the right information from udev, you need to either use its lib or to listen via D-Bus. Using D-Bus from QtCore creates a dependency reversal due to QtDBus. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday 13 January 2014 18:04:24 Tony Van Eerd wrote: 1) well, it can go to qt base, but what module? We can't add mount and monitor to qtcore, because Linux implementation will require dbus. I'm not familiar with the details there, can you briefly explain why dbus is necessary and why it is a bad thing for qtcore? QtCore can't link to QtDBus, since QtDBus links to QtCore. Mounting can still be done with `mount`, no? Notifications mean listening to dbus signals though, indeed. Tricky. Maybe by using libdbus directly, but this contradicts the long term plan of not using libdbus in QtDBus (AFAIK). -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
I think, mount requires root privileges, doesn't it? Not sure about libudev, maybe it can be used from userspace... Иван Комиссаров 13 янв. 2014 г., в 22:17, David Faure david.fa...@kdab.com написал(а): On Monday 13 January 2014 18:04:24 Tony Van Eerd wrote: 1) well, it can go to qt base, but what module? We can't add mount and monitor to qtcore, because Linux implementation will require dbus. I'm not familiar with the details there, can you briefly explain why dbus is necessary and why it is a bad thing for qtcore? QtCore can't link to QtDBus, since QtDBus links to QtCore. Mounting can still be done with `mount`, no? Notifications mean listening to dbus signals though, indeed. Tricky. Maybe by using libdbus directly, but this contradicts the long term plan of not using libdbus in QtDBus (AFAIK). -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday, January 13, 2014 10:32:12 PM abba...@gmail.com wrote: I think, mount requires root privileges, doesn't it? Not if the entry is present in fstab, with the option user or users. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On 2014-01-13, David Faure david.fa...@kdab.com wrote: Mounting can still be done with `mount`, no? Only in rare cases. Normally on linux from a user app you would call out to udisks, who would connect to polkit and have polkit maybe query you and other magic. Notifications mean listening to dbus signals though, indeed. Tricky. Maybe by using libdbus directly, but this contradicts the long term plan of not using libdbus in QtDBus (AFAIK). In order to not do it half-assed and in a way that only works for your app run as root, you do need dbus on linux. I don't know how it is done on windows and mac. Though mounting/unmounting drives is in general not something I would expect an application to do, but rather something that happens in the workspace, be it Windows, Gnome or OSX. For the specific case of mounting stuff from the file dialog, maybe it should be even easier to call out to a system file dialog, like the QFileDialog::getSomething function does. If that can be done somehow, then I only think we have the 'dedicated system information / system manipulation apps' left, and I'm not sure that I think that it is a usecase that Qt should try to solve in qtbase, but rather keep it around as an extra addon. /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
2014/1/13 David Faure david.fa...@kdab.com On Monday, January 13, 2014 10:32:12 PM abba...@gmail.com wrote: I think, mount requires root privileges, doesn't it? Not if the entry is present in fstab, with the option user or users. Still, what about volumes (|un)mounting of which requires higher privileges than the user has? Should we ever care about them? /* IMO, we shouldn't. */ Regards, Konstantin -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday, 2014-01-13, 22:00:53, abba...@gmail.com wrote: 1) well, it can go to qt base, but what module? We can't add mount and monitor to qtcore, because Linux implementation will require dbus. I think this will come up again and again until there is a QPA like platform adapter on the QtCore level. D-Bus simply is *the* system integration technology on Linux, QtCore will need to be able to do D-Bus at runtime. Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On segunda-feira, 13 de janeiro de 2014 21:28:05, Kevin Krammer wrote: D-Bus simply is *the* system integration technology on Linux, QtCore will need to be able to do D-Bus at runtime. That will always require plugins. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Monday, 2014-01-13, 12:37:54, Thiago Macieira wrote: On segunda-feira, 13 de janeiro de 2014 21:28:05, Kevin Krammer wrote: D-Bus simply is *the* system integration technology on Linux, QtCore will need to be able to do D-Bus at runtime. That will always require plugins. Yes, but QPA is a plugin based system already anyway. We've seen the same need with PPS on QNX. The system's main IPC system just needs to be available to code in QtCore if the system's integration API is based on IPC. The alternative to platform plugins is to put all those IPC basics into QtCore itself, like what was done for PPS. I.e. moving parts of QtDBus into QtCore. Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On segunda-feira, 13 de janeiro de 2014 21:48:22, Kevin Krammer wrote: The alternative to platform plugins is to put all those IPC basics into QtCore itself, like what was done for PPS. I.e. moving parts of QtDBus into QtCore. We could do that, though I'd rather not. The basics for kdbus will be quite big, since we'll do it without help from a system library. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote: On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. I would like to at least have something like QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog. (QDir::drives() provides drive letters on Windows but not mount points on Linux, which is asymmetric IMO.) The reason is to have similar functionality on operating systems which will rely on the QML FileDialog as on Windows and OSX: when you plug in a removable drive, or mount a network drive, there should be a shortcut to access it in the file dialog. So where should we start, and how much should we try to bring over in the first pass? Is anyone else interested in working on patches for that? If it doesn't have public QML API, that's OK for now, because I have some C++ support code for the dialogs anyway. But maybe we should try to bring back (and improve) some of the QML APIs too? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
There was some work going on inside BlackBerry to revamp QSystemStorageInfo. Last version I saw had: QDrive: - similar to QDir (not a QObject!). - construct from URI/path (ie dev/sda1 or D:\) - mount/unmount/is-it-mounted/list-of-mount-points/etc - total/available space QDriveWatcher: - QObject, constructed from a QDrive (or uri/path) - Signals when a particular drive is mounted/unmounted - also signals on activity-state changes (ie for SD Cards 'busy', etc) QDriveListWatcher - get list of drives - signal when drives are added/removed Maybe we can get it put up for review... P.S. note that Windows (NTFS) now has real mount points, as well as D:,E:,... -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Rutledge Shawn Sent: Friday, January 10, 2014 11:15 AM To: Lorn Potter; development@qt-project.org; David Faure; Alan Alpert Subject: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote: On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. I would like to at least have something like QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog. (QDir::drives() provides drive letters on Windows but not mount points on Linux, which is asymmetric IMO.) The reason is to have similar functionality on operating systems which will rely on the QML FileDialog as on Windows and OSX: when you plug in a removable drive, or mount a network drive, there should be a shortcut to access it in the file dialog. So where should we start, and how much should we try to bring over in the first pass? Is anyone else interested in working on patches for that? If it doesn't have public QML API, that's OK for now, because I have some C++ support code for the dialogs anyway. But maybe we should try to bring back (and improve) some of the QML APIs too? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Friday, January 10, 2014, Tony Van Eerd wrote: There was some work going on inside BlackBerry to revamp QSystemStorageInfo. Last version I saw had: QDrive: - similar to QDir (not a QObject!). - construct from URI/path (ie dev/sda1 or D:\) - mount/unmount/is-it-mounted/list-of-mount-points/etc - total/available space QDriveWatcher: - QObject, constructed from a QDrive (or uri/path) - Signals when a particular drive is mounted/unmounted - also signals on activity-state changes (ie for SD Cards 'busy', etc) QDriveListWatcher - get list of drives - signal when drives are added/removed Maybe we can get it put up for review... Yes please :) Matt P.S. note that Windows (NTFS) now has real mount points, as well as D:,E:,... -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org javascript:; [mailto:development-bounces+tvaneerd javascript:;= rim@qt-project.org javascript:;] On Behalf Of Rutledge Shawn Sent: Friday, January 10, 2014 11:15 AM To: Lorn Potter; development@qt-project.org javascript:;; David Faure; Alan Alpert Subject: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote: On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. I would like to at least have something like QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog. (QDir::drives() provides drive letters on Windows but not mount points on Linux, which is asymmetric IMO.) The reason is to have similar functionality on operating systems which will rely on the QML FileDialog as on Windows and OSX: when you plug in a removable drive, or mount a network drive, there should be a shortcut to access it in the file dialog. So where should we start, and how much should we try to bring over in the first pass? Is anyone else interested in working on patches for that? If it doesn't have public QML API, that's OK for now, because I have some C++ support code for the dialogs anyway. But maybe we should try to bring back (and improve) some of the QML APIs too? ___ Development mailing list Development@qt-project.org javascript:; http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org javascript:; http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
https://codereview.qt-project.org/73945 Regards, Konstantin 2014/1/10 Matt Broadstone mbroa...@gmail.com On Friday, January 10, 2014, Tony Van Eerd wrote: There was some work going on inside BlackBerry to revamp QSystemStorageInfo. Last version I saw had: QDrive: - similar to QDir (not a QObject!). - construct from URI/path (ie dev/sda1 or D:\) - mount/unmount/is-it-mounted/list-of-mount-points/etc - total/available space QDriveWatcher: - QObject, constructed from a QDrive (or uri/path) - Signals when a particular drive is mounted/unmounted - also signals on activity-state changes (ie for SD Cards 'busy', etc) QDriveListWatcher - get list of drives - signal when drives are added/removed Maybe we can get it put up for review... Yes please :) Matt P.S. note that Windows (NTFS) now has real mount points, as well as D:,E:,... -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Rutledge Shawn Sent: Friday, January 10, 2014 11:15 AM To: Lorn Potter; development@qt-project.org; David Faure; Alan Alpert Subject: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote: On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. I would like to at least have something like QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog. (QDir::drives() provides drive letters on Windows but not mount points on Linux, which is asymmetric IMO.) The reason is to have similar functionality on operating systems which will rely on the QML FileDialog as on Windows and OSX: when you plug in a removable drive, or mount a network drive, there should be a shortcut to access it in the file dialog. So where should we start, and how much should we try to bring over in the first pass? Is anyone else interested in working on patches for that? If it doesn't have public QML API, that's OK for now, because I have some C++ support code for the dialogs anyway. But maybe we should try to bring back (and improve) some of the QML APIs too? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Fri, Jan 10, 2014 at 1:31 PM, Konstantin Ritt ritt...@gmail.com wrote: https://codereview.qt-project.org/73945 I looked at this, but it lacks the extra functionality that Tony indicates is in their classes. Specifically, not just info about the drive/device, but the ability to mount/unmount the devices as well as the ability to watch for changes. In a perfect world it looks like his classes could be merged in, and modified to use the QDriveInfo class in this review. Matt Regards, Konstantin 2014/1/10 Matt Broadstone mbroa...@gmail.com On Friday, January 10, 2014, Tony Van Eerd wrote: There was some work going on inside BlackBerry to revamp QSystemStorageInfo. Last version I saw had: QDrive: - similar to QDir (not a QObject!). - construct from URI/path (ie dev/sda1 or D:\) - mount/unmount/is-it-mounted/list-of-mount-points/etc - total/available space QDriveWatcher: - QObject, constructed from a QDrive (or uri/path) - Signals when a particular drive is mounted/unmounted - also signals on activity-state changes (ie for SD Cards 'busy', etc) QDriveListWatcher - get list of drives - signal when drives are added/removed Maybe we can get it put up for review... Yes please :) Matt P.S. note that Windows (NTFS) now has real mount points, as well as D:,E:,... -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Rutledge Shawn Sent: Friday, January 10, 2014 11:15 AM To: Lorn Potter; development@qt-project.org; David Faure; Alan Alpert Subject: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote: On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. I would like to at least have something like QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog. (QDir::drives() provides drive letters on Windows but not mount points on Linux, which is asymmetric IMO.) The reason is to have similar functionality on operating systems which will rely on the QML FileDialog as on Windows and OSX: when you plug in a removable drive, or mount a network drive, there should be a shortcut to access it in the file dialog. So where should we start, and how much should we try to bring over in the first pass? Is anyone else interested in working on patches for that? If it doesn't have public QML API, that's OK for now, because I have some C++ support code for the dialogs anyway. But maybe we should try to bring back (and improve) some of the QML APIs too? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
2014/1/10 Matt Broadstone mbroa...@gmail.com
On Fri, Jan 10, 2014 at 1:31 PM, Konstantin Ritt ritt...@gmail.comwrote:
https://codereview.qt-project.org/73945
I looked at this, but it lacks the extra functionality that Tony indicates
is in their classes. Specifically, not just info about the drive/device,
but the ability to mount/unmount the devices as well as the ability to
watch for changes. In a perfect world it looks like his classes could be
merged in, and modified to use the QDriveInfo class in this review.
QDriveInfo is indeed a drive info class. Won't you find it surprising if
QFileInfo has a QFile read/write functionality? That's a reason to not
mount/unmount drives from QDriveInfo. And even if it were a QDrive, the
other reason is that that mount/unmount may require a higher privileges
that the user's ones. So we decided to separate the functionality to the
informative-only QDriveInfo and the operational
QDrive{Controller|Watcher} or whatever name we'll choose for it.
@Tony: Could you plz share a link to your QDrive* sources?
Regards,
Konstantin
Matt
Regards,
Konstantin
2014/1/10 Matt Broadstone mbroa...@gmail.com
On Friday, January 10, 2014, Tony Van Eerd wrote:
There was some work going on inside BlackBerry to revamp
QSystemStorageInfo. Last version I saw had:
QDrive:
- similar to QDir (not a QObject!).
- construct from URI/path (ie dev/sda1 or D:\)
- mount/unmount/is-it-mounted/list-of-mount-points/etc
- total/available space
QDriveWatcher:
- QObject, constructed from a QDrive (or uri/path)
- Signals when a particular drive is mounted/unmounted
- also signals on activity-state changes (ie for SD Cards 'busy', etc)
QDriveListWatcher
- get list of drives
- signal when drives are added/removed
Maybe we can get it put up for review...
Yes please :)
Matt
P.S. note that Windows (NTFS) now has real mount points, as well as
D:,E:,...
-Original Message-
From: development-bounces+tvaneerd=rim@qt-project.org
[mailto:development-bounces+tvaneerd=rim@qt-project.org] On
Behalf
Of Rutledge Shawn
Sent: Friday, January 10, 2014 11:15 AM
To: Lorn Potter; development@qt-project.org; David Faure; Alan
Alpert
Subject: [Development] moving some SystemInfo stuff into qtbase (was
Re: QtDriveInfo module in Playground)
On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote:
On 02/03/13 07:59, Thiago Macieira wrote:
On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote:
Wasn't there already similar functionality in QtMobility?
QSystemStorageInfo seems to provide similar functionality?
Yes it does.
Or did all
that get scrapped in Qt 5?
It's there in qtsystems, which is a hidden module.
As I said before when QSystemStorageInfo came about, I think the
functionality
belongs in QtCore. With less emphasis in QML and mobile, of course.
systeminfo works on all platforms, mobile or not.
The udisks functionality would have to be removed if moved to core.
I would like to at least have something like
QSystemStorageInfo::logicalDrives() to use in building the QML
FileDialog. (QDir::drives() provides drive letters on Windows but not
mount points on Linux, which is asymmetric IMO.) The reason is to
have
similar functionality on operating systems which will rely on the QML
FileDialog as on Windows and OSX: when you plug in a removable drive,
or mount a network drive, there should be a shortcut to access it in
the file dialog. So where should we start, and how much should we try
to bring over in the first pass? Is anyone else interested in working
on patches for that?
If it doesn't have public QML API, that's OK for now, because I have
some C++ support code for the dialogs anyway. But maybe we should try
to bring back (and improve) some of the QML APIs too?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from
your system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be
unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
We will put up our stuff into a review next week. Currently it is mostly
header/API only, no implementation files. We are just trying to get the API
designed.
We looked at QDriveInfo (either that one or similar one of the same name) and,
basically, stole many ideas from it. Ours was also called QDriveInfo until
we decided to add non-info stuff like mounting. But maybe it should be kept
separate. We should definitely bring all the work together into a consistent
API.
From: Konstantin Ritt [mailto:ritt...@gmail.com]
Sent: Friday, January 10, 2014 2:00 PM
To: Matt Broadstone
Cc: Tony Van Eerd; Alvin Yulo; David Faure; Rutledge Shawn; Alan Alpert;
development@qt-project.org
Subject: Re: [Development] moving some SystemInfo stuff into qtbase (was Re:
QtDriveInfo module in Playground)
2014/1/10 Matt Broadstone mbroa...@gmail.commailto:mbroa...@gmail.com
On Fri, Jan 10, 2014 at 1:31 PM, Konstantin Ritt
ritt...@gmail.commailto:ritt...@gmail.com wrote:
https://codereview.qt-project.org/73945
I looked at this, but it lacks the extra functionality that Tony indicates is
in their classes. Specifically, not just info about the drive/device, but the
ability to mount/unmount the devices as well as the ability to watch for
changes. In a perfect world it looks like his classes could be merged in, and
modified to use the QDriveInfo class in this review.
QDriveInfo is indeed a drive info class. Won't you find it surprising if
QFileInfo has a QFile read/write functionality? That's a reason to not
mount/unmount drives from QDriveInfo. And even if it were a QDrive, the other
reason is that that mount/unmount may require a higher privileges that the
user's ones. So we decided to separate the functionality to the
informative-only QDriveInfo and the operational QDrive{Controller|Watcher}
or whatever name we'll choose for it.
@Tony: Could you plz share a link to your QDrive* sources?
Regards,
Konstantin
Matt
Regards,
Konstantin
2014/1/10 Matt Broadstone mbroa...@gmail.commailto:mbroa...@gmail.com
On Friday, January 10, 2014, Tony Van Eerd wrote:
There was some work going on inside BlackBerry to revamp QSystemStorageInfo.
Last version I saw had:
QDrive:
- similar to QDir (not a QObject!).
- construct from URI/path (ie dev/sda1 or D:\)
- mount/unmount/is-it-mounted/list-of-mount-points/etc
- total/available space
QDriveWatcher:
- QObject, constructed from a QDrive (or uri/path)
- Signals when a particular drive is mounted/unmounted
- also signals on activity-state changes (ie for SD Cards 'busy', etc)
QDriveListWatcher
- get list of drives
- signal when drives are added/removed
Maybe we can get it put up for review...
Yes please :)
Matt
P.S. note that Windows (NTFS) now has real mount points, as well as D:,E:,...
-Original Message-
From: development-bounces+tvaneerd=rim@qt-project.org
[mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf
Of Rutledge Shawn
Sent: Friday, January 10, 2014 11:15 AM
To: Lorn Potter; development@qt-project.org; David Faure; Alan Alpert
Subject: [Development] moving some SystemInfo stuff into qtbase (was
Re: QtDriveInfo module in Playground)
On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote:
On 02/03/13 07:59, Thiago Macieira wrote:
On sábado, 2 de março de 2013 07.51.04tel:2013%2007.51.04, Lorn Potter
wrote:
Wasn't there already similar functionality in QtMobility?
QSystemStorageInfo seems to provide similar functionality?
Yes it does.
Or did all
that get scrapped in Qt 5?
It's there in qtsystems, which is a hidden module.
As I said before when QSystemStorageInfo came about, I think the
functionality
belongs in QtCore. With less emphasis in QML and mobile, of course.
systeminfo works on all platforms, mobile or not.
The udisks functionality would have to be removed if moved to core.
I would like to at least have something like
QSystemStorageInfo::logicalDrives() to use in building the QML
FileDialog. (QDir::drives() provides drive letters on Windows but not
mount points on Linux, which is asymmetric IMO.) The reason is to have
similar functionality on operating systems which will rely on the QML
FileDialog as on Windows and OSX: when you plug in a removable drive,
or mount a network drive, there should be a shortcut to access it in
the file dialog. So where should we start, and how much should we try
to bring over in the first pass? Is anyone else interested in working
on patches for that?
If it doesn't have public QML API, that's OK for now, because I have
some C++ support code for the dialogs anyway. But maybe we should try
to bring back (and improve) some of the QML APIs too?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-
This transmission (including any attachments) may
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
I also had a drive monitor class https://gitorious.org/qdrive/qdrive/source/bf9f993ec64781534169a7ac630632805ef34374:src/driveinfo/qdrivecontroller.h but it needs a bit polishing Иван Комиссаров 11 янв. 2014 г., в 0:28, Tony Van Eerd tvane...@blackberry.com написал(а): We will put up our stuff into a review next week. Currently it is mostly header/API only, no implementation files. We are just trying to get the API designed. We looked at QDriveInfo (either that one or similar one of the same name) and, basically, stole many ideas from it. Ours was also called QDriveInfo until we decided to add non-info stuff like mounting. But maybe it should be kept separate. We should definitely bring all the work together into a consistent API. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
