[Development] call for comments/review QSystemInfo::NetworkInfo API

Simon Hausmann simon.hausmann at digia.com
Wed Sep 24 07:57:07 CEST 2014


On Wednesday, September 24, 2014 11:02:26 AM Lorn Potter wrote:
> Hi *,
> 
> While looking into a bug
> https://bugreports.qt-project.org/browse/QTBUG-41283
> 
> It reminded me that I am not happy with NetworkInfo since it got ported from
> QtMobility to Qt 5.
> 
> 
> *Note* QSystemInfo is not officially supported API.
> 
> Since I am maintainer for it and it's not "released", I am going to change
> it.
> 
> For one, I really wish the whole QtSystemInfo code were a separate module
> and not lumped in with two other completely unrelated modules - publish &
> subscribe and serviceframework.
> 
> 
> If anyone wants to help review/revise this API, take a look (or any other
> QtSystemInfo API's)
> 
> https://qt.gitorious.org/qt/qtsystems/source/aa651c73bf7bc57c1b6b1bfcfa9afe9
> 01884a102:src/systeminfo/qnetworkinfo.h
> 
> comments/suggestions welcome.

I wonder if the"int interface" indexed API is tedious to use. Say you do 
manage to get a QNetworkInterface object from QtNetwork, then before you can 
call for example

    QString imsi(int interface) const;

you have to retrieve the index() from the network interface first. It feels 
like a very procedural API.

Half of the "getters" would IMO be a nicer fit if they were part of the 
QNetworkInterface API. Then they would make for a really nice property based 
API - and we just may have to delegate some functionality into plugins 
implementation wise?

When it comes to the notification signals I also wonder if it would be better 
to have a QNetworkInterfaceMonitor alike class in QtNetwork that supplies the 
notifications (for an interface mask perhaps).


>From a 10000 feet Qt as a product point of view, it's not evident why this API 
belongs into a separate module instead of simply into the Qt network module.


Simon



More information about the Development mailing list