Lighthouse-Documentation

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Qt4 vs Qt5

Lighthouse in Qt 5 is expanding, due to the fact it was born to be a simple replacement to QWX, but now it's taking care of pretty much everything about platform. There will be no big API guarantees about the API for obvious reasons The documentation issue is mostly about a "how to get around" issue, the specific documentation API is not as important as that in this context.

There is no such thing a porting issue, we need something which explains the concept

Current Lighthouse situation

There are 3 people working actively full-time on it. The focus is on Tier 1 platforms, but of course community support for other platform should be regarded as important.

This kind of information and documentation of course is not meant to be shown everywhere, especially for the API stability issue. There is a qdoc "trick" to create private documentation which is the one which could be used. Or the wiki.

There is a quite steep learning curve for the new Lighthouse.

Thomas Senyk should be a good person to interact with for the documentation.

We don't want to have API stability for Lighthouse, because it's simply not possible. Ports should be maintained throughout separate versions, and there is no point in having a stable API with the platform target moving.

In Qt4 there has been a similar mistake of having too many APIs public and stable, and there was a failure. After all, LH (Lighthouse, not Lufthansa) API is meant to remain private.

Bottom line: LH plugins should be part of the Qt project itself, but not necessarily of Qt Base

Where do these plugins live?

If we are providing a private API, we want to have those plugins inside Qt itself.

How many LH plugins should be in QtBase? They can be in a separate repositories indeed.

The path should be done inside Qt Project itself for the development of a new platform plugin. Reference platforms should be inside QtBase itself for obvious reasons. However, plugins should be able to live outside of it, also for having more flexibility for developers. Of course, considering a merge with QtBase should always be considered.

Case study: Wayland. Wayland is a highly moving target, so the plugin NEEDS to live outside QtBase main tree

Blog about API changes!

Problem of centralizing docs which might be already existent. Documentation should also be interactive -> blogs, wiki…

Have qdoc putting private documentation somewhere? We need design documentation.

To write design doc, we of course need people doing design. Private documentation should be/become as important as public one, and anything private should be documented inside the source code itself, or wherever it makes more sense (wiki).

Documentation and how to write documentation should be exposed.