Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define The Compositor Modules Library Collection #2

Merged
merged 15 commits into from
Feb 14, 2024

Conversation

romangg
Copy link
Member

@romangg romangg commented Feb 14, 2024

We rename, rework, redefine the essence of this project to fit our years long path to carve out an independent library collection for compositor creation. A library collection we name The Compositor Modules.

We can see Issue 21 on Gitlab as the formalized starting point of this journey. Now coming to an end we:

  • Reset the CMake project version to 0.1.
  • Remove most KCMs, that must be provided in consumers instead.
  • Rename toplevel namespace to como.
  • Correct library export, load plugins dynamically.
  • Provide a logo, adapt the docs.

We don't install them, but still build them as this ensures the full feature
set can be built.
The project will evolve to be a library called "The Compositor Modules",
abbreviated to "como". We change the project name in the CMake build files,
library names and config as well as export definitions.
The first library release will start at version 0.1. Version numbering will
be independent of Plasma releases.
Rename from "KWin" to "como".
These are removed form the pure library part.
These are "The Compositor Modules". We declare this in the central README.md,
describe their usage and add the official logos.
In order to have includes of files with the como prefix in the build the same
way as when the headers are installed, the files must reside in a folder
structure with "como" as toplevel directory.
This way the installed headers can be used by consumers without potential name
collisions.
In the past these plugins were changed to be static in order to improve startup
time. But in order to use them by consumers of the library, we switch back to
dynamic loading. We assume the startup time increase is tolerable.
These plugins have been compiled statically into the binaries before, but for
independent consumers to make use of them we need to instead install and load
them dynamically.
To enable consumers making use of it we must ensure:
* config file is installed with transitive dependencies
* custom find module files are provided
* all required headers are installed
* the base directory is included
It's more commont to have it here and in fact also plugins rely on it.
Such packages can be used by downstream projects in our CI. We directly create a new CI
job for that. It creates a Debian package and a simple tar archive.
This way the package is kept available. The workflow is scheduled to run every
Thursday at 4:00 only within the 'winft/como' repo.
Our custom code for message linting only works on push events. For pull
requests we would require to adapt the code. Or we can use an already available
action from the market place, what we try to do with this commit.
@romangg romangg merged commit 84fdd24 into winft:master Feb 14, 2024
9 checks passed
@romangg romangg deleted the lib-isolate branch February 14, 2024 14:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant