Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
Lighthouse-Documentation: Difference between revisions
No edit summary |
(Move to actual category; the category this thought it belonged to was specific to 2011 but didn't say so.) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
== | {{delete|reason=Outdated information.}} | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}} | |||
Lighthouse in Qt 5 is expanding, due to the fact it was born to be a simple replacement to | [[Category:QtCS2011]] | ||
== 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 | There is no such thing a porting issue, we need something which explains the concept | ||
==Current Lighthouse situation== | == 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. | 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 | 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 15: | Line 22: | ||
Thomas Senyk should be a good person to interact with for the documentation. | Thomas Senyk should be a good person to interact with for the documentation. | ||
We | 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 | 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 | Bottom line: LH plugins should be part of the Qt project itself, but not necessarily of Qt Base | ||
==Where do these plugins live?== | == Where do these plugins live? == | ||
If we are providing a private | 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. | How many LH plugins should be in QtBase? They can be in a separate repositories indeed. | ||
| Line 29: | Line 36: | ||
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. | 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 | Case study: Wayland. Wayland is a highly moving target, so the plugin NEEDS to live outside QtBase main tree | ||
Blog about | 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. | ||
| Line 41: | Line 48: | ||
Documentation and how to write documentation should be exposed. | Documentation and how to write documentation should be exposed. | ||
==Documentation for new modules== | == Documentation for new modules == | ||
Latest revision as of 09:30, 16 February 2018
| This article is nominated for deletion. Reason: Outdated information. Please raise your support/opposition to this nomination in the article's discussion page. |
| 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.