It would be useful to update https://qooxdoo.org/documentation/#/development/contribute to explain how to develop using a checked-out version of qooxdoo rather than via npx qx compile which uses the version of qooxdoo deep in the bowels of node_modules.

At the moment, it is not obvious where to look in the documentation if one wants to know how to manually configure the compiler's dependency resolution. We haven't migrated http://archive.qooxdoo.org/current/pages/tool/generator/dependencies_manually.html into the new docs, it seems. But in any case, the information must be placed in a more accessible way and linked from introductory chapters.

There is currently no link to https://archive.qooxdoo.org/ on the homepage and no information how to retrieve API/Documentation of previous versions that are published there. We need to add a "history" page with links to all the archived versions which can be found here: https://github.com/qooxdoo/website-archive

so far, the overview only covers OO features, which doesn't cover the whole range of interesting qooxdoo features, such as databinding, promises, etc.

https://qooxdoo.org/documentation/v7.0/#/development/howto/using_non_qx_libs?id=using-non-qooxdoo-third-party-libraries

Attempting to use require() in a Qooxdoo application to load a Browserify'ed NPM module results in "require is not defined".

We need a page which explains the philosophy and design of the object id system and provides a few examples how to use it. Assigning @johnspackman since you devised the system.

In the page about adding resources, the line about importing assets from the theme is missing it's placeholder. The placeholder is there in the markdown file

https://github.com/qooxdoo/documentation/blob/master/desktop/gui/resources.md in line 95
but it doesn't show in the web page

https://qooxdoo.org/documentation/#/desktop/gui/resources

There were two ideas behind introducing the apps:// pseudo-protocol to indicate links to the qooxdoo apps:

• it made it possible to have local versions of the qooxdoo apps that could be linked to in the documentation. Docsify would dynamically reference the online or offline version dependent on whether it was run with qx serve or from the qooxdoo domain. However, we no longer ship the offline apps with the NPM release-
• it would speed up linting as the links were considered to be safe. However, the links can be faulty if the apps change something in their approach to routing (which would be bad, because non-BC) or if there is something broken. The question is if the increase in speed is more valuable than alerting us to broken links.

I suggest we replace apps:// with real https:// links. This would also make them work when viewing the docs on GitHub. It would still be possible to implement some kind of dynamic redirection if we need it, based on those links.

With the switch to sematic release, it becomes important to have a system that automatically creates documentation that reflects feature and breaking releases:

• No feature and breaking release should be done without a corresponding update and release of the documentation .
• qooxdoo.org/documentation should always have the latest version, qooxdoo.org/documentation/X.X the corresponding legacy docs.