[Development] New Module for Serial Buses

Frederik Gladhorn frederik.gladhorn at theqtcompany.com
Thu May 28 17:16:22 CEST 2015

On Thursday, May 28, 2015 01:35:17 PM Marc Mutz wrote:
> On Tuesday 26 May 2015 15:33:59 Viironen Kalle wrote:
> > For naming we have thought either QtBus or QtSerialBus. IMO name as such
> > should already on it’s own describe the generalised idea of the module.
> What use-case do you have in mind where the programmer doesn't know that
> he's talking to a CAN bus? Or an i2c one? Or, for that matter, to a KNX
> bus?
> Sure, there are apps that generically will talk to any bus as long as
> there's a Qt plugin for it, but those apps should implement the abstraction
> layer themselves, as fits their needs.
> Please don't overengineer this. If this is about CAN, call it QtCanBus. If
> it's about i2c, call it QtI2cBus. These are separate libraries. You get the
> idea. This is not like the web (ftp, http, ...) where there's an established
> abstraction (URLs) and the vast majority of applications shouldn't care
> about the actual protocol underlying a URL (thus, QNAM is ok, even though I
> note that it loses functionality compared to QHttp, just as QHostInfo lost
> functionality compared to QDns).
> I don't know about CAN, but taking KNX as an example I know well, you want
> (preferably static, as opposed to type-erased) access to the KNX data
> formats and group addresses. Yes, all the way up to QML, not just C++.

My understanding is that the goal is to be able to share code, in the end we 
should still end up with several classes handling specific buses, but also a 
shared repository and not re-inventing all of the implementations from scratch 
for each new bus type.


> QAbstactSocket is listed in the Wiki as a design mistake.
> Don't repeat it, please.
> Thanks,
> Marc

More information about the Development mailing list