2014/1/10 Matt Broadstone <mbroa...@gmail.com> > 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. > > 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 >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development