[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