Qt Interface Framework documentation improvement

User suggested to to update the Qt Interface documentation:

"

The current documentation for Qt IF is pretty solid but does lean quite heavily on the  Automotive background and use cases.

It is very clear that the framework is very useful for a wide variety of use cases beyond the original automotive scope.

I would like to see a nicer separation of the framework and how to build your parts of it, and move the automotive focus into a separate area, module or whatever as a solid reference.

The documentation leads very quickly into automotive speak which should be made more generic and not to alienate potential beneficiaries of this great way of working.

More focus should be placed on the different workflows that are introduced as benefits.
This is because a) there are great benefits for many parallel workflows and QA, testing, DEMO mode, training modes, record and (offline) playback and many other ideas I can think of.

These are reasons that a team might consider QtIF for their architecture. So the technical "sales pitch" should be clear from the start of the docs.

The ability to decouple Qt Remote Objects and use e.g. QGrpc instead or other custom zero-config IPC setup or even to wrap complex systems with a common interface for the aforementioned benefits.

"
We requested more concrete example of this:

"

The first landing page as linked there could do with being split up according to core, media and vehicle as the C++ and QML sections are.

https://doc.qt.io/QtInterfaceFramework/interfaceframework-modules.html

https://doc.qt.io/QtInterfaceFramework/interfaceframework-qmlmodules.html

However even these pages could be restructured to present primary focus on the core modules and examples first.

My focus point here is this:

As Qt embarks on a quest to make the Qt Application Framework a much better-know and more widely adopted technology (I know that is a real thing you're doing, not making that up) then the whole API needs more of a generic approach in its "selling point" to developers and managers in its generic features.

So, that being said, it should focus on the core modules and its main features and benefits and push the media and vehicle parts aside into a secondary topic, by way of but ONE example. The fact is, if Qt want to advertise QtIF, then it needs to break into other spaces other than purely automotive (which is where of course this came _from) and so needs to focus on the benefits of the core modules from the landing page and not mention too early on, the automotive background. As we look at it, we see straight away the customer questioning "but I'm not working on automotive – is the Qt Application Framework right for me?" The answer could well be yes, but they need to understand more that the media and vehicle parts are "extras" and not something they need to worry about for their bespoke implementation._

For context: we gave a presentation to our manager about adopting QtIF for our future architecture – and it was very much an uphill struggle because you are hit with so much complexity out of the box to get even a small "feature" working and we as developers were all asked "is it really worth it" and "what is the benefit" – it was a hard sell, even if we could "feel" that it could be worth it. The docs don't sell it for us unfortunately.

"