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

[Rutledge Shawn]

On 13 Jan 2014, at 8:06 PM, David Faure wrote:

> On Monday 13 January 2014 22:00:53 abbapoh at 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.