[Development] New Module Request: QtGeniviExtras

Dominik Holland dominik.holland at pelagicore.com
Wed Aug 12 09:55:14 CEST 2015



On 08/11/2015 05:51 PM, Thiago Macieira wrote:
> On Tuesday 11 August 2015 09:59:19 Dominik Holland wrote:
>> Hi,
>>
>> i would like to request a new qt module repository for QtGeniviExtras.
>>
>> The current code can be found here:
>> https://github.com/Pelagicore/qtgeniviextras
>>
>> The goal of QtGeniviExtras is similar to QtWinExtras or QtMacExtras and
>> provides Platform dependent Qt additions. In this case for the GENIVI
>> platform.
>>
>> GENIVI is an alliance which tries to develop an open standard for IVI
>> systems. More information can be found here (http://www.genivi.org/)
>>
>> Currently the QtGeniviExtras module only contains one component called
>> QDLT which is a Qt Categorized Logging Binding towards GENIVI DLT
>> (Diagnostic Log and Trace)
>>
>> In the future this repository could also contain more GENIVI specific
>> APIs like a autogenerator for GENIVI's CommonAPI (IPC Abstraction)
>>
>> As the module should be well accepted within GENIVI as well the module
>> is currently licensed under LGPLv2.1
> 
> Hello Dominik
> 
> I think the idea of having API wrapping some of GENIVI's functionality is 
> good. How soon will you begin working on the CommonAPI?


Currently it's not planned as we currently don't have any project where
this is needed. Just looking at CommonAPI and how the code-generation
currently works there it also means a little bit more work if we want to
get rid of the eclipse dependency which it currently seems to have.

> 
> But I can't give a +1 right now for the API you have of DLT. That looks like 
> something Qt should automatically be doing. Have you explored that 
> possibility? Can you explain why it shouldn't / couldn't be done like that?
> 

In general you are right. It would be really nice if we could use
QLoggingCategories straight away without any change, but the biggest
problem is the way how DLT works.

Every Process which wants to log using DLT needs to provide information
about it's Application, this needs to be a 4 characters long unique
identifier and a Description for it.

QDLT_REGISTER_APPLICATION does that for us.

Every LoggingCategory (In DLT it's called Context) needs to have a 3
characters long unique identifier and a Description.

I think the Description is not that hard to get (or not mandatory), but
the 3 or 4 characters long identifiers are a blocker and nothing we can
change as they are required by the DLT protocol. QLoggingCategories
already have the categoryName which could act as a identifier, but the
Developer would need to know that he is only allowed to use 3 characters
here to make it usable by DLT. It also feels a bit awkward to use the
enable it using the env variable:

QT_LOGGING_RULES=inp.debug=true;gca.debug=false


The current idea of the wrapper is to make the use of DLT explicit for
the Developer, but at the same time make it easy to transition or don't
use it at all.

If we want to fully support DLT there is no way to not have a DLT
specific API, as DLT also support so called injection messages. A Qt
Application would be able register for a specific injection message and
react once it got it (it's basically a IPC using the DLT channel).

On the other side you can write a plugin for the DLT Viewer application
which can send these injection messages to control the Application (e.g.
calling a factor reset of a specific component because your navigation
sub system doesn't work anymore)


-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holland at pelagicore.com
www.pelagicore.com




More information about the Development mailing list