Lighthouse-Documentation: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
== Qt4 vs Qt5 == | == 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. | 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 | There is no such thing a porting issue, we need something which explains the concept | ||
| Line 11: | Line 13: | ||
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. | 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 | 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. | There is a quite steep learning curve for the new Lighthouse. | ||
| Line 35: | Line 37: | ||
Blog about API changes! | Blog about API changes! | ||
Problem of centralizing docs which might be already existent. Documentation should also be interactive - | 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. | Have qdoc putting private documentation somewhere? We need design documentation. | ||
Revision as of 10:47, 25 February 2015
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.