[Development] Proposal: reorganization of QtSystems module, since Qt5.x

[Denis Shienkov]

Hello Lorn,

> Because printing is a common and basic thing to want to add to applications. Getting info and notifications about cellId changes is more of a fringe use case.

Yes, it is, clear. But then why not add ScannerSupport? After all, this is the same as the printing support. :) 

For addition (for not change printing support) to the QtSystems can be duplicated support QPrinterInfo, QScannerInfo, 
QPlotterInfo and so forth, with extended parameters, with plug/unplug notification support, change parameters
notification support and so forth (if available).

> I don't understand why I would need information about manufacturer, model of the computer (from QDeviceInfo) when I want to get information about the network or storage?

This is not a problem ... In addition to the manufacturer, PID / VID, description, you can get more specific information.
E.g. for QStorageInfo you can get partitions, size, and so forth; for QBatteryInfo - voltage level, accumulator type and and so forth;
for QMonitorInfo - resolution, bit depth and so forth, and etc...

> I think you may misunderstand 'device' in DeviceInfo. It is one computer - desktop, laptop, or mobile phone, and not really a peripheral like you are proposing.

Not. Renaming of the essence does not change. Under the device I understand all the peripherals, internals, etc. devices. which are part of Laptop, PC, Mobile phone and so forth.
And which are detected by OS as separate devices. I do not division devices entities on peripherals or not, as all this is the common - device entity! 
And on the type/class - is a peripheral-in, internal, etc. I.e. base class - device! (I think I'm clearly expressed.)

> This is more than extended it.

Yes. :)

> Even though they are distinct types and use-cases for this information? 

This eliminates duplicate code when enumerating of devices or at notification of plug/unplug, because this can be a single class, 
in which we simply register desired device. 

> Having one grand class/signal for all this information is too much, and not object oriented.

Why? it is an object oriented, at least this is true for the watcher class. IMHO. 

Although, yes, for the enumeration of devices and get Info, can be used QDeviceInfo class, like
static method:

QList<QDeviceInfo > QDeviceInfo::availableDevices();

i.e. like:

QList<QMonitorInfo> QMonitorInfo::availableDevices();
QList<QBatteryInfo> QBatteryInfo::availableDevices();
...
QList<QStorageInfo> QStorageInfo::availableDevices();

Where QMonitorInfo, QBatteryInfo ... is separate classes.

QDeviceManager can register any of the types/classes of devices for tracking plug/unplug, 
also can have static method, like:

QList<QDeviceInfo> QDeviceManager::devices(DeviceType dt = AllTypes) 
{
    QList<QDeviceInfo> list;

    switch (dt)
    {
    case BatteryDeviceClass:
        list.append(QBatteryInfo::availableDevices());
        break;
    ...
    ...

    case AllDeviceClass:
        list.append(QBatteryInfo::availableDevices());
        ....
        list.append(QStorageInfo::availableDevices());
        ....
        break;
    }

    return list.
}

Next can do so:

foreach(const QDeviceInfo &info, list)
{
    // common methods
    qDebug() << info->description();
    qDebug() << info->manufacturer();
    ...
    qDebug() << info->vendorIdentifier();

    // custom methods

    if (info->class() == BatteryDeviceClass) {

        BatteryDeviceClass batteryInfo = static_cast<BatteryDeviceClass >(info);

        qDebug() << batteryInfo->batteryInfoMethod1();
        qDebug() << batteryInfo->batteryInfoMethod2();
   
    }

}

Or something like that, can on templates somehow implement. I'm just suggesting the idea. :)




Best regards,
Denis



14.09.2012, 00:03, "Lorn Potter" <lorn.potter at gmail.com>:
> Hi Denis,
>
> On 13/09/2012, at 8:27 PM, Denis Shienkov <scapig2 at yandex.ru> wrote:
>
>>  Hello all.
>>
>>  As I'm concerned, at the moment Qt5 contains fragmented set of classes to
>>  obtain information about the devices:
>>
>>  QPrinterInfo   -> QtBase/src/printsupport
>>  others info's  -> QtSystems/
>
> Because printing is a common and basic thing to want to add to applications. Getting info and notifications about cellId changes is more of a fringe use case.
>
>>  Since all of these entities are devices, it is logical to make the base
>>  class QDeviceInfo, from which derive all of the specific types of devices
>>  infos, like:
>
> No, these aren't devices, they are peripherals.
>
>>  class QDeviceInfo : public QObject
>>  {
>>  ...
>>  }
>>
>>  class QStorageInfo : public QDeviceInfo
>>  {
>>  ...
>>  }
>>
>>  ...
>>  ...
>>
>>  class QNetworkAdapterInfo : public QDeviceInfo
>>  {
>>  ...
>>  }
>
> I don't understand why I would need information about manufacturer, model of the computer (from QDeviceInfo) when I want to get information about the network or storage?
>
>>  Next, can create a separate class - watcher type QDeviceManeger (singleton),
>>  which could provide a list of all available devices to send signals about
>>  connecting/disconnecting devices, etc.
>
> I think you may misunderstand 'device' in DeviceInfo. It is one computer - desktop, laptop, or mobile phone, and not really a peripheral like you are proposing.
>
>>  class QDeviceManager : public QObject
>>  {
>>  public:
>>
>>     enum DeviceType {
>>         SerialPort,
>>         LptPort,
>>         MidiPort,
>>         NetworkAdapter,
>>         VideoAdapter,
>>         AudioAdapter,
>>         Monitor,
>>         Drive,
>>         ...
>>         AllTypes
>>     };
>>
>>     QList<QDeviceInfo> devicesInfo(DeviceType dt = AllTypes);
>>     void enableWatchForType(DeviceType dt = AllTypes);
>>     bool isEnabledWatchForType(DeviceType dt = AllTypes);
>>
>>     // Maybe add another methods
>>
>>  signals:
>>     void connected(const QDeviceInfo &info);
>>     void disconnected(const QDeviceInfo &info);
>>
>>     // Maybe add another signals
>>  }
>>
>>  For a start here can add only the basic types of devices (already implemented),
>>  and then on future can add new supported device types (step-by-step).
>>
>>  This is just pseudocode, I know that it contains errors. I just proposed the idea,
>>  so please do not judge strictly.
>>
>>  Pros:
>>  + QtSystems module is already available, you just need to extend it.
>
> This is more than extended it.
>
>>  + This solution will integrate all the disparate components of information in
>>  one place.
>
> Even though they are distinct types and use-cases for this information?
> Having one grand class/signal for all this information is too much, and not object oriented.
>
>>  + Flexibility: you want - include the module, and you want - not.
>>  + Common notifier for all devices in which you can register and subscribe to
>>  events on the desired device type.
>>
>>  Cons:
>>  - To use printing support need for a separate module QtSystems. Although previously
>>  it was not required.
>>  - Implementation is complex.
>>
>>  I'm waiting for comments and suggestions. :)
>>
>>  Best regards,
>>  Denis
>>  _______________________________________________
>>  Development mailing list
>>  Development at qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> Lorn Potter
> Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo