[Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Konstantin Ritt]

2014/1/10 Matt Broadstone <mbroadst at gmail.com>

> On Fri, Jan 10, 2014 at 1:31 PM, Konstantin Ritt <ritt.ks at 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 <mbroadst at 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.com at qt-project.org
>>>> > [mailto:development-bounces+tvaneerd=rim.com at qt-project.org] On
>>>> Behalf
>>>> > Of Rutledge Shawn
>>>> > Sent: Friday, January 10, 2014 11:15 AM
>>>> > To: Lorn Potter; <development at 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 at 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 at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>
>>>
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140110/35b5f34e/attachment.html>