Public Support

Now I think i found out each remaining former Qt releated string and replace for an upcoming delivery!

Hi Florian,

concerning the CIDs: please consider the device toolbox updates also in the ARXML Toolbox example project. (In the one delivered to Wolfgang the old CIDs of CAN substream ... filter were used).

Concerning renaming of components. I would appreciate if one could also be more conservative here. We have marketing documents and training documents that mention certain filter and service names. Then similar things could apply in project documentation. And then these documents should not only fit to the users of a specific version of ADTF or a toolbox but for some recent range of versions.
What would be a decent concept for naming a specific filter/service in such a document without making it version specific?

I do not fully understand why renaming Qt ... to Qt5 ... or Qt6 ... is important in any way.

BR,
Jochen

Hi Jochen,

concerning the CIDs: please consider the device toolbox updates also in the ARXML Toolbox example project. (In the one delivered to Wolfgang the old CIDs of CAN substream ... filter were used).

OK, I will have a look at it, thanks!

Concerning renaming of components. I would appreciate if one could also be more conservative here. We have marketing documents and training documents that mention certain filter and service names. Then similar things could apply in project documentation. And then these documents should not only fit to the users of a specific version of ADTF or a toolbox but for some recent range of versions.
What would be a decent concept for naming a specific filter/service in such a document without making it version specific?

To be fair, this is a different approach to our business, our documentation and training is always version specific.
But for now, I will have this is my mind and will have an eye on it before changing.
For now, the label names seem good to me and I dont see any changes.

I do not fully understand why renaming Qt ... to Qt5 ... or Qt6 ... is important in any way.

The issue was, we have a mix of with and without Qt Prefix and other components with or without ADTF prefix.
This was important to harmonize that and we use it, to use Qt5 instead of Qt for all.
Because when we create a Qt6 dependent XSystem and components, then the user can differ (as mentioned, cannot be upgraded from qt5 to qt6 without breaking binary comptaibility).
But this is future.

Hi Florian,

yeah guess we have a different approach with terminology. Updating terminology is a more involved process here with many different people and company internal terminology database involved. So for ADTF 2 (from version 2.9) I do not remember any significant naming update.

I was browsing a little bit further in the guide and here https://support.digitalwerk.net/adtf/v3/guides/sdk_properties_filter.html there is also the "Demo Media Description Display" in the video and "Qt Media Description Display" in the text. So I somehow would assume further locations that need to be updated.

From training side, I still think it would be not a good approach that people have to learn different names every now and then ... (ok guess it does not go so far yet that user of different ADTF 3 minor versions do not understand each other).

You see my preference for a naming that reduces the update effort (why not just "Media Description Display"?). Hm ... in the toolboxes there are more Qt components ... which do not have Qt in the name yet.

Concerning importance: I still do not get it why for the users it is important to see in the component view, with which Qt version a component was created. (Hm maybe if one wants to support usage of different Qt major versions at the same time, but I guess we are not going there). And then when the projects were created with the Qt 5 version default names of the components and used with the Qt 6 update there is finally a confusing mismatch (so in the graph editor the component is called Qt 5 Media Description Display, but what is actually launched is the Qt 6 Media Description Display). Qt version information is needed much earlier as release information to find out which toolbox versions can be used with which ADTF version. Hm I have no final idea for this yet ... maybe a good approach would be to provide a compatibility matrix for the users: which toolbox versions are recommended/tested/should work for which ADTF versions. (Or recommended bundles).

Concerning ARXML toolbox example project: actually beyond the topic of the ticket but when you look at it it anyway, we found the following further issues. 1. CAN decoder example. Signal name wrong in property of the CAN coder filter. 2. Flexray example has no fibex nor arxml, so would not work. 3. SomeIP example would be nice.

Hi Jochen,

I was browsing a little bit further in the guide and here https://support.digitalwerk.net/adtf/v3/guides/sdk_properties_filter.html there is also the "Demo Media Description Display" in the video and "Qt Media Description Display" in the text. So I somehow would assume further locations that need to be updated.

Correct, as mentioned here -> #17471#note-2

You see my preference for a naming that reduces the update effort (why not just "Media Description Display"?). Hm ... in the toolboxes there are more Qt components ... which do not have Qt in the name yet.

This will be changed in upcoming toolbox as well.

Concerning importance: I still do not get it why for the users it is important to see in the component view, with which Qt version a component was created. (Hm maybe if one wants to support usage of different Qt major versions at the same time, but I guess we are not going there). And then when the projects were created with the Qt 5 version default names of the components and used with the Qt 6 update there is finally a confusing mismatch (so in the graph editor the component is called Qt 5 Media Description Display, but what is actually launched is the Qt 6 Media Description Display). Qt version information is needed much earlier as release information to find out which toolbox versions can be used with which ADTF version. Hm I have no final idea for this yet ... maybe a good approach would be to provide a compatibility matrix for the users: which toolbox versions are recommended/tested/should work for which ADTF versions. (Or recommended bundles).

