pax_global_header00006660000000000000000000000064152141736370014523gustar00rootroot0000000000000052 comment=323505da7fa9fedbab6b9cacbfc3a5dcd6492948 linuxdeepin-treeland-protocols-886890b/000077500000000000000000000000001521417363700201575ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.agents/000077500000000000000000000000001521417363700215165ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.agents/skills/000077500000000000000000000000001521417363700230175ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.agents/skills/treeland-wayland-protocol/000077500000000000000000000000001521417363700301115ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.agents/skills/treeland-wayland-protocol/SKILL.md000066400000000000000000000124551521417363700313200ustar00rootroot00000000000000--- name: treeland-wayland-protocol description: Write or update Treeland Wayland protocol XML specifications. Use when the task is to design, draft, review, or version protocol files under xml/, following standard Wayland protocol conventions while correcting non-standard patterns in existing Treeland protocols. --- Use this skill when working on Treeland Wayland protocol definitions in this repository. ## Scope This skill is for: - creating a new protocol XML under `xml/` - extending an existing protocol in a backward-compatible way - preparing a new major version for a backward-incompatible change - reviewing protocol XML for naming, versioning, lifecycle, and wording issues This skill is not for compositor/server implementation details. It only covers the protocol spec layer. ## Workflow 1. Read [references/treeland-wayland-protocol-rules.md](references/treeland-wayland-protocol-rules.md). 2. Open 2-3 nearby XML files under `xml/` that match the intended style or domain. 3. Use Treeland-unstable naming by default and only diverge when maintainers explicitly require a stable file line. 4. Draft or edit the XML using [assets/treeland-protocol-template.xml](assets/treeland-protocol-template.xml) as a starting point when useful. 5. If adding a new XML file, update `CMakeLists.txt` so it is installed with the rest of the protocol set. 6. Re-read the final XML once for protocol lifecycle correctness: - object creation and destruction are explicit - events vs requests are directionally correct - error enums are specific and actionable - additions in an existing major version use `since` - naming is consistent across file name, protocol name, interface names, and enum references ## Treeland-specific rules - Protocol XML files live in `xml/`, not in `stable/`, `staging/`, or `experimental/` directories. - Use unstable naming for new Treeland protocols by default: `xml/treeland-foo-unstable-v1.xml` with protocol name `treeland_foo_unstable_v1`. - Important repo convention: even for unstable files, interface names usually stay in the form `treeland_foo_bar_v1` rather than `treeland_foo_bar_unstable_v1`. Match neighboring Treeland XMLs unless the repo convention changes. - New protocol files must be added to the `XML` list in the top-level `CMakeLists.txt`. - Use the repo's SPDX copyright block style from neighboring files. - Existing Treeland XML may contain non-standard patterns. Prefer the rules in this skill over preserving those patterns. ## Authoring guidance - Keep each protocol narrow in scope. If a request starts needing unrelated policy or multiple roles, split the protocol. - Prefer clear object lifetimes over implicit state machines. - Use `new_id` only when the compositor is creating a protocol object for the client. - Within one interface, prefer the order: `description -> enum -> destroy request -> other requests -> events`. - Interface descriptions should state the interface purpose and briefly describe the expected workflow when it is not obvious. - Manager-style interfaces should provide an explicit `destroy` request. - If an interface has a destroy-style request, place it as the first request in that interface. - Use `type="destructor"` on explicit destroy requests. - Keep all requests before all events inside one interface. - Request descriptions should document any required call scenarios, preconditions, and ordering constraints. - Put protocol errors in `enum name="error"` when clients can violate required rules. - Avoid XML comments for protocol semantics. Put normative and behavioral information in `` blocks. If a short comment is needed for maintenance, keep it non-semantic. - Use `since` only for backward-compatible additions inside the same major version. Do not write `since="1"`. - If an existing interface gains a new request or event, increment that interface's `version`, append the new member at the end of the existing request or event section, and mark the new member with the matching `since="N"`. - If an interface version is raised, review any nearby interface that creates it with `new_id`, returns it from a request, or exposes it from an event; if that dependency changes the observable contract for clients, raise the exposing interface `version` as well. - For a breaking change, keep the old XML file, add a new `-vN+1` file, rename the protocol and interfaces to the new major suffix, reset interface `version` to `1`, and remove carried-over `since` attributes. - Prefer precise `summary` text and concrete descriptions over placeholders. - Event descriptions should explain event meaning and the compositor-side trigger timing for emission. - When writing normative behavior, use RFC 2119 keywords in lowercase and include the RFC 2119 paragraph in the top-level protocol description if the document relies on those terms normatively. ## Validation Before finishing: - compare the XML against at least one standard Wayland reference spec for structure quality - compare against at least one Treeland XML for local naming and packaging conventions, but do not preserve non-standard patterns just because they already exist - ensure enum references are fully correct, especially `enum="interface.enum"` where needed - ensure nullable object args explicitly use `allow-null="true"` - ensure destroy ordering constraints are documented wherever misuse would be a protocol error linuxdeepin-treeland-protocols-886890b/.agents/skills/treeland-wayland-protocol/assets/000077500000000000000000000000001521417363700314135ustar00rootroot00000000000000treeland-protocol-template.xml000066400000000000000000000054631521417363700373340ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.agents/skills/treeland-wayland-protocol/assets Replace this description with the protocol's purpose, object model, and lifecycle guarantees. If this specification uses RFC 2119 keywords normatively, include the standard interpretation paragraph here. Describe what this global creates, any singleton or binding rules, and a brief high-level workflow for clients. Describe whether child objects must be destroyed first. Describe ownership, required call scenarios, preconditions, and lifetime expectations. Describe the object's state, lifetime, and relation to Wayland core objects. Describe any ordering constraints with related objects. Describe whether this is immediate or latched until commit. Describe event meaning, compositor-side trigger timing, and what the client should do next. linuxdeepin-treeland-protocols-886890b/.agents/skills/treeland-wayland-protocol/references/000077500000000000000000000000001521417363700322325ustar00rootroot00000000000000treeland-wayland-protocol-rules.md000066400000000000000000000151061521417363700407220ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.agents/skills/treeland-wayland-protocol/references# Treeland Wayland Protocol Rules This reference condenses standard Wayland protocol conventions together with the packaging and naming conventions used in this repository. ## 1. Source of truth When drafting a protocol: - use standard Wayland reference protocols as the style reference for XML structure and protocol evolution - use `xml/` as the source of Treeland-specific naming and packaging conventions Do not copy a reference protocol mechanically. Reuse its structure only when the lifecycle matches. ## 2. Naming and versioning Treeland protocol defaults for this repo: - file: `xml/treeland-foo-unstable-v1.xml` - protocol: `treeland_foo_unstable_v1` - interfaces usually still end with `_v1` and usually do not include `_unstable` - if maintainers later stabilize a protocol line, follow the naming convention requested in that stabilization review Backward-compatible extension: - keep the same file - keep the same interface major version suffix - raise interface `version` - add `since="N"` on each new request, event, enum entry, or arg introduced in version `N` - never write `since="1"` - append newly added requests or events after the existing ones instead of reordering old members - if an upgraded interface is exposed by another interface via `new_id`, a request return object, or an event object, review that exposing interface and raise its `version` too when clients need the higher version to observe or use the new contract Backward-incompatible extension: - create a new file with the next major version - keep the old file in the tree for compatibility - rename the protocol and interfaces to the new major suffix - reset interface versions to `1` - remove old `since` attributes unless needed again within the new major line ## 3. XML structure Recommended order: 1. XML declaration 2. `` 3. `` 4. optional top-level `` 5. one or more `` Recommended interface order: 1. interface description 2. enums, if any 3. destroy request, if the interface has one 4. constructor-style requests 5. regular requests 6. events Within one interface, keep enums before requests, and keep requests before events. Existing Treeland files vary, but new or updated protocol work should follow this ordering. ## 4. Description quality Descriptions should answer: - who owns the object - who creates it - when it becomes invalid - which sequencing constraints are illegal - whether the compositor or client defines a behavior Good protocol text is concrete: - say what triggers an event - say whether state is latched, pending, or immediately applied - say whether an object is singleton, per-output, per-surface, or per-session Description minimums by member type: - interface description should explain the interface purpose and, when useful, the high-level workflow - request description should explain required call scenarios and ordering/precondition constraints - event description should explain event meaning and compositor-side trigger timing Avoid: - vague summaries like "do something" - implementation detail that does not affect the wire contract - undocumented one-shot objects or hidden lifecycle rules - semantic requirements hidden in XML comments ## 5. Requests, events, and errors Use requests for client-to-compositor actions. Use events for compositor-to-client notifications. Manager-style interfaces should generally expose `destroy`. Create a dedicated error enum when the client can violate protocol rules such as: - using an object after required destruction ordering - passing an invalid role target - calling a one-shot request multiple times - providing out-of-range values Prefer specific error entries over a generic `failed`. ## 6. Object model heuristics Prefer manager/object splits: - manager global creates session/object instances - per-object interfaces own ongoing state and events Prefer separate objects when: - lifetime differs from the manager - events only make sense after setup - the API would otherwise need ad-hoc request ordering rules Avoid turning one interface into a grab-bag of unrelated features. ## 7. Arg conventions Use: - `new_id` for created protocol objects - `object` for existing protocol objects such as `wl_output`, `wl_surface`, `wl_buffer`, `wl_callback`, `wl_compositor`, `wl_seat`, `wl_pointer`, `wl_touch`, and `wl_keyboard` - `allow-null="true"` only when null is explicitly valid - `enum="..."` on integer args that reference enums - `bitfield="true"` on enum definitions used as flag sets Add `summary` for args when it materially improves readability. ## 8. XML comments Reference protocols do use XML comments in a few places, most commonly to mark versioned additions. However, comments are not a good place for protocol semantics. Rule for Treeland skills: - do not place normative behavior, sequencing rules, or lifecycle requirements in XML comments - prefer `` blocks for anything a protocol reader must understand - use comments only sparingly for short maintenance markers ## 9. RFC 2119 usage If the protocol text relies on words like `must`, `should`, or `may` normatively, add a top-level protocol description that includes the RFC 2119 interpretation paragraph used by standard Wayland protocol specifications. Do not add that paragraph if the protocol text is otherwise non-normative. ## 10. Treeland repo integration When adding a new protocol file: - place it under `xml/` - add it to the `XML` list in the repository `CMakeLists.txt` - follow the local SPDX block: ```xml ``` Match the year range used by neighboring files when editing an existing protocol family. ## 11. Review checklist Before considering the XML finished, check: - file name, protocol name, and interface suffixes all agree - interface `version` matches the highest supported additive version - interfaces that create or expose upgraded interfaces were reviewed for required version bumps - new additions in an existing interface have `since` - no member is annotated with `since="1"` - newly added requests and events were appended without reordering older members - destructor requests are marked `type="destructor"` - enums, if present, appear before requests - if an interface has a destroy request, it is the first request - requests appear before events - object lifetime constraints are documented - event ordering constraints are documented where required - all enum references resolve correctly - nullable args are intentional - the protocol is added to `CMakeLists.txt` if it is new linuxdeepin-treeland-protocols-886890b/.github/000077500000000000000000000000001521417363700215175ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.github/workflows/000077500000000000000000000000001521417363700235545ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.github/workflows/call-auto-tag.yml000066400000000000000000000005171521417363700267340ustar00rootroot00000000000000name: auto tag on: pull_request_target: types: [opened, synchronize, closed] paths: - "debian/changelog" concurrency: group: ${{ github.workflow }}-pull/${{ github.event.number }} cancel-in-progress: true jobs: auto_tag: uses: linuxdeepin/.github/.github/workflows/auto-tag.yml@master secrets: inherit linuxdeepin-treeland-protocols-886890b/.github/workflows/call-chatOps.yml000066400000000000000000000002421521417363700266070ustar00rootroot00000000000000name: chatOps on: issue_comment: types: [created] jobs: chatopt: uses: linuxdeepin/.github/.github/workflows/chatOps.yml@master secrets: inherit linuxdeepin-treeland-protocols-886890b/.github/workflows/call-clacheck.yml000066400000000000000000000005251521417363700267470ustar00rootroot00000000000000name: Call CLA check on: issue_comment: types: [created] pull_request_target: types: [opened, closed, synchronize] concurrency: group: ${{ github.workflow }}-pull/${{ github.event.number }} cancel-in-progress: true jobs: clacheck: uses: linuxdeepin/.github/.github/workflows/cla-check.yml@master secrets: inherit linuxdeepin-treeland-protocols-886890b/.github/workflows/call-commitlint.yml000066400000000000000000000003641521417363700273720ustar00rootroot00000000000000name: Call commitlint on: pull_request_target: concurrency: group: ${{ github.workflow }}-pull/${{ github.event.number }} cancel-in-progress: true jobs: check_job: uses: linuxdeepin/.github/.github/workflows/commitlint.yml@master linuxdeepin-treeland-protocols-886890b/.github/workflows/call-license-check.yml000066400000000000000000000005521521417363700277070ustar00rootroot00000000000000name: Call License and README Check on: pull_request_target: types: [opened, synchronize, reopened] permissions: pull-requests: write contents: read concurrency: group: ${{ github.workflow }}-pull/${{ github.event.number }} cancel-in-progress: true jobs: license-check: uses: linuxdeepin/.github/.github/workflows/license-check.yml@master linuxdeepin-treeland-protocols-886890b/.gitignore000066400000000000000000000002161521417363700221460ustar00rootroot00000000000000# build build*/ Makefile CMakeLists.txt.user # nix .direnv/ result result-* # clangd .cache/ compile_commands.json # qtcreator *.autosave linuxdeepin-treeland-protocols-886890b/.obs/000077500000000000000000000000001521417363700210205ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/.obs/workflows.yml000066400000000000000000000011521521417363700235770ustar00rootroot00000000000000test_build: steps: - link_package: source_project: vioken source_package: %{SCM_REPOSITORY_NAME} target_project: vioken:CI - configure_repositories: project: vioken:CI repositories: - name: deepin_ci paths: - target_project: vioken target_repository: deepin_develop architectures: - x86_64 - aarch64 filters: event: pull_request commit_build: steps: - trigger_services: project: vioken package: %{SCM_REPOSITORY_NAME} filters: event: push linuxdeepin-treeland-protocols-886890b/CMakeLists.txt000066400000000000000000000022021521417363700227130ustar00rootroot00000000000000cmake_minimum_required(VERSION 3.25.0) project(TreelandProtocols VERSION 0.5.9) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) include(GNUInstallDirs) add_subdirectory(cmake) set(XML xml/treeland-capture-unstable-v1.xml xml/treeland-output-manager-v1.xml xml/treeland-virtual-output-manager-v1.xml xml/treeland-dde-shell-v1.xml xml/treeland-personalization-manager-v1.xml xml/treeland-wallpaper-color-v1.xml xml/treeland-foreign-toplevel-manager-v1.xml xml/treeland-shortcut-manager-v1.xml xml/treeland-shortcut-manager-v2.xml xml/treeland-window-management-v1.xml xml/treeland-ddm-v1.xml xml/treeland-screensaver-v1.xml xml/treeland-prelaunch-splash-v1.xml xml/treeland-prelaunch-splash-v2.xml xml/treeland-app-id-resolver-v1.xml xml/treeland-wallpaper-manager-unstable-v1.xml xml/treeland-wallpaper-shell-unstable-v1.xml xml/treeland-wine-window-management-unstable-v1.xml xml/treeland-wine-window-state-unstable-v1.xml xml/treeland-input-manager-unstable-v1.xml xml/treeland-keyboard-state-notify-unstable-v1.xml ) install(FILES ${XML} DESTINATION ${CMAKE_INSTALL_DATADIR}/treeland-protocols) linuxdeepin-treeland-protocols-886890b/LICENSES/000077500000000000000000000000001521417363700213645ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/LICENSES/CC-BY-4.0.txt000066400000000000000000000411771521417363700232330ustar00rootroot00000000000000Creative Commons Attribution 4.0 International Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. Using Creative Commons Public Licenses Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors. Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public. Creative Commons Attribution 4.0 International Public License By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. Section 1 – Definitions. a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. c. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. d. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. e. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. f. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. g. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. h. Licensor means the individual(s) or entity(ies) granting rights under this Public License. i. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. j. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. k. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. Section 2 – Scope. a. License grant. 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: A. reproduce and Share the Licensed Material, in whole or in part; and B. produce, reproduce, and Share Adapted Material. 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 3. Term. The term of this Public License is specified in Section 6(a). 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 5. Downstream recipients. A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. B. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). b. Other rights. 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 2. Patent and trademark rights are not licensed under this Public License. 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. Section 3 – License Conditions. Your exercise of the Licensed Rights is expressly made subject to the following conditions. a. Attribution. 1. If You Share the Licensed Material (including in modified form), You must: A. retain the following if it is supplied by the Licensor with the Licensed Material: i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); ii. a copyright notice; iii. a notice that refers to this Public License; iv. a notice that refers to the disclaimer of warranties; v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 4. If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License. Section 4 – Sui Generis Database Rights. Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. Section 5 – Disclaimer of Warranties and Limitation of Liability. a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. Section 6 – Term and Termination. a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 2. upon express reinstatement by the Licensor. c. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. d. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. e. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. Section 7 – Other Terms and Conditions. a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. Section 8 – Interpretation. a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. Creative Commons may be contacted at creativecommons.org. linuxdeepin-treeland-protocols-886890b/LICENSES/CC0-1.0.txt000066400000000000000000000156101521417363700227710ustar00rootroot00000000000000Creative Commons Legal Code CC0 1.0 Universal CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED HEREUNDER. Statement of Purpose The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work"). Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others. For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights. 1. Copyright and Related Rights. A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following: i. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work; ii. moral rights retained by the original author(s) and/or performer(s); iii. publicity and privacy rights pertaining to a person's image or likeness depicted in a Work; iv. rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below; v. rights protecting the extraction, dissemination, use and reuse of data in a Work; vi. database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and vii. other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof. 2. Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose. 3. Public License Fallback. Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose. 4. Limitations and Disclaimers. a. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document. b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law. c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work. d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work. linuxdeepin-treeland-protocols-886890b/LICENSES/GPL-2.0-only.txt000066400000000000000000000416711521417363700240340ustar00rootroot00000000000000GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. one line to give the program's name and an idea of what it does. Copyright (C) yyyy name of author This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice linuxdeepin-treeland-protocols-886890b/LICENSES/MIT.txt000066400000000000000000000020771521417363700225640ustar00rootroot00000000000000MIT License Copyright (c) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. linuxdeepin-treeland-protocols-886890b/README.md000066400000000000000000000013501521417363700214350ustar00rootroot00000000000000# Treeland protocols Wayland protocol extensions for treeland. ## Dependencies Check `debian/control` for build-time dependencies, or use `cmake` to check the missing required dependencies. ## Building Regular CMake building steps applies, in short: ```shell $ mkdir build && cd build $ cmake .. $ cmake --build . ``` ## Getting Involved - [Code contribution via GitHub](https://github.com/linuxdeepin/dde-launchpad/) - [Submit bug or suggestions to GitHub Issues or GitHub Discussions](https://github.com/linuxdeepin/developer-center/issues/new/choose) - [Translate this project into your language on Hosted Weblate](https://hosted.weblate.org/projects/deepin/dde-launchpad/) ## License **treeland-protocols** is licensed under MIT. linuxdeepin-treeland-protocols-886890b/README.zh_CN.md000066400000000000000000000013401521417363700224340ustar00rootroot00000000000000# Treeland 协议 Treeland 中的 Wayland 协议扩展 ## 依赖项 请检查 `debian/control` 文件以获取构建时依赖项，或者使用 `cmake` 检查缺失的必需依赖项。 ## 构建 构建过程遵循常规的 CMake 构建步骤，简而言之： ```shell $ mkdir build && cd build $ cmake .. $ cmake --build . ``` ## 如何参与 - [通过 GitHub 提交代码贡献](https://github.com/linuxdeepin/dde-launchpad/) - [在 GitHub Issues 或 Discussions 提交问题或建议](https://github.com/linuxdeepin/developer-center/issues/new/choose) - [在 Hosted Weblate 上将本项目翻译为您的语言](https://hosted.weblate.org/projects/deepin/dde-launchpad/) ## 许可证 Treeland遵循 MIT 许可证发布。 linuxdeepin-treeland-protocols-886890b/REUSE.toml000066400000000000000000000031341521417363700217400ustar00rootroot00000000000000version = 1 SPDX-PackageName = "treeland-protocols" SPDX-PackageDownloadLocation = "https://github.com/linuxdeepin/treeland-protocols" [[annotations]] path = [".github/**", ".obs/**.yml", "garnix.yaml"] precedence = "aggregate" SPDX-FileCopyrightText = "None" SPDX-License-Identifier = "CC0-1.0" [[annotations]] path = [".clang-format", ".editorconfig", "**.frag", "**.ui", "**.vert", "**/qmldir"] precedence = "aggregate" SPDX-FileCopyrightText = "None" SPDX-License-Identifier = "CC0-1.0" [[annotations]] path = ["debian/**", "rpm/**", "archlinux/**"] precedence = "aggregate" SPDX-FileCopyrightText = "None" SPDX-License-Identifier = "CC0-1.0" [[annotations]] path = ["**.nix", ".envrc", "flake.lock", "renovate.json"] precedence = "aggregate" SPDX-FileCopyrightText = "None" SPDX-License-Identifier = "CC0-1.0" [[annotations]] path = ["REUSE.toml", "**.json", "**.service", "**.txt", "**.ini", "**.sh", "**.html", ".gitignore", ".gitmodules", "INSTALL.md", "**.desktop", "**.css", "**.ttf", "**.conf", ".release.json"] precedence = "aggregate" SPDX-FileCopyrightText = "UnionTech Software Technology Co., Ltd." SPDX-License-Identifier = "CC0-1.0" [[annotations]] path = ["**.md", "README.md", "README.zh_CN.md", "CONTRIBUTING.md", "ChangeLog", "CONTRIBUTORS"] precedence = "aggregate" SPDX-FileCopyrightText = "UnionTech Software Technology Co., Ltd." SPDX-License-Identifier = "CC-BY-4.0" [[annotations]] path = ["**.cmake", "CMakeLists.txt", "**.in", "**.qrc", "misc/**", "services/**", "releng/create_changelog.pl"] precedence = "aggregate" SPDX-FileCopyrightText = "None" SPDX-License-Identifier = "GPL-2.0-only" linuxdeepin-treeland-protocols-886890b/cmake/000077500000000000000000000000001521417363700212375ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/cmake/CMakeLists.txt000066400000000000000000000011141521417363700237740ustar00rootroot00000000000000configure_file(TreelandProtocolsConfig.cmake.in TreelandProtocolsConfig.cmake @ONLY) configure_file(TreelandProtocolsConfigVersion.cmake.in TreelandProtocolsConfigVersion.cmake @ONLY) configure_file(treeland-protocols.pc.in treeland-protocols.pc @ONLY) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/TreelandProtocolsConfig.cmake ${CMAKE_CURRENT_BINARY_DIR}/TreelandProtocolsConfigVersion.cmake DESTINATION ${CMAKE_INSTALL_DATADIR}/cmake/TreelandProtocols) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/treeland-protocols.pc DESTINATION ${CMAKE_INSTALL_DATADIR}/pkgconfig) linuxdeepin-treeland-protocols-886890b/cmake/TreelandProtocolsConfig.cmake.in000066400000000000000000000002711521417363700274370ustar00rootroot00000000000000set(TREELAND_PROTOCOLS_DATA_DIR @CMAKE_INSTALL_FULL_DATAROOTDIR@/treeland-protocols/) set(TreelandProtocols_VERSION @PROJECT_VERSION@) set(TREELAND_PROTOCOLS_VERSION @PROJECT_VERSION@) linuxdeepin-treeland-protocols-886890b/cmake/TreelandProtocolsConfigVersion.cmake.in000066400000000000000000000005721521417363700310110ustar00rootroot00000000000000set(PACKAGE_VERSION "@PROJECT_VERSION@") # Check whether the requested PACKAGE_FIND_VERSION is compatible if("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}") set(PACKAGE_VERSION_COMPATIBLE FALSE) else() set(PACKAGE_VERSION_COMPATIBLE TRUE) if("${PACKAGE_VERSION}" VERSION_EQUAL "${PACKAGE_FIND_VERSION}") set(PACKAGE_VERSION_EXACT TRUE) endif() endif() linuxdeepin-treeland-protocols-886890b/cmake/treeland-protocols.pc.in000066400000000000000000000003431521417363700260100ustar00rootroot00000000000000prefix=@CMAKE_INSTALL_PREFIX@ datarootdir=@CMAKE_INSTALL_FULL_DATAROOTDIR@ pkgdatadir=${pc_sysrootdir}${datarootdir}/treeland-protocols/ Name: Treeland Protocols Description: Treeland protocol files Version: @PROJECT_VERSION@ linuxdeepin-treeland-protocols-886890b/debian/000077500000000000000000000000001521417363700214015ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/debian/changelog000066400000000000000000000110401521417363700232470ustar00rootroot00000000000000treeland-protocols (0.5.9) unstable; urgency=medium * feat(wallpaper-shell): bump treeland_wallpaper_shell_v1 to version 2 * feat: remove wallpapercontext from personalization manager -- YaoBing Xiao Tue, 16 Jun 2026 14:41:16 +0800 treeland-protocols (0.5.8) unstable; urgency=medium * feat: add treeland-keyboard-state-notify-unstable-v1 protocol * feat(input-manager): document valid ranges for scroll factor and accel speed * feat(input-manager): remove bitfield flag from acceleration_profile enum * feat(input-manager): clarify seat association and destruction order for settings objects * feat(wallpaper): document wl_output destruction order requirement * feat(treeland-wine-window-management): add serial to position requests * feat: add ready request for initial wallpaper synchronization * feat: add one-shot shortcut capture interface * feat: add treeland-input-manager-unstable-v1 protocol * refactor: protocol cleanup and version normalization -- rewine Thu, 04 Jun 2026 16:04:48 +0800 treeland-protocols (0.5.7) unstable; urgency=medium * docs: clarify virtual output validation and error codes * foreign-toplevel: add attention state -- rewine Fri, 22 May 2026 09:43:40 +0800 treeland-protocols (0.5.6) unstable; urgency=medium * fix(xml): fix wine window management stacking docs * chore: prettify treeland-capture protocol * chore: remove commented pointer grab protocol sections * refactor: update window management protocol XMLs * treeland-protocols: add Wine Wayland split protocols * feat: add destructor methods and reorganize protocol * chore: treeland-protocol-templated Treeland Wayland protocol authoring skill -- rewine Sat, 09 May 2026 09:55:30 +0800 treeland-protocols (0.5.5) unstable; urgency=medium * feat: add prelaunch splash screen protocol v2 -- rewine Sat, 28 Feb 2026 13:54:07 +0800 treeland-protocols (0.5.4) unstable; urgency=medium * chore: rename move_xwayland_surface to set_position_relative * feat: add treeland_wallpaper_v1 protocol for per-output wallpapers * feat: expose a method to move XWayland window position relative to wl_surface -- rewine Thu, 29 Jan 2026 20:28:33 +0800 treeland-protocols (0.5.3) unstable; urgency=medium * fix: replace XML comments with tags * fix: align protocol and interface names with filenames * fix: correct nonexistent enum reference in protocol -- rewine Thu, 15 Jan 2026 10:43:54 +0800 treeland-protocols (0.5.2) unstable; urgency=medium * fix: enum reference in set_blend_mode request * chore: remove since="1" attributes from protocols * feat: add optional icon buffer parameter to splash screen * fix: fix protocol specification errors and warnings * feat: enhance Wayland protocol with sandbox support * feat: add new Wayland protocols for app launching * fix: correct duplicate enum value in shortcut management protocol & add missing actions * feat: enhancements to treeland-shortcut-manager-v1 protocol * feat: Add treeland-screensaver-v1 protocol -- zhangkun Thu, 18 Dec 2025 17:32:46 +0800 treeland-protocols (0.5.1) unstable; urgency=medium * feat: support setting brightness and color temperature in treeland- output-manager protocol -- rewine Fri, 14 Nov 2025 11:27:09 +0800 treeland-protocols (0.5.0) unstable; urgency=medium * feat: add treeland-ddm communication protocol -- rewine Thu, 21 Aug 2025 11:39:06 +0800 treeland-protocols (0.4.5) unstable; urgency=medium * bump version to 0.4.5 -- rewine Fri, 06 Dec 2024 15:05:05 +0800 treeland-protocols (0.4.4) unstable; urgency=medium * bump version to 0.4.4 -- Groveer Tue, 26 Nov 2024 19:49:21 +0800 treeland-protocols (0.4.3) unstable; urgency=medium * bump version to 0.4.3 -- Groveer Wed, 20 Nov 2024 16:19:23 +0800 treeland-protocols (0.4.2) unstable; urgency=medium * bump version to 0.4.2 -- Groveer Thu, 14 Nov 2024 13:37:11 +0800 treeland-protocols (0.4.1) unstable; urgency=medium * update appearance -- Dingyuan Zhang Fri, 01 Nov 2024 11:07:40 +0800 treeland-protocols (0.4) unstable; urgency=medium * Initial release -- Dingyuan Zhang Tue, 12 Dec 2023 20:07:40 +0800 linuxdeepin-treeland-protocols-886890b/debian/control000066400000000000000000000010111521417363700227750ustar00rootroot00000000000000Source: treeland-protocols Priority: optional Maintainer: rewine Build-Depends: cmake (>= 3.4~), debhelper-compat (= 13), Standards-Version: 4.6.0 Section: dde Homepage: https://github.com/linuxdeepin/treeland-protocols #Vcs-Browser: https://salsa.debian.org/debian/treeland #Vcs-Git: https://salsa.debian.org/debian/treeland.git Rules-Requires-Root: no Package: treeland-protocols Section: dde Architecture: all Depends: ${misc:Depends}, Description: wayland protocols of treeland. linuxdeepin-treeland-protocols-886890b/debian/copyright000066400000000000000000000006111521417363700233320ustar00rootroot00000000000000Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: treeland-protocols Source: https://github.com/linuxdeepin/treeland-protocols Files: .github/* .obs/*.yml garnix.yaml Copyright: None License: CC0-1.0 Files: *.md README.md README.zh_CN.md CONTRIBUTING.md ChangeLog CONTRIBUTORS Copyright: UnionTech Software Technology Co., Ltd. License: MIT linuxdeepin-treeland-protocols-886890b/debian/rules000077500000000000000000000002361521417363700224620ustar00rootroot00000000000000#!/usr/bin/make -f # See debhelper(7) (uncomment to enable) # output every command that modifies files on the build system. #export DH_VERBOSE = 1 %: dh $@ linuxdeepin-treeland-protocols-886890b/debian/source/000077500000000000000000000000001521417363700227015ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/debian/source/format000066400000000000000000000000151521417363700241100ustar00rootroot000000000000003.0 (native) linuxdeepin-treeland-protocols-886890b/flake.lock000066400000000000000000000036361521417363700221230ustar00rootroot00000000000000{ "nodes": { "flake-utils": { "inputs": { "systems": "systems" }, "locked": { "lastModified": 1726560853, "narHash": "sha256-X6rJYSESBVr3hBoH0WbKE5KvhPU5bloyZ2L4K60/fPQ=", "owner": "numtide", "repo": "flake-utils", "rev": "c1dfcf08411b08f6b8615f7d8971a2bfa81d5e8a", "type": "github" }, "original": { "owner": "numtide", "repo": "flake-utils", "type": "github" } }, "nix-filter": { "locked": { "lastModified": 1730207686, "narHash": "sha256-SCHiL+1f7q9TAnxpasriP6fMarWE5H43t25F5/9e28I=", "owner": "numtide", "repo": "nix-filter", "rev": "776e68c1d014c3adde193a18db9d738458cd2ba4", "type": "github" }, "original": { "owner": "numtide", "repo": "nix-filter", "type": "github" } }, "nixpkgs": { "locked": { "lastModified": 1730531603, "narHash": "sha256-Dqg6si5CqIzm87sp57j5nTaeBbWhHFaVyG7V6L8k3lY=", "owner": "NixOS", "repo": "nixpkgs", "rev": "7ffd9ae656aec493492b44d0ddfb28e79a1ea25d", "type": "github" }, "original": { "owner": "NixOS", "ref": "nixos-unstable", "repo": "nixpkgs", "type": "github" } }, "root": { "inputs": { "flake-utils": "flake-utils", "nix-filter": "nix-filter", "nixpkgs": "nixpkgs" } }, "systems": { "locked": { "lastModified": 1681028828, "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=", "owner": "nix-systems", "repo": "default", "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e", "type": "github" }, "original": { "owner": "nix-systems", "repo": "default", "type": "github" } } }, "root": "root", "version": 7 } linuxdeepin-treeland-protocols-886890b/flake.nix000066400000000000000000000012601521417363700217600ustar00rootroot00000000000000{ description = "A basic flake to help develop"; inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; flake-utils.url = "github:numtide/flake-utils"; nix-filter.url = "github:numtide/nix-filter"; }; outputs = { self, nixpkgs, flake-utils, nix-filter }@input: flake-utils.lib.eachSystem [ "x86_64-linux" "aarch64-linux" "riscv64-linux" ] (system: let pkgs = nixpkgs.legacyPackages.${system}; treeland-protocols = pkgs.callPackage ./nix { nix-filter = nix-filter.lib; }; in { packages = { default = treeland-protocols; }; } ); } linuxdeepin-treeland-protocols-886890b/nix/000077500000000000000000000000001521417363700207555ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/nix/default.nix000066400000000000000000000013351521417363700231230ustar00rootroot00000000000000{ stdenv , lib , nix-filter , cmake , pkg-config , wayland-scanner }: stdenv.mkDerivation (finalAttrs: { pname = "treeland-protocols"; version = "0.4"; src = nix-filter.filter { root = ./..; exclude = [ ".git" "debian" "LICENSES" "README.md" "README.zh_CN.md" ]; }; depsBuildBuild = [ pkg-config ]; nativeBuildInputs = [ cmake pkg-config wayland-scanner ]; meta = { description = "Wayland protocol extensions for treeland"; homepage = "https://github.com/linuxdeepin/treeland-protocols"; license = with lib.licenses; [ gpl3Only lgpl3Only asl20 ]; platforms = lib.platforms.linux; maintainers = with lib.maintainers; [ rewine ]; }; }) linuxdeepin-treeland-protocols-886890b/xml/000077500000000000000000000000001521417363700207575ustar00rootroot00000000000000linuxdeepin-treeland-protocols-886890b/xml/treeland-app-id-resolver-v1.xml000066400000000000000000000061111521417363700266310ustar00rootroot00000000000000 Create a resolver object. Typically exactly one privileged helper (a Wayland client with DBus access) binds this interface and serves identification requests coming from the compositor. Create or bind a resolver object. Only one resolver may be registered per session. Treeland is a multi-user compositor; different user sessions may each register their own resolver. If a resolver is already bound in the same session, the compositor will report an error on the manager and will NOT create a new resolver object for this request. The compositor sends identify_request with a unique request_id and a pidfd. The client must answer exactly once via respond(request_id, app_id). If resolution fails respond with an empty string. Respond to an identify_request. The sandbox_engine_name must be provided and matches the context in which the process is running (container, sandbox, etc). If resolution fails, respond with an empty app_id. linuxdeepin-treeland-protocols-886890b/xml/treeland-capture-unstable-v1.xml000066400000000000000000000231251521417363700271020ustar00rootroot00000000000000 This protocol allows authorized application to capture output contents or window contents(useful for window streaming). Unreferences the frame. This request must be called as soon as it's no longer valid. Start session and keeps sending frame. This is the ACK to the current "ready" event. The next "frame" event will be sent only when current "ready" event is acknowledged. The timestamp should be the same as the one sent in "ready" event. If the frame has the "transient" flag, all objects sent before become invalid after this event. Main event supplying the client with information about the frame. If the capture didn't fail, this event is always emitted first before any other events. When mask is provided, x and y should be offset relative to mask surface origin. Otherwise offset_x and offset_y should always be zero. This event is sent as soon as the frame is presented, indicating it is available for reading. This event includes the time at which presentation happened at. If the capture failed or if the frame is no longer valid after the "frame" event has been emitted, this event will be used to inform the client to scrap the frame. Destroys the context. This request can be sent at any time by the client. Copy capture contents to provided buffer Inform client to prepare buffer. Inform client that all buffer formats supported are emitted. Provides flags about the frame. This event is sent once before the "ready" event. Inform that buffer is ready for reading Inform that frame copy fails. Destroys the context. This request can be sent at any time by the client. Selector is provided by compositor. Client can provide source hint to hint compositor to provide certain kinds of source. This event can be called just once. A second call might result in a protocol error cause we just provide transient Often used by a screen recorder. This event supplies the client some information about the capture source, including the capture region relative to mask and source type. There could a lot of reasons but the most common one is that selector is busy Destroy the treeland_capture_manager_v1 object. linuxdeepin-treeland-protocols-886890b/xml/treeland-dde-shell-v1.xml000066400000000000000000000357111521417363700254710ustar00rootroot00000000000000 This interface allows DDE change some treeland function. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. Create a shell surface for an existing wl_surface. Only one shell surface can be associated with a given surface. Recommended for use with xdg_surface. Create a new dde active for a given seat. Create a new multitaskview context for toggle. Create a new window picker to pick window. Create a new lockscreen context for toggle. Move the top-left point of a XWayland surface specified with Window ID, to a position that has (dx, dy) offset from the top-left point of a wl_surface Once the server finished process it send "done" to the callback. The callback data 0 means no error occured, 1 means something went wrong and the move cannot be done. Destroy the treeland_dde_shell_manager_v1 object. A treeland_dde_shell_handle_v1 object represents an opened toplevel window. Each app may have multiple opened toplevels. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. This event is sent when windows overlapped. This event is sent only once. This event is sent when windows not overlapped. This event is sent only once. same layershell This interface is used to receive the detected surface. When the xdgshell window in the workspace overlaps with the detected window, an event will be sent to notify the client to process it. The window position will only be recorded when this interface is called. If the window moves, this interface needs to be called again. Destroys the treeland_window_overlap_checker object. This request should be called either when the client does not want to use the toplevel anymore or after the closed event to finalize the destruction of the object. An interface that may be implemented by a wl_surface, for implementations that provide the shell user interface. It provides requests to set surface role, set skip, set the position set auto placement in output coordinates. On the server side the object is automatically destroyed when the related wl_surface is destroyed. On client side, treeland_dde_shell_surface_v1.destroy() must be called before destroying the wl_surface object. The treeland_dde_shell_surface_v1 interface is removed from the wl_surface object that was turned into a shell surface with the treeland_shell_v1.get_treeland_dde_shell_surface request. The shell surface role is lost and wl_surface is unmapped. Move the surface to new coordinates. Coordinates are global, for example 50,50 for a 1920,0+1920x1080 output is 1970,50 in global coordinates space. These values indicate which roles a surface can be rendered in, They are ordered by z depth. Displayed below wlr-layer-shell, at the overlay level of the workspace. Multiple surfaces can share a single role, and ordering within a single role is undefined. Assign a role to a shell surface. Set the vertical alignment of the surface within the cursor width. Do not use it together with set_surface_position to avoid exceptions. The position of the surface will be controlled by the compositor after the request, including preventing it from being displayed beyond the edge of the output. Setting this bit will indicate that the window prefers not to be listed in a switcher. Setting this bit will indicate that the window prefers not to be listed in a dock preview. Setting this bit will indicate that the window prefers not to be listed in a mutitask view. Setting this will determine whether the surface can receive keyboard focus. When set to 0, the surface will not receive keyboard focus even when clicked or activated. When set to 1 (default), the surface will receive keyboard focus normally. An interface used to monitor special events. An interface used to control multitaskview. Show or hide the multitaskview. An interface used to pick window and return credentials. Pick a window to get information. Picked window information. An interface used to operate lockscreen. Lock the screen. Show shutdown. Switch user. linuxdeepin-treeland-protocols-886890b/xml/treeland-ddm-v1.xml000066400000000000000000000060311521417363700243650ustar00rootroot00000000000000 This is the treeland - ddm private communication protocol. This object is primarily used for establish connection between treeland and ddm. Send treeland to Greeter mode. Set lockscreen user to username. Ignore when username is "ddm". Activate treeland session. This will makes treeland try to take control of screen. Deactivate treeland session. This will release control of the screen, but not to close the current seats. Enable treeland rendering. This is primarily called after disable_render to resume treeland. Disable treeland rendering. This will prevent treeland from output to DRM device. Destroys this treeland_ddm_v1 object. Call ddm to switch current virtual terminal to vtnr. ddm should take care of the switch and call ioctl respectively. Call ddm to acquire control of VT at vtnr. ddm should call VT_SETMODE respectively. linuxdeepin-treeland-protocols-886890b/xml/treeland-foreign-toplevel-manager-v1.xml000066400000000000000000000363601521417363700305220ustar00rootroot00000000000000 This interface allows a client to get toplevel some info. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. This event is emitted whenever a new toplevel window is created. It is emitted for all toplevels, regardless of the app that has created them. All initial details of the toplevel(title, app_id, states, etc.) will be sent immediately after this event via the corresponding events in treeland_foreign_toplevel_handle_v1. Indicates the client no longer wishes to receive events for new toplevels. However the compositor may emit further toplevel_created events, until the finished event is emitted. The client must not send any more requests after this one. This event indicates that the compositor is done sending events to the treeland_foreign_toplevel_manager_v1. The server will destroy the object immediately after sending this request, so it will become invalid and the client should free any resources associated with it. A treeland_foreign_toplevel_handle_v1 object represents an opened toplevel window. Each app may have multiple opened toplevels. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. This event will be sent when the compositor has set the process id this window belongs to. This should be set once before the initial_state is sent. This event is emitted whenever the title of the toplevel changes. This event is emitted whenever the app-id of the toplevel changes. The identifier of each top level and its handle must be unique. Two different top layers cannot have the same identifier. This identifier is only valid as long as the top level is mapped. Identifiers must not be reused if the top level is not mapped. The compositor must not reuse identifiers to ensure there are no races when identifiers are shared between processes. This event is emitted whenever the toplevel becomes visible on the given output. A toplevel may be visible on multiple outputs. This event is emitted whenever the toplevel stops being visible on the given output. It is guaranteed that an entered-output event with the same output has been emitted before this event. Requests that the toplevel be maximized. If the maximized state actually changes, this will be indicated by the state event. Requests that the toplevel be unmaximized. If the maximized state actually changes, this will be indicated by the state event. Requests that the toplevel be minimized. If the minimized state actually changes, this will be indicated by the state event. Requests that the toplevel be unminimized. If the minimized state actually changes, this will be indicated by the state event. Request that this toplevel be activated on the given seat. There is no guarantee the toplevel will be actually activated. The different states that a toplevel can have. These have the same meaning as the states with the same names defined in xdg-toplevel This event is emitted immediately after the treeland_foreign_toplevel_handle_v1 is created and each time the toplevel state changes, either because of a compositor action or because of a request in this protocol. This event is sent after all changes in the toplevel state have been sent. This allows changes to the treeland_foreign_toplevel_handle_v1 properties to be seen as atomic, even if they happen via multiple events. Send a request to the toplevel to close itself. The compositor would typically use a shell-specific method to carry out this request, for example by sending the xdg_toplevel.close event. However, this gives no guarantees the toplevel will actually be destroyed. If and when this happens, the treeland_foreign_toplevel_handle_v1.closed event will be emitted. The rectangle of the surface specified in this request corresponds to the place where the app using this protocol represents the given toplevel. It can be used by the compositor as a hint for some operations, e.g minimizing. The client is however not required to set this, in which case the compositor is free to decide some default value. If the client specifies more than one rectangle, only the last one is considered. The dimensions are given in surface-local coordinates. Setting width=height=0 removes the already-set rectangle. This event means the toplevel has been destroyed. It is guaranteed there won't be any more events for this treeland_foreign_toplevel_handle_v1. The toplevel itself becomes inert so any requests will be ignored except the destroy request. Destroys the treeland_foreign_toplevel_handle_v1 object. This request should be called either when the client does not want to use the toplevel anymore or after the closed event to finalize the destruction of the object. Requests that the toplevel be fullscreened on the given output. If the fullscreen state and/or the outputs the toplevel is visible on actually change, this will be indicated by the state and output_enter/leave events. The output parameter is only a hint to the compositor. Also, if output is NULL, the compositor should decide which output the toplevel will be fullscreened on, if at all. Requests that the toplevel be unfullscreened. If the fullscreen state actually changes, this will be indicated by the state event. This event is emitted whenever the parent of the toplevel changes. No event is emitted when the parent handle is destroyed by the client. This interface allows dock set windows preview. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. This event is sent after mouse enter preview box. This event is sent after mouse leave preview box. X and Y are relative to the relative_surface. surfaces wl_array is identifiers. close preview box Destroy the context object. linuxdeepin-treeland-protocols-886890b/xml/treeland-input-manager-unstable-v1.xml000066400000000000000000001162711521417363700302130ustar00rootroot00000000000000 This protocol allows a privileged client to discover seat capabilities and configure compositor-managed mouse, touchpad, and keyboard devices. A treeland_input_manager_v1 object is a global manager. It creates settings objects that represent configuration state for existing input devices; those settings objects are not the device objects themselves. For mouse and touchpad devices, pointer device settings such as acceleration speed, acceleration profile, natural scrolling, scroll factor, handed mode, double-click interval, send events mode, disable-while-typing and tap-to-click are managed through a treeland_pointer_device_configuration_v1 object created from the device-specific settings interface. The treeland_input_manager_v1 interface is a global object used to create per-device settings objects for input devices exposed by the compositor. The compositor advertises device capability changes with the capability_available and capability_unavailable events. For each target device or seat-level settings scope, the compositor may allow at most one live settings object of a given interface created from one manager object. virtual-pointer and virtual-keyboard are not included in the list. This informs the compositor that the treeland input manager object will no longer be used. Existing objects created through this interface are not destroyed automatically. Clients should destroy those objects before destroying the manager. Create a treeland_mouse_settings_v1 object bound to the specified wl_seat. The created object acts as a factory for treeland_pointer_device_configuration_v1 objects that manage mouse device settings on the target seat. The seat must currently expose mouse capability. If the seat does not identify a valid mouse-capable target, the compositor raises the protocol error. Note: 1. The treeland_mouse_settings_v1 object must be destroyed before the associated wl_seat is destroyed. Create a treeland_touchpad_settings_v1 object bound to the specified wl_seat. The created object acts as a factory for treeland_pointer_device_configuration_v1 objects that manage touchpad device settings on the target seat. The seat must currently expose touchpad capability. If the seat does not identify a valid touchpad-capable target, the compositor raises the protocol error. Note: 1. The treeland_touchpad_settings_v1 object must be destroyed before the associated wl_seat is destroyed. Create a treeland_keyboard_settings_v1 object bound to the specified wl_seat. The seat must currently expose keyboard capability. If the seat does not identify a valid keyboard-capable target, the compositor raises the protocol error. Note: 1. The treeland_keyboard_settings_v1 object must be destroyed before the associated wl_seat is destroyed. This event is emitted when the compositor detects that a seat now exposes the specified device capability. The compositor sends this event immediately after the treeland_input_manager_v1 object is created to report capabilities currently available on a seat. The compositor may also send this event later when input devices are hot-plugged and a seat gains the specified capability. A client may create a treeland_mouse_settings_v1 object for a given seat only if the compositor has advertised device_type mouse capability for that seat. Likewise, a client may create a treeland_touchpad_settings_v1 or treeland_keyboard_settings_v1 object for a given seat only if the compositor has advertised device_type touchpad or keyboard capability for that seat. This event is emitted when the compositor detects that a seat no longer exposes the specified device capability. The compositor may also send this event later when input devices are hot-unplugged and a seat loses the specified capability. If type includes mouse capability, the client must destroy any treeland_mouse_settings_v1 objects targeting the seat. This also destroys any treeland_pointer_device_configuration_v1 objects created from those mouse settings objects. If type includes touchpad capability, the client must destroy any treeland_touchpad_settings_v1 objects targeting the seat. This also destroys any treeland_pointer_device_configuration_v1 objects created from those touchpad settings objects. If type includes keyboard capability, the client must destroy any treeland_keyboard_settings_v1 objects targeting the seat. The treeland_pointer_device_configuration_v1 interface represents pending configuration for pointer devices associated with the parent device settings object. This object is created via get_pointer_configuration on a treeland_mouse_settings_v1 or treeland_touchpad_settings_v1 object. It collects configuration that applies to the associated device type. Requests on this object update pending state. The compositor applies the accumulated settings when the client sends apply. Destroying the object before apply discards any pending state that has not yet been applied. The compositor sends configuration events after object creation to report the current effective settings. It may later send additional state batches when those effective settings change for compositor-defined reasons. A done event terminates each event batch. Optional features supported by pointer devices. The compositor sends a feature event to indicate which features are supported by at least one device associated with the parent settings object. A client must only send a set request if the corresponding feature has been advertised. It is a protocol error to send a set request for a feature that has not been advertised. Pointer acceleration profiles. The semantics correspond to libinput acceleration profiles. Modes controlling whether the target pointer device should send events and whether those events depend on the presence of an external pointer device on the same seat. Destroy this treeland_pointer_device_configuration_v1 object. Destroying the object discards any pending state that has not yet been applied. Set a scaling factor applied to scroll axis delta generated by wheel and other continuous scrolling input sources. This request requires the scroll_factor feature to be advertised via the feature event. The compositor multiplies scroll axis values by the specified factor before forwarding them to clients. This affects continuous scroll delta only and does not modify discrete scroll step events. This request updates only the pending state associated with this object. The change takes effect after the next apply request. Sending this request or the corresponding apply request does not by itself cause a scroll_factor event to be emitted. delta = factor * _delta Set whether primary and secondary buttons use left-handed or right-handed ordering. This request requires the handed_mode feature to be advertised via the feature event. The change takes effect on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause a handed_mode event to be emitted. Set the pointer acceleration speed. This request requires the accel_speed feature to be advertised via the feature event. The change takes effect on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause an accel_speed event to be emitted. Set the acceleration profile. This request requires the acceleration_profile feature to be advertised via the feature event. The change takes effect on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause an acceleration_profile event to be emitted. Set how events from the target pointer device are delivered. This request requires the send_events_mode feature to be advertised via the feature event. The change takes effect on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause a send_events_mode event to be emitted. Enable or disable natural scrolling. This request requires the natural_scroll feature to be advertised via the feature event. The change takes effect on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause a natural_scroll event to be emitted. Enable or disable temporarily disabling pointer devices while the user is typing. This request requires the disable_while_typing feature to be advertised via the feature event. The change takes effect on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause a disable_while_typing event to be emitted. Enable or disable tap-to-click. This request requires the tap_to_click feature to be advertised via the feature event. The change takes effect on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause a tap_to_click event to be emitted. Ask the compositor to apply the pending pointer device configuration carried by this object. This event reports which optional features are supported by at least one device associated with the parent settings object. The compositor sends this event as part of the initial state batch after the treeland_pointer_device_configuration_v1 object is created. The compositor may also send this event again when devices are added to or removed from the target seat and the set of supported features changes. This event reports the current scroll factor used for wheel and similar scroll input. The compositor sends this event immediately after the treeland_pointer_device_configuration_v1 object is created as part of the initial state batch. Changes requested through set_scroll_factor do not cause this event to be emitted automatically. This event reports whether left-handed or right-handed button ordering is currently used. The compositor sends this event immediately after the treeland_pointer_device_configuration_v1 object is created as part of the initial state batch. Changes requested through set_handed_mode do not cause this event to be emitted automatically. This event reports the current pointer acceleration speed. The compositor sends this event immediately after the treeland_pointer_device_configuration_v1 object is created as part of the initial state batch. Changes requested through set_accel_speed do not cause this event to be emitted automatically. This event reports the current acceleration profile. The compositor sends this event immediately after the treeland_pointer_device_configuration_v1 object is created as part of the initial state batch. Changes requested through set_acceleration_profile do not cause this event to be emitted automatically. This event reports the current event delivery mode used for the target pointer device. The compositor sends this event immediately after the treeland_pointer_device_configuration_v1 object is created as part of the initial state batch. Changes requested through set_send_events_mode do not cause this event to be emitted automatically. This event reports whether natural scrolling is enabled. The compositor sends this event immediately after the treeland_pointer_device_configuration_v1 object is created as part of the initial state batch. Changes requested through set_natural_scroll do not cause this event to be emitted automatically. This event reports whether pointer devices are temporarily disabled while the user is typing. The compositor sends this event as part of the initial state batch if the disable_while_typing feature has been advertised. Changes requested through set_disable_while_typing do not cause this event to be emitted automatically. This event reports whether tap-to-click is enabled. The compositor sends this event as part of the initial state batch if the tap_to_click feature has been advertised. Changes requested through set_tap_to_click do not cause this event to be emitted automatically. This event indicates that the compositor failed to apply one or more pending pointer device configuration changes carried by this object. This event does not destroy the object. The client may continue using the object and send further requests. This event is sent once when all pointer device configuration state events in the current batch have been sent. The compositor must always end a batch of pointer device configuration state events with this event, regardless of whether it sends the initial state or a later update. The serial is used in a future get_pointer_configuration request to ensure the client's configuration is based on up-to-date state. The treeland_mouse_settings_v1 interface acts as a factory for treeland_pointer_device_configuration_v1 objects that manage mouse device settings on the target seat. A treeland_pointer_device_configuration_v1 object is created via get_pointer_configuration on this object. Destroy this treeland_mouse_settings_v1 object. Existing treeland_pointer_device_configuration_v1 objects created from this object are also destroyed. Create a treeland_pointer_device_configuration_v1 object for this mouse settings scope. The created object manages mouse device configuration on the target seat. The serial argument must match the serial from the most recent done event sent on the previous treeland_pointer_device_configuration_v1 object for this treeland_mouse_settings_v1 object. For the first creation, the serial should be 0. Only one treeland_pointer_device_configuration_v1 object may exist for this treeland_mouse_settings_v1 object at a time. Creating a second one without destroying the first is a protocol error. If the serial does not match the current state, the compositor may immediately send a failed event on the new treeland_pointer_device_configuration_v1 object. The treeland_touchpad_settings_v1 interface acts as a factory for treeland_pointer_device_configuration_v1 objects that manage touchpad device settings on the target seat. A treeland_pointer_device_configuration_v1 object is created via get_pointer_configuration on this object. Destroy this treeland_touchpad_settings_v1 object. Existing treeland_pointer_device_configuration_v1 objects created from this object are also destroyed. Create a treeland_pointer_device_configuration_v1 object for this touchpad settings scope. The created object manages touchpad device configuration on the target seat. The serial argument must match the serial from the most recent done event sent on the previous treeland_pointer_device_configuration_v1 object for this treeland_touchpad_settings_v1 object. For the first creation, the serial should be 0. Only one treeland_pointer_device_configuration_v1 object may exist for this treeland_touchpad_settings_v1 object at a time. Creating a second one without destroying the first is a protocol error. If the serial does not match the current state, the compositor may immediately send a failed event on the new treeland_pointer_device_configuration_v1 object. The treeland_keyboard_settings_v1 interface represents pending settings for all keyboard associated with the target seat. Requests on this object update pending keyboard state. The compositor applies the accumulated settings when the client sends apply. The compositor sends keyboard-specific state events after object creation to report the current effective settings for the target seat. It may later send additional state batches when those effective settings change for compositor-defined reasons. A done event terminates each event batch. Optional features supported by keyboard devices. The compositor sends a feature event to indicate which features are supported by at least one keyboard device associated with the target seat. A client must only send a set request if the corresponding feature has been advertised. It is a protocol error to send a set request for a feature that has not been advertised. Destroy this treeland_keyboard_settings_v1 object. Destroying the object discards any pending state that has not yet been applied. Set the keyboard repeat rate and delay to apply on the next apply request. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause a repeat event to be emitted. Set the num lock state to apply on the next apply request. This request requires the num_lock feature to be advertised via the feature event. This request updates only the pending state tracked by this object. Sending this request, or the following apply request, does not by itself cause a num_lock event to be emitted. Ask the compositor to apply the pending keyboard settings carried by this object. This event reports which optional features are supported by at least one keyboard device associated with the target seat. The compositor sends this event as part of the initial state batch after the treeland_keyboard_settings_v1 object is created. The compositor may also send this event again when keyboard devices are added to or removed from the target seat and the set of supported features changes. This event reports the current keyboard repeat configuration. The compositor sends this event immediately after the treeland_keyboard_settings_v1 object is created as part of the initial keyboard state batch. Changes requested through set_repeat do not cause this event to be emitted automatically. This event reports the current num lock state. The compositor sends this event immediately after the treeland_keyboard_settings_v1 object is created as part of the initial keyboard state batch. Changes requested through set_num_lock do not cause this event to be emitted automatically. This event indicates that the compositor failed to apply one or more pending keyboard settings carried by this object. This event does not destroy the object. The client may continue using the object and send further requests. This event is sent once when all keyboard state events in the current batch have been sent. The compositor must always end a batch of keyboard state events with this event, regardless of whether it sends the initial state or a later update. linuxdeepin-treeland-protocols-886890b/xml/treeland-keyboard-state-notify-unstable-v1.xml000066400000000000000000000277131521417363700316720ustar00rootroot00000000000000 This protocol allows privileged clients to subscribe to global keyboard state changes (e.g. Caps Lock, Num Lock). Clients create watcher objects through the manager global, each bound to a seat. The client then configures the watcher with set_modifiers to choose which modifiers to monitor, and set_flags to choose which event types (locked, unlocked, or both) to receive. Configuration changes are double-buffered and take effect atomically when the client sends apply. Both set_modifiers and set_flags can be called multiple times before apply; only the values from the most recent calls are committed. This allows changing the configuration at runtime without destroying and recreating the watcher. After apply, the compositor sends a current_state event for each watched modifier containing its current lock state, so the client can synchronize its initial state without waiting for the next physical key press. The compositor then sends state_changed events on the watcher whenever any of the watched modifiers changes lock state globally, regardless of which surface has keyboard focus. This protocol is observation-only. Keyboard state changes are never consumed or intercepted by this protocol. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. The treeland_keyboard_state_notify_manager_v1 interface is a singleton global object used to create watcher objects for monitoring keyboard state changes on a given seat. A client may create multiple watcher objects for the same seat if needed. Destroy this treeland_keyboard_state_notify_manager_v1 object. Existing watcher objects created through this interface are not destroyed automatically. Clients should destroy those objects before destroying the manager. Create a treeland_keyboard_state_watcher_v1 object for monitoring keyboard state changes on the given seat, or on all seats if seat is null. The watcher is created with no modifiers and no flags set by default. The client should use set_modifiers and set_flags on the watcher to configure what to monitor. Note: 1. The treeland_keyboard_state_watcher_v1 object must be destroyed before the associated wl_seat is destroyed. The treeland_keyboard_state_watcher_v1 interface represents a subscription to keyboard state changes on a specific seat. This object is created via get_keyboard_state_watcher on the treeland_keyboard_state_notify_manager_v1 global. The client configures the watcher with set_modifiers to choose which modifiers to monitor and set_flags to choose which state transitions to receive. Both can be changed at runtime. Configuration changes are double-buffered: set_modifiers and set_flags only update the pending state, which is applied atomically when apply is called. The compositor sends a current_state event for each modifier in the committed modifier set immediately after apply is called. It then sends state_changed events whenever any of the watched modifiers changes lock state, according to the committed modifiers and flags. Bitfield of keyboard modifiers whose lock state can be monitored. Multiple modifier values can be combined using bitwise OR. caps_lock: the Caps Lock modifier. num_lock: the Num Lock modifier. scroll_lock: the Scroll Lock modifier. Examples: caps_lock: monitor only Caps Lock. caps_lock | num_lock: monitor both Caps Lock and Num Lock. Flags to specify which modifier lock state transitions the client wants to be notified about. none: do not notify on any state transition. locked: notify when a watched modifier becomes locked. unlocked: notify when a watched modifier becomes unlocked. Examples: locked: the client receives events only when a modifier is locked. unlocked: the client receives events only when a modifier is unlocked. locked | unlocked: the client receives events on both. The current lock state of a keyboard modifier. Destroy this treeland_keyboard_state_watcher_v1 object and stop receiving keyboard state notifications. Set the keyboard modifiers to watch on this watcher. The modifiers argument is a bitfield of values from the modifier enum (e.g. caps_lock = 1, num_lock = 2, scroll_lock = 4). Multiple modifiers can be combined using bitwise OR. Calling set_modifiers replaces any previously pending modifiers. This request only updates the pending configuration. The change takes effect when apply is called. If set_modifiers is called multiple times before apply, only the values from the most recent call are used. Change the watch flags for this watcher, selecting which modifier state transitions (locked, unlocked, or both) the client wants to be notified about. This request only updates the pending configuration. The change takes effect when apply is called. If set_flags is called multiple times before apply, only the values from the most recent call are used. Apply the pending configuration state for this watcher atomically. The compositor will use the modifiers and flags set by the most recent set_modifiers and set_flags calls as the new active configuration for this watcher. If set_modifiers or set_flags have not been called since the last apply (or since the watcher was created), the corresponding pending values remain unchanged. After this request, the pending configuration is considered consumed. Subsequent calls to set_modifiers or set_flags will begin a new pending configuration. The compositor will send a current_state event for each modifier in the newly committed modifier set immediately after processing this request. Sent for each modifier in the committed modifier set after each apply call to provide its current lock state. For example, if the client watches caps_lock and num_lock, the compositor will send two current_state events, one for each modifier. This event is emitted before any subsequent state_changed events for the new configuration. It may be sent again after future apply calls if the client reconfigures the watcher. This event is sent when one of the watched modifiers changes lock state globally, according to the modifiers and flags currently set on this watcher. The modifier argument identifies which modifier changed state. The state argument indicates whether the modifier is now locked or unlocked. linuxdeepin-treeland-protocols-886890b/xml/treeland-output-manager-v1.xml000066400000000000000000000115001521417363700265660ustar00rootroot00000000000000 Protocol for telling which is the primary display among the selection of enabled outputs. Specifies which output is the primary one identified by their name. Protocol for controlling color temperature and brightness settings of a specific output. Color temperature settings are applied only after a commit request is made. Setting a value outside the range [1000, 20000] is a protocol error. Brightness settings are applied only after a commit request is made. Setting a value outside the range [0.0, 100.0] is a protocol error. Provides the current color temperature setting of the output. Color temperature is valued in the range [1000, 20000]. Color temperature is defined as the corresponding temperature (in Kelvin) of the current white point of the display on a Planckian locus. With the current implementation, the neutral temperature is 6600K. This event is sent once after the treeland_output_color_control_v1 object is created, or right after when a color temperature change for the output is successfully commited. Provides the current brightness setting of the output. Brightness is valued in the range [0.0, 100.0]. This event is sent once after the treeland_output_color_control_v1 object is created, or right after when a brightness change for the output is successfully commited. linuxdeepin-treeland-protocols-886890b/xml/treeland-personalization-manager-v1.xml000066400000000000000000000424551521417363700304640ustar00rootroot00000000000000 This interface allows a client to customized display effects. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. set window background, shadow based on context custom user cursor custom treeland and window global font context custom user treeland window appearance global This interface allows a client personalization cursor. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. if only one commit fails validation, the commit will fail Destroy the context object. Send this signal after commit cursor configure. Send this signal after system cursor theme changed. Send this signal after system cursor size changed. This interface allows a client personalization window. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. Window blend mode defines how compositor composite window's surface over other surfaces. Set window background blend mode This request will set window round corner radius, invoking this request means user want to manage window round corner radius by itself. If not invoked, window round corner radius will be decided by compositor. Set window shadow's radius, offset and color, invoking this request indicates that client want to manage the window shadow by itself. If not invoked, window shadow will be decided by the compositor Set window border width and color Set window enable mode Set if system titlebar is enabled Destroy the context object. This interface allows set treeland window global font settings. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. Send this signal after setting the system font. Send this signal after setting the system monospace font. Send this signal after setting the system font size. Set the system font size Get the system font size Set the system font Get the system font Set the system monospace font Get the system monospace font Destroy the context object. This interface allows set treeland window global appearance settings. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. Send this signal after setting the round corner radius. Send this signal after setting the system icon theme. Send this signal after setting the system active color Send this signal after setting the system active color Send this signal after setting the system theme Send this signal after setting the window titlebar height Set window round corner radius Get window round corner radius Set the system icon theme Get the system icon theme Set the system active color Get the system active color Set the window window opacity Get the window window opacity Set the window theme. Get the window theme type Set the window titlebar height Get the window titlebar height Destroy the context object. linuxdeepin-treeland-protocols-886890b/xml/treeland-prelaunch-splash-v1.xml000066400000000000000000000043071521417363700270760ustar00rootroot00000000000000 This interface is a manager for creating prelaunch splash screens. A prelaunch splash screen is a placeholder surface that is shown before an application's main window is mapped. This helps to improve the perceived startup time. It is particularly useful for application launchers to provide immediate feedback to the user. Creates a new prelaunch splash screen. The `app_id` is a string that identifies the application. The compositor will use this ID together with `sandbox_engine_name` to match the splash screen with the actual application window when it appears. This matching mechanism should also work for XWayland windows. Callers MUST provide a non-empty `sandbox_engine_name` string which identifies the sandboxing/container. If there is already an active (not-yet-completed) splash for the same `sandbox_engine_name` and `app_id`, the compositor will silently ignore this request (no new splash will be created and no error is raised). linuxdeepin-treeland-protocols-886890b/xml/treeland-prelaunch-splash-v2.xml000066400000000000000000000066611521417363700271040ustar00rootroot00000000000000 This interface is a manager for creating prelaunch splash screens. A prelaunch splash screen is a placeholder surface that is shown before an application's main window is mapped. This helps to improve the perceived startup time. It is particularly useful for application launchers to provide immediate feedback to the user. Compared to treeland_prelaunch_splash_manager_v1, this version returns a splash object from create_splash. The caller can destroy the object to dismiss the splash, and the compositor can send events (e.g. timeout) back to the caller through the object. Creates a new prelaunch splash screen and returns a splash object. The `app_id` is a string that identifies the application. The compositor will use this ID together with `sandbox_engine_name` to match the splash screen with the actual application window when it appears. This matching mechanism should also work for XWayland windows. The `instance_id` identifies a specific application instance, allowing multiple splashes for non-singleton applications. The compositor can use this to associate a splash with a particular launch instance. Callers MUST provide a non-empty `sandbox_engine_name` string which identifies the sandboxing/container. Represents a single prelaunch splash screen created by the manager. The caller can destroy this object to dismiss the corresponding splash. The compositor may also send events through this object, for example to notify the caller that the splash was closed due to a timeout. Dismisses the splash screen and destroys this object. linuxdeepin-treeland-protocols-886890b/xml/treeland-screensaver-v1.xml000066400000000000000000000045311521417363700261440ustar00rootroot00000000000000 This object implements a simple idle inhibit protocol used to implement org.freedesktop.ScreenSaver D-Bus interface. Call inhibit to prevent treeland from entering idle state. Call uninhibit or disconnect from the global to release the inhibit. If the client disconnects from the compositor, the inhibit associated with that client is automatically released. There can be only one inhibit per client per time. Calling inhibit multiple times will raise an error. Call uninhibit before inhibit to update application_name and reason recorded. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. Inhibit idleness with given application_name and reason_for_inhibit. Uninhibit idleness previously inhibited by inhibit request. linuxdeepin-treeland-protocols-886890b/xml/treeland-shortcut-manager-v1.xml000066400000000000000000000047451521417363700271160ustar00rootroot00000000000000 This interface allows a client to get some shell's info. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. The format of the shortcut key is 'Modify+Key', such as 'Ctrl+Alt+T'. If the format is wrong, the synthesizer will give a "format error". If the shortcut key is already registered, the compositor will give a "register error" and issue a destruction to the context. This interface allows a client to listen a shortcut action. Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. Destroy the context object. linuxdeepin-treeland-protocols-886890b/xml/treeland-shortcut-manager-v2.xml000066400000000000000000000442401521417363700271110ustar00rootroot00000000000000 This interface allows privileged clients to register global shortcuts. In treeland, global shortcuts are managed in a per-user context. Shortcuts for different users are isolated, and will not interfere with each other. This allows multiple users to use their own set of global shortcuts on the same system without conflicts. This behavior is transparent to the clients of this interface (i.e., the user context used by this protocol is the same as that of the client.) Warning! The protocol described in this file is currently in the testing phase. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes can only be done by creating a new major version of the extension. Compositor actions that can be assigned to a shortcut. Flags to specify the keybinding mode. With key_press, the action is triggered on key press. With key_release, the action is triggered on key release. With repeat, the action is repeatedly triggered if the key is held down. Examples: key_press | repeat: the action is triggered on key press, and repeatedly triggered if the key is held down. key_press | key_release: the action is triggered on both key press and key release, auto-repeated events are ignored. key_press | key_release | repeat: note that treeland repeats both key press and key release events. Error codes indicating the reason of a binding failure. Destroy the shortcut manager. Existing shortcuts created through this interface remain valid. Acquire the shortcut manager for the current client. This request must be sent before any bind/unbind request can be performed. Only one client can hold exclusive control of the shortcut manager at a time, for a given session. If the shortcut manager is already acquired by another client, the compositor will raise the `occupied` protocol error. Bind a key sequence to a compositor action. The key sequence is specified in the string format used by QKeySequence, see https://doc.qt.io/qt-6/qkeysequence.html#toString for details. Sending this request without first acquiring the shortcut manager will result in a `not_acquired` protocol error. The name argument must be unique among all existing bindings. If a binding with the same name already exists, the bind_key request will fail. The action argument specifies the compositor action to be executed when the key sequence is activated. Each keybind has a flags argument that specifies the exact triggering condition, see the documentation of the keybind_flag enum for details. If a binding with the same key sequence and action already exists, its flags will be updated to the new value. Note that the binding will not take effect until a commit request is sent. Bind a swipe gesture to a compositor action. Sending this request without first acquiring the shortcut manager will result in a `not_acquired` protocol error. The name argument must be unique among all existing bindings. If a binding with the same name already exists, the bind_swipe_gesture request will fail. The direction argument specifies the direction towards which the swipe gesture must be performed. If this argument is not one of the defined enum values, the bind_swipe_gesture request will fail. The action argument specifies the compositor action to be executed when the swipe gesture is activated. If a binding with the same gesture and action already exists, the bind_swipe_gesture request will fail. Note that the binding will not take effect until a commit request is sent. Bind a hold gesture to a compositor action. Sending this request without first acquiring the shortcut manager will result in a `not_acquired` protocol error. The name argument must be unique among all existing bindings. If a binding with the same name already exists, the bind_hold_gesture request will fail. The action argument specifies the compositor action to be executed when the hold gesture is activated. If a binding with the same gesture and action already exists, the bind_hold_gesture request will fail. Note that the binding will not take effect until a commit request is sent. Commit the pending bindings. This request applies all the bind_key, bind_swipe_gesture and bind_hold_gesture requests sent since the last commit. After processing this request, the compositor will emit a `commit_success` event if the commit was successful or `commit_failure` event if the commit failed. On a successful commit, all the pending bindings will take effect. On a failed commit, none of the pending bindings will take effect. Sending this request without first acquiring the shortcut manager will result in a `not_acquired` protocol error. Sending further commit requests before `commit_success` or `commit_failure` is sent is a protocol error. Remove an existing binding. Sending this request without first acquiring the shortcut manager will result in a `not_acquired` protocol error. The binding to be removed is identified by its unique name. If no binding with the specified name exists, the unbind request has no effect. Request the compositor to capture the next shortcut input once, bound to the provided surface. The capture object is created by this request via new_id. The compositor performs validation after receiving the request, and may immediately emit a terminal event on the newly created object. Clients must be prepared to handle a capture object that is failed immediately after creation. The surface argument must be a wl_surface owned by the requesting client. Otherwise, the compositor will raise the `invalid_surface` protocol error. The compositor must verify that the provided surface currently has keyboard focus or is active before starting capture. If this check fails, the compositor must first decide that capture does not start, and then must emit `failed` with reason `not_active` on the created object. The compositor monitors both key_press and key_release events during capture. The shortcut candidate is established on key_press of a valid non-modifier key; the terminal event (captured or failed) is sent on key_release of that non-modifier key. Pure modifier-only key presses (e.g. Ctrl, Alt, Shift) are silently consumed while waiting for a non-modifier key. Auto-repeat events are consumed and ignored. If the next intercepted input is not a valid shortcut input (for example: unmodified alphanumeric keys such as a, b, c, d, 1, 2, 3, unmodified Escape, or pointer button and wheel events), the compositor must fail capture with reason `interrupted`. For either `interrupted` failure or successful `captured`, the triggering input event must be consumed by the compositor and must not be forwarded to the client. The compositor creates a treeland_shortcut_capture_v1 object and starts a one-shot capture flow for this request. This request does not modify existing shortcut bindings. This request does not require acquire. This event is emitted when a binding registered with action `notify` is activated. The flags argument indicates the type of key event as defined in the keybind_flag enum. This event is emitted in response to a commit request, indicating that the commit was successful. This event is emitted in response to a commit request, indicating that the commit has failed. The error argument indicates the first error that caused the commit to fail. This object represents one request to capture the next shortcut input. After creation, the compositor captures input once and may send at most one terminal event: either captured or failed. If the client destroys this object while capture is pending, no terminal event is sent. After a terminal event is sent, this object becomes inert. The client should destroy this object promptly after receiving captured or failed. Reasons why a one-shot capture could not complete. Destroy this capture object. Destroying the object cancels capture if it is still pending. The compositor captured one shortcut input for this request. The key argument uses the same textual format as bind_key. The compositor could not complete this capture request. linuxdeepin-treeland-protocols-886890b/xml/treeland-virtual-output-manager-v1.xml000066400000000000000000000127031521417363700302600ustar00rootroot00000000000000 This interface is a manager that allows the creation of copied output. Create virtual output that can be used when setting screen copy mode for use on multiple screens. Virtual outputs are created to mirror multiple wl_output outputs. The name argument must not be empty. If name is empty, the compositor emits an error event with code invalid_group_name. The element of the array is the name of the screen. The first element of the array outputs is the screen to be copied, and the subsequent elements are the screens to be mirrored. The outputs array must contain at least two elements. If the number of elements is less than two, the compositor emits an error event with code invalid_screen_number. If any output name in the outputs array does not exist, the compositor emits an error event with code invalid_output. The client calling this interface will not generate an additional wl_output object on the client. Gets a list of virtual output names. The compositor emits one virtual_output_list event for each request. Clients should avoid issuing a new get_virtual_output_list request before receiving the corresponding event. Sends a list of virtual output names to the client. The client obtains the corresponding virtual_output_v1 object through the virtual output name. A treeland_virtual_output_v1 represents a set virtual screen output object. This event is sent to the client when any screen in the array changes. The element of the array is the name of the screen. The first element of the array outputs is the screen to be copied, and the subsequent elements are the screens to be mirrored. When the primary screen (the screen being copied) is removed, a successor is selected from the queue as the primary screen, and the queue information is updated. When an error occurs, an error event is emitted, terminating the replication mode request issued by the client. The code argument uses treeland_virtual_output_v1.error. Destroy the output. linuxdeepin-treeland-protocols-886890b/xml/treeland-wallpaper-color-v1.xml000066400000000000000000000030541521417363700267260ustar00rootroot00000000000000 Monitor the wallpaper color of a given screen. Stop monitor the wallpaper color for the given screen. The client no longer cares about wallpaper_color. Tell the client that the wallpaper color of the screen it is monitoring has changed. This event will also be sent immediately when the client requests a watch. linuxdeepin-treeland-protocols-886890b/xml/treeland-wallpaper-manager-unstable-v1.xml000066400000000000000000000223211521417363700310330ustar00rootroot00000000000000 The treeland_wallpaper_manager_v1 interface is a global object used to create wallpaper objects for specific outputs. Destroy this treeland_wallpaper_manager_v1 object. Destroying a bound treeland_wallpaper_manager_v1 object while there are wallpapers still alive created by this treeland_wallpaper_manager_v1 object instance is illegal and will result in a protocol error. Creates a treeland_wallpaper_v1 object bound to the specified wl_output. The compositor may enforce that only one wallpaper exists for a given (output, role) combination. When a surface is associated, the compositor will track the workspace the surface belongs to. Whenever the workspace changes, the compositor may notify the client of the current wallpaper file path used by that workspace. Note: 1. The treeland_wallpaper_v1 object must be destroyed before the associated wl_output is destroyed. 1. The treeland_wallpaper_v1 object must be destroyed before the associated wl_surface is destroyed. The treeland_wallpaper_v1 interface represents a wallpaper instance created by the compositor for a specific output, role. The wallpaper source provided by the client is stored and managed on the compositor side. Once a wallpaper source has been set, the compositor may cache, reuse, or persist the source independently of the client. Destroys the treeland_wallpaper_v1 object and releases all resources associated with it on the compositor side. After calling this request, the client must not use the wallpaper object anymore. Sets an image as the wallpaper source, apply to the current wl_output and the active workspace. except for lockscreen wallpapers, only one wallpaper can be set per wl_output. Supported formats: - JPG / JPEG (Joint Photographic Experts Group) The compositor will attempt to load and display the specified image file. If the file cannot be accessed, decoded, or is in an unsupported format, the compositor will emit a failed event with an appropriate error code. Access Control: This protocol accepts file_source such as /usr/share/wallpapers/xxx or /var/cache/wallpapers/xxxx provided by the client. the compositor will perform file verification. Sets a video file as the wallpaper source, apply to the current wl_output and the active workspace. except for lockscreen wallpapers, only one wallpaper can be set per wl_output. Supported formats: - MP4 - AVI - MOV The compositor is responsible for decoding and presenting the video. Playback behavior such as looping, synchronization, and performance characteristics are compositor-defined. If the video source cannot be opened or decoded, a failed event will be emitted. Access Control: This protocol accepts file_source such as /usr/share/wallpapers/xxx or /var/cache/wallpapers/xxxx provided by the client. the compositor will perform file verification. This event is emitted when a wallpaper-related request fails. The failure may occur during source loading, validation, or runtime setup. The error code provides additional information about the cause of the failure. Possible error values include: - already_used: The wallpaper source is already configured. This is not a fatal error and serves as a notification to the client. - invalid_source: The specified wallpaper source is invalid, unsupported, or could not be processed. This is a fatal error and the client should verify the source before retrying. - Permission denied, check file permissions. This event is emitted by the compositor to notify the client that the wallpaper source associated with this treeland_wallpaper_v1 object has changed. The event may be emitted during initial object setup or when the wallpaper is changed due to external factors not initiated by this client, such as compositor policy decisions, workspace switches (except for lockscreen wallpapers) that affect the active wallpaper, or other system components. Because the desktop wallpaper is designed to support different workspaces. if the client is a surface, changes to its displayed workspace will also send (reference set_reference_surface). The event provides the current wallpaper source type and the corresponding source file path. linuxdeepin-treeland-protocols-886890b/xml/treeland-wallpaper-shell-unstable-v1.xml000066400000000000000000000265661521417363700305470ustar00rootroot00000000000000 The treeland_wallpaper_notifier_v1 interface provides notifications about the availability and lifetime of wallpaper sources managed by the compositor. This interface is purely event-driven. Clients receive events when wallpaper sources are added, become active, or are removed, and may update their internal state or user interface accordingly. Destroys this treeland_wallpaper_notifier_v1 object. Destroying a bound treeland_wallpaper_notifier_v1 object while wallpaper surface objects created from it are still alive is illegal and will result in a protocol error. This event is sent by the compositor when a new wallpaper source is added or becomes active. The source_type argument describes the type of the wallpaper source. The meaning of the file_source argument depends on the reported source_type. This event indicates that the wallpaper source identified by file_source is no longer available. After receiving this event, the client should discard any internal state associated with the wallpaper source and must not reference it anymore. The treeland_wallpaper_shell_v1 interface is a global object exposed by the compositor that allows a client to assign the wallpaper role to a wl_surface and create wallpaper surface objects. A wallpaper surface represents content intended to be displayed as the desktop wallpaper, such as a static image or a dynamic media source, and is associated with exactly one wl_surface. This interface follows the shell pattern used by other Wayland protocols: it assigns a specific role to a wl_surface and manages the lifetime and behavior of wallpaper surfaces. This interface is a singleton. At most one client may bind to treeland_wallpaper_shell_v1 at any given time. Destroys this treeland_wallpaper_shell_v1 object. Destroying a bound treeland_wallpaper_shell_v1 object while there are still treeland_wallpaper_surface_v1 objects created from it is illegal and will result in a protocol error. Creates a treeland_wallpaper_surface_v1 object and assigns the wallpaper role to the given wl_surface. The provided wl_surface must not already have a role, and while it is used as a wallpaper surface, it must not be assigned any other role. The file_source argument specifies the initial wallpaper source identifier. Its interpretation depends on the wallpaper source type selected by the compositor. The treeland_wallpaper_surface_v1 interface controls the behavior of a wallpaper surface. A wallpaper surface is bound to exactly one wl_surface and defines how that surface should be sized, positioned, and synchronized with the compositor's wallpaper management logic. Destroy the wallpaper surface object and release its association with the underlying wl_surface. After calling this request, the wallpaper surface object becomes invalid and must not be used again. This request should only be sent when the client intends to permanently stop using the wallpaper surface, such as when the client is shutting down or after receiving the treeland_wallpaper_produce_v1.removed event for this surface. Reports to the compositor that a wallpaper-related operation has failed on the client side. This request may be sent by the client when it fails to open, load, or otherwise process the configured wallpaper source. The compositor may use this information for diagnostics, policy decisions, or to adjust internal state. Possible error values include: - invalid_source: The specified wallpaper source is invalid, unsupported, or could not be processed. This is a fatal error and indicates that the source should be verified before retrying. - permission_denied: The client does not have permission to access the specified wallpaper source. Informs the compositor that the wallpaper surface has completed its initial rendering and is ready to be displayed. The client should send this request only after a valid buffer has been attached and committed to the associated wl_surface. Before receiving this request, the compositor may keep the wallpaper hidden or continue displaying a fallback wallpaper. This request is typically used to avoid visual glitches such as black frames, incomplete rendering, or uninitialized content during wallpaper startup. Calling this request multiple times has no additional effect. This event provides a position value associated with the wallpaper. The semantic meaning of the position value is compositor-defined. It may represent a scroll offset, animation progress, or playback position. The value is expressed as a fixed-point number[0, 1.0]. This event instructs the client to pause wallpaper updates or animations. After receiving this event, the client should stop advancing any time-based or animated wallpaper content until a play event is received. Sets the playback speed of the wallpaper content. A rate of 1.0 represents normal speed. A rate of 0.0 represents a paused state. This event instructs the client to resume wallpaper updates or animations after a pause. This event instructs the client to progressively reduce the playback or animation update rate of the wallpaper content until it comes to a complete stop. The slowdown should be smooth and continuous rather than abrupt. The duration argument specifies the amount of time, in milliseconds, over which the slowdown should occur. After this duration has elapsed, the client should consider the wallpaper paused. A duration of 0 means the client should pause immediately. linuxdeepin-treeland-protocols-886890b/xml/treeland-window-management-v1.xml000066400000000000000000000034061521417363700272450ustar00rootroot00000000000000 This interface manages application windows. It provides requests to show and hide the desktop and emits an event every time a window is created so that the client can use it to manage the window. Only one client can bind this interface at a time. Tell the compositor to show/hide the desktop. This event will be sent whenever the show desktop mode changes. E.g. when it is entered or left. On binding the interface the current state is sent. linuxdeepin-treeland-protocols-886890b/xml/treeland-wine-window-management-unstable-v1.xml000066400000000000000000000346251521417363700320270ustar00rootroot00000000000000 This protocol provides privileged window management capabilities required by Wine (the Windows API compatibility layer) that are not available through standard Wayland protocols. Standard xdg-shell intentionally prevents clients from setting their own screen position or controlling z-order. Wine applications rely heavily on absolute positioning (SetWindowPos, MoveWindow) and stacking control (HWND_TOPMOST, HWND_TOP) to implement the Windows window management model. This protocol bridges that gap by allowing a trusted Wine client to request positioning and stacking changes while leaving the compositor the final authority over actual placement. A client obtains a treeland_wine_window_control_v1 object for each xdg_toplevel it wishes to manage. Requests on that object express the client's desired geometry and stacking. The compositor applies or adjusts them and reports the actual result through events. A Wine session is the set of all treeland_wine_window_control_v1 objects created through the same treeland_wine_window_manager_v1 global binding. window_id values emitted by the window_id event are unique and valid only within that set. The compositor must enforce this boundary: a sibling_id supplied to set_z_order that refers to a control object from a different manager binding must be treated as if no matching sibling exists, causing hwnd_insert_after to have no effect. The key words "must", "must not", "should", "should not", and "may" in this document are to be interpreted as described in IETF RFC 2119. Lets a Wine client create per-toplevel control objects. The compositor should restrict binding to trusted clients identified by app_id or an equivalent policy mechanism. The client must destroy all child treeland_wine_window_control_v1 objects before destroying this object. Destroys this manager object. The client must destroy every treeland_wine_window_control_v1 created through this manager before sending this request; otherwise the compositor must raise an implementation-defined protocol error. Creates a treeland_wine_window_control_v1 bound to the given xdg_toplevel. At most one control object may exist for each toplevel; requesting a second one is a toplevel_already_controlled error. If the xdg_toplevel has been destroyed or has no configured role the compositor must raise a defunct_toplevel error. Controls the screen geometry and stacking order for one xdg_toplevel surface. All coordinate values are in the compositor's global logical coordinate space (the same space used by wl_output.geometry and xdg_output.logical_position). Position requests are not applied immediately. The compositor processes them and reports the result via configure_position. The client should treat the values in configure_position as authoritative and update its internal state accordingly. If the associated xdg_toplevel is destroyed, this object becomes inert. All subsequent requests are ignored and no further events are emitted. The client should destroy the inert object. Window size is managed through the standard xdg_toplevel configure / xdg_surface.ack_configure mechanism. This interface only controls screen position and stacking order. Encodes the Windows SetWindowPos hWndInsertAfter parameter directly. The first four values correspond to the four special HWND constants. hwnd_insert_after requires a non-zero sibling_id in set_z_order. hwnd_topmost and hwnd_notopmost change WS_EX_TOPMOST tier membership; the compositor must preserve the resulting tier until explicitly changed. hwnd_bottom also clears topmost. hwnd_top does not alter tier membership. This is a superset of what the Wine X11 driver implements: the X11 driver tracks only the topmost flag and a boolean "raise to top", skipping HWND_BOTTOM and sibling-relative ordering (see sync_window_position comment in winex11.drv). This protocol implements all five Windows cases. Destroys the control object. This does not affect the associated xdg_toplevel or its current position on screen. Requests that the compositor place this window at the specified position in the compositor's global logical coordinate space. The client must supply a non-zero serial that monotonically increases with each request, starting from 1. The compositor echoes this serial in the resulting configure_position event so the client can correlate responses to requests. The requested position must fall within the bounds of an active screen. If the compositor determines that (x, y) is outside all screen regions, it rejects the request and emits a configure_position event reporting the current unchanged position. Even for valid positions the compositor does not guarantee exact placement: it may adjust the position to respect window management rules or layer-shell exclusive zones. The client must treat the values in the resulting configure_position event as authoritative and update its internal state accordingly. Window size changes must use the standard xdg_toplevel configure / xdg_surface.ack_configure flow and are outside the scope of this protocol. Corresponds to the position component of the Windows SetWindowPos and MoveWindow APIs. Requests a Z-order change that directly encodes the Windows SetWindowPos hWndInsertAfter parameter. For ops hwnd_top, hwnd_bottom, hwnd_topmost, and hwnd_notopmost, sibling_id must be 0; a non-zero value is an invalid_sibling error. For op hwnd_insert_after, sibling_id must be the window_id of a control object in the same Wine session as emitted by the window_id event on that control. The compositor places this surface directly below the identified sibling in Z-order. If sibling_id is 0 or does not identify a live surface in the same session, the compositor must ignore the request and leave the current Z-order unchanged. hwnd_insert_after must not mix tiers: if the sibling is in a different tier from this surface, the compositor must clamp to hwnd_top within the appropriate tier. The compositor reports the resulting stacking state via configure_stacking. Note: hwnd_top and hwnd_insert_after do not change tier membership and therefore do not emit configure_stacking. Emitted by the compositor immediately after this control object is created, before any configure_position or configure_stacking event. The id is a non-zero uint32 that uniquely identifies this toplevel within the current Wine session for the lifetime of this control object. The Wine driver must store this mapping (HWND to window_id) in wineserver shared memory so that other Wine processes in the same session can look up the sibling_id to use in set_z_order requests. Sent by the compositor to inform the client of the actual window position in the compositor's global logical coordinate space. This event is emitted: - immediately after window_id on initial creation, - in response to set_position requests, - when the user or compositor moves the window. The serial field echoes the serial from the set_position request that caused this event. If the position change was not initiated by a set_position request (e.g. initial creation, user drag, or compositor policy), serial is 0. Window size is communicated via the standard xdg_toplevel configure event and is not reported here. The client should use these coordinates to synchronize its internal window state (e.g. update the wineserver window rectangles with the correct screen origin). Sent by the compositor to report whether this toplevel is currently in the topmost tier (WS_EX_TOPMOST equivalent). This event is emitted: - immediately after window_id and configure_position on initial creation, to report the current tier state, - in response to set_z_order requests that change tier membership (hwnd_topmost, hwnd_notopmost, hwnd_bottom), - when the compositor changes tiers on its own initiative. Note: hwnd_top and hwnd_insert_after do not change tier membership and therefore do not trigger this event. linuxdeepin-treeland-protocols-886890b/xml/treeland-wine-window-state-unstable-v1.xml000066400000000000000000000315401521417363700310240ustar00rootroot00000000000000 This protocol provides window state management capabilities required by Wine (the Windows API compatibility layer) that are not available through standard Wayland protocols. Standard xdg-shell lacks: - any way to read whether a toplevel is minimized, - any way to programmatically unminimize a toplevel, - any way to request activation without a valid xdg-activation token originating from a prior user interaction, - any way to request a visual attention hint (taskbar flash) without stealing focus. This protocol fills those gaps. A client obtains a treeland_wine_window_state_v1 object for each xdg_toplevel whose state it needs to observe or control. The compositor remains the final authority: every request is advisory, and the compositor reports the authoritative state through events. The key words "must", "must not", "should", "should not", and "may" in this document are to be interpreted as described in IETF RFC 2119. Lets a Wine client create per-toplevel state objects. The compositor should restrict binding to trusted clients identified by app_id or an equivalent policy mechanism. The client must destroy all child treeland_wine_window_state_v1 objects before destroying this object. Destroys this manager object. The client must destroy every treeland_wine_window_state_v1 created through this manager before sending this request; otherwise the compositor must raise an implementation-defined protocol error. Creates a treeland_wine_window_state_v1 bound to the given xdg_toplevel. At most one state object may exist for each toplevel; requesting a second one is a toplevel_already_bound error. If the xdg_toplevel has been destroyed or has no configured role, the compositor must raise a defunct_toplevel error. Upon creation, the compositor immediately sends a state_changed event to report the current state of the toplevel. Observes and controls the lifecycle state for one xdg_toplevel surface. State flags are reported via the state_changed event. Each flag corresponds to a Windows window state that xdg-shell does not expose to clients. If the associated xdg_toplevel is destroyed, this object becomes inert. All subsequent requests are ignored and no further events are emitted. The client should destroy the inert object. Bitfield of window states that the compositor tracks for this toplevel. These supplement the states delivered by xdg_toplevel.configure. Keyboard focus (activated) is excluded because it is already delivered by xdg_toplevel; duplicating it here would create two conflicting sources of truth. Provides semantic context for an activate request so the compositor can apply appropriate focus-stealing prevention policy. Destroys the state object. This does not affect the associated xdg_toplevel. Requests that the compositor restore this toplevel from the minimized state. Standard xdg-shell provides xdg_toplevel.set_minimized but no way to reverse it. This request fills that gap. If the toplevel is not currently minimized, this request has no effect. If the compositor honors the request, it emits a state_changed event with the minimized flag cleared. This corresponds to the Wine/Windows ShowWindow(SW_RESTORE) call on a minimized window. Requests that the compositor give keyboard focus to this toplevel and raise it in the stacking order. serial is a client-assigned value that is echoed back in any activate_denied event for this request, allowing the client to correlate denials when multiple activations are in flight. The reason argument informs the compositor about the context of the activation. Compositors should generally honor user_request and restore activations, and may choose to deny or convert programmatic activations into attention requests based on focus-stealing prevention policy. If the compositor accepts the request, no activate_denied event is sent. Acceptance does not guarantee immediate keyboard focus: if another surface (e.g. a layer-shell surface with exclusive keyboard interactivity) currently holds focus, the compositor places this toplevel at the head of the focus fallback queue and activates it once the exclusive focus is released. The client will observe the eventual focus grant through the normal xdg_toplevel.configure activated state. If the compositor denies the request, it emits an activate_denied event carrying the same serial, and may set the attention flag via state_changed. Corresponds to the Wine/Windows SetForegroundWindow API. Under X11, Wine sends a _NET_ACTIVE_WINDOW client message with source indication; this request serves the same role under Wayland. Asks the compositor to signal that this toplevel needs user attention in the taskbar or dock. This must not steal keyboard focus. The compositor forwards this hint to the taskbar via the foreign toplevel manager protocol. Whether the taskbar honors count and timeout_ms is implementation-defined and not guaranteed by the compositor; clients must not rely on exact flash behavior. count specifies how many times to flash. 0 means flash indefinitely until the window is activated, corresponding to FLASHW_TIMER in the Windows FlashWindowEx API. timeout_ms specifies the desired interval between flashes in milliseconds. 0 requests the compositor or taskbar default rate. This value is forwarded as a hint only. Sending this request replaces any currently active attention hint. To stop flashing, use clear_attention. This request covers the taskbar/tray component (FLASHW_TRAY) of the Windows FlashWindowEx API. Title-bar caption flashing (FLASHW_CAPTION) is handled by Wine's client-side decoration layer and is outside the scope of this protocol. Under X11, Wine sets _NET_WM_STATE_DEMANDS_ATTENTION; this request serves the same role under Wayland. Cancels any active attention hint set via set_attention. If no hint is active, this request has no effect. The compositor emits a state_changed event with the attention flag cleared. Corresponds to FlashWindowEx with FLASHW_STOP. Emitted whenever the state flags of the toplevel change. This event is sent: - immediately after the treeland_wine_window_state_v1 is created, to report current state, - when the user or compositor minimizes or restores the window, - when an attention hint is set or cleared. The state argument is a bitfield of treeland_wine_window_state_v1.state values. Flags not present in the bitfield are considered unset. Emitted when the compositor denies an activate request. The serial matches the serial field of the activate request that was denied. The compositor may have set the attention flag via state_changed instead. The client must not retry the activation automatically.