Advance Wayland and KDE package bring-up

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
This commit is contained in:
2026-04-14 10:51:06 +01:00
parent 51f3c21121
commit cf12defd28
15214 changed files with 20594243 additions and 269 deletions
@@ -0,0 +1 @@
add_subdirectory(kbuildsycoca6)
@@ -0,0 +1,8 @@
### KApiDox Project-specific Overrides File
# define so that deprecated API is not skipped
PREDEFINED += \
"KSERVICE_ENABLE_DEPRECATED_SINCE(x, y)=1" \
"KSERVICE_BUILD_DEPRECATED_SINCE(x, y)=1" \
"KSERVICE_DEPRECATED_VERSION(x, y, t)=" \
"KSERVICE_DEPRECATED_VERSION_BELATED(x, y, xt, yt, t)="
@@ -0,0 +1 @@
kdoctools_create_manpage(man-kbuildsycoca6.8.docbook 8 INSTALL_DESTINATION ${KDE_INSTALL_MANDIR})
@@ -0,0 +1,191 @@
<?xml version="1.0" ?>
<!DOCTYPE refentry PUBLIC "-//KDE//DTD DocBook XML V4.5-Based Variant V1.1//EN" "dtd/kdedbx45.dtd" [
<!ENTITY % English "INCLUDE"><!-- change language only here -->
]>
<refentry lang="&language;">
<refentryinfo>
<title>&kde-frameworks;: KService</title>
<author>
<firstname>Darian</firstname>
<surname>Lanx</surname>
<contrib>Wrote the original documentation.</contrib>
<affiliation>
<address><email>content@openprojects.net</email></address>
</affiliation>
</author>
<author>
<firstname>Alex</firstname>
<surname>Merry</surname>
<contrib>Updated the documentation for &kf5-full;.</contrib>
<affiliation>
<address><email>alexmerry@kde.org</email></address>
</affiliation>
</author>
<date>2015-09-17</date>
<releaseinfo>Frameworks 5.15</releaseinfo>
<productname>KDE Frameworks</productname>
</refentryinfo>
<refmeta>
<refentrytitle><command>kbuildsycoca6</command></refentrytitle>
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
<refname><command>kbuildsycoca6</command></refname>
<refpurpose>Rebuilds the KService desktop file system configuration cache</refpurpose>
</refnamediv>
<refsynopsisdiv>
<title>Synopsis</title>
<cmdsynopsis>
<command>kbuildsycoca6</command>
<group choice="opt" rep="repeat"><replaceable class="option">OPTIONS</replaceable></group>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>kbuildsycoca6</command> builds binary cache of the data stored in
<literal role="extension">.desktop</literal> and &MIME; type <literal
role="extension">.xml</literal> files that the KService framework uses to find
plugins, applications and other services.
</para>
<para>
The KService library uses this database to efficiently provide the information
requested of it.
</para>
<para>
Users do not normally need to run this application directly; KService will run
it if necessary, when any of the files whose data is cached are changed.
</para>
</refsect1>
<refsect1>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>--global</option></term>
<listitem>
<para>Ignores any user-set files (in <varname>XDG_DATA_HOME</varname>). This is currently only supported on &UNIX; systems.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--noincremental</option></term>
<listitem>
<para>Rather than using the existing cache and only updating the information that has changed or been added, start with an empty cache. Ignored if <option>--global</option> is set.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--menutest</option></term>
<listitem>
<para>Test the generation of the application menu database. Does not actually build the cache.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--testmode</option></term>
<listitem>
<para>Use the QStandardPaths "test mode" to avoid interfering with user data. This is intended for use with unit tests.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--track <replaceable>menu-id</replaceable></option></term>
<listitem>
<para>Track a menu ID for debugging.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--author</option></term>
<listitem>
<para>
Show author information.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--license</option></term>
<listitem>
<para>
Show license information.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-h, --help</option></term>
<listitem>
<para>
Show a brief help text.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-v , --version</option></term>
<listitem>
<para>
Show version information.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Files</title>
<variablelist>
<varlistentry>
<term><filename><varname>cachedir</varname>/ksycoca6_[lang]_[sha1-of-dirs]</filename></term>
<listitem>
<para>The KService cache generated by <command>kbuildsycoca6</command>. On &UNIX; systems, <varname>cachedir</varname>
is typically <filename class="directory"><envar>XDG_CACHE_HOME</envar></filename>.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>kded5</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>kdeinit5</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
<refsect1>
<title>Bugs</title>
<para>Please use <ulink url="https://bugs.kde.org">&kde;'s bugtracker</ulink> to report bugs.</para>
</refsect1>
</refentry>
@@ -0,0 +1,49 @@
Service types
=============
A service type is a capability that a set of services (applications or plugins) have.
For instance the service type KParts/ReadOnlyPart means "this plugin has the capability
to provide a class that derives from KParts::ReadOnlyPart" (i.e. an embeddable viewer).
The coincidence in naming is just a coincidence, we could have named that servicetype
"EmbeddableKPartsViewer" or whatever, it's just a name.
A service type is defined by a .desktop file (installed into the servicetypes directory),
containing name, translated description, and a few additional things like inheritance
and additional properties.
Mime types
==========
In KDE3 and KDE4, a mimetype was a special kind of servicetype.
However since KF5 we are moving away from this, and splitting out the two.
This document was written before that, however.
Service type inheritance (X-KDE-Derived)
========================================
X-KDE-Derived is the desktop file key that defines inheritance for a service type.
"ST1 derives from ST2" means "ST1 is more specific than ST2".
If a service implements ST1, it also implements ST2, but not the other way round.
For instance, KoDocument derives from KParts/ReadWritePart, which derives from KParts/ReadOnlyPart,
so KWord's part (which implements KoDocument) can be used as a readonly viewer for KWord files
in Konqueror (which looks for a KParts/ReadOnlyPart).
Mimetype "inheritance"
======================
For mimetypes, we need a mechanism to also say that "text/xml is a special case of text/plain",
or "text/docbook is a kind of text/sgml", or "application/x-smb-workgroup is a kind
of inode/directory", etc. See below.
Why mimetype "inheritance" doesn't use X-KDE-Derived
====================================================
The confusing thing is that we said "a mimetype is a servicetype". But that's not exactly correct.
As Waldo noted, "the ability to open a mimetype" is what's a servicetype.
So if text/xml said X-KDE-Derived=text/plain (i.e. ST1=text/xml, ST2=text/plain),
then an application opening text/xml (ST1) would end up being associated with any text/plain (ST2) file,
which would be wrong.
We want the other way round: to be able to open special kinds of text/plain in a plain text editor.
This is why mimetypes have their own inheritance mechanism ("X-KDE-IsAlso" in KDE3, and since KDE4,
the inheritance mechanism defined in shared-mime-info).
It kind of "works the other way" than X-KDE-Derived.
If M1 is a special kind of M2 (mimetypes), then "the ability to open M2" derives from "the ability to open M1"
The ability to open any text/plain file derives (is more specific than) the ability to open text/xml only.
"text/xml inherits from text/plain" means that applications that can open text/plain can also open text/xml.