Sorry, but you mix up to many different things and unfortunately do not understand our approach.
The current Qt related components are build with Qt5 and will always be !
But the plan in future is, to also support Qt6 but this not possible due to binary compatibility.
So if we support Qt6, there will be an additional Qt6 UI SDK, additional Qt6 XSystem and additonal Qt6 components besides the current Qt5 content.
To differ the content in component view and graph, we work with the label, it wont be possible create a graph for both worlds (nice idea but we will focus a different way which will always work and is transparent for the user and dependencies). So if you drop a Qt5 Filter, it will add the Qt5 XSystem, if you add a Qt6 Filter, it will add the Qt6 XSystem.
Both cannot be handled in one Session and will fail and declined by CE.
Mixing Qt versions can only work in different instances / distributed system.
So this is our plan and to prevent in future the naming, we start tagging with Qt5 now.
If I could, I would also edit the CID but this I won't do to avoid breaking changes.
So in future we will have a qt_xsystem.ui_service.adtf.cid (unfortunately not qt5_xsystem.ui_service.adtf.cid) and a qt6_xsystem.ui_service.adtf.cid which cannot be combined.
That's it, hope its more clear now.

And yes, we are planning to create baselines for ADTF bundles. But right now, the tested ADTF version is the one from the build, so transparent for the user. Recommended will be always latest. Second approach for this will be our store, with the abaility to only get a reduced packae (codename adtf_nano) and download plugins from store. This hopefully can also help customers with version freezes to get updates and - hoepfully in future as well - automatic downloads by just sharing sessions.

Concerning ARXML toolbox example project: actually beyond the topic of the ticket but when you look at it it anyway, we found the following further issues. 1. CAN decoder example. Signal name wrong in property of the CAN coder filter. 2. Flexray example has no fibex nor arxml, so would not work. 3. SomeIP example would be nice.

Yes, we adapt that, this has been already reported from your colleague (#17454)

From training side, I still think it would be not a good approach that people have to learn different names every now and then ... (ok guess it does not go so far yet that user of different ADTF 3 minor versions do not understand each other).

[...]

yeah guess we have a different approach with terminology. Updating terminology is a more involved process here with many different people and company internal terminology database involved. So for ADTF 2 (from version 2.9) I do not remember any significant naming update.

• We wont change any class ids or interface ids in future, neither in ADTF or in toolboxes, we are fine now and have a process update to prevent this in future
• We are not planning to adapt label names in adtf core (besides components may get deprecated or succeed BETA state)
• We will adapt the toolboxes label names for the new profiles (to changes from adtf 3.14 as well
  • Calibration TB
    • Signal Requester Filter -> XCP Signal Requester
    • XCP Decode Filter -> XCP Config Decoder Filter
    • XCP Emulator Filter -> XCP Emulator
    • XCP Encode Filter -> XCP Config Encoder Filter
    • XCP Master Filter -> XCP Master
    • XCP Service -> XCP Support Service
  • Device TB
    • (Deprecated) CAN Trace View -> (Deprecated) Qt5 CAN Trace View UI Service
    • CAN FD Trace View -> Qt5 CAN FD Trace View UI Service
    • DevTB2 Support Service -> ADTF 2.x Bus Data Deserializer Support Service
    • FlexRay Trace View -> Qt5 FlexRay Trace View UI Service
    • SOME IP Trace View -> Qt5 SOME IP Trace View UI Service
  • Display TB
    • 2D OpenGL Display -> Qt5 2D OpenGL Display
    • 3D OpenSceneGraph Display -> Qt5 3D OpenSceneGraph Display
    • Demo Signal Provider UI Service -> Demo Qt5 Signal Provider UI Service
    • Signal Scope View UI Service -> Qt5 Signal Scope View UI Service
    • Signal Table View UI Service -> Qt5 Signal Table View UI Service
    • Signal Tree View UI Service -> Qt5 Signal Tree View UI Service

Hi Florian,

thanks for the detailed information! Now I think I get closer to understand the future concept.

For me it still looks a little bit hairy since names can be arbitrary changed in the graphs and the system. So how should the configuration editor or launcher know when opening a project with arbitrary named components, which Qt version is used? Hm, still we have the plugindescriptions and the path to the different plugins. So guess this can be handled somehow using that information.

Thank you! Ticket can be closed.

Ah I see, new cids for the qt6 versions. Then it is clear.

BR,
Jochen