diff --git a/rust/Cargo.lock b/rust/Cargo.lock
index b597838..34ad3cc 100644
--- a/rust/Cargo.lock
+++ b/rust/Cargo.lock
@@ -610,15 +610,13 @@ checksum = "c08c74e62047bb2de4ff487b251e4a92e24f48745648451635cec7d591162d9f"
name = "rust_lib_flight"
version = "0.1.0"
dependencies = [
- "bitflags",
"flutter_rust_bridge",
"futures",
"serde",
"serde_json",
"tokio",
- "wayland-backend",
"wayland-client",
- "wayland-scanner",
+ "wayland-protocols",
]
[[package]]
@@ -850,6 +848,18 @@ dependencies = [
"wayland-scanner",
]
+[[package]]
+name = "wayland-protocols"
+version = "0.32.12"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "563a85523cade2429938e790815fd7319062103b9f4a2dc806e9b53b95982d8f"
+dependencies = [
+ "bitflags",
+ "wayland-backend",
+ "wayland-client",
+ "wayland-scanner",
+]
+
[[package]]
name = "wayland-scanner"
version = "0.31.10"
diff --git a/rust/Cargo.toml b/rust/Cargo.toml
index 55ec7a9..f10a9c9 100644
--- a/rust/Cargo.toml
+++ b/rust/Cargo.toml
@@ -7,7 +7,6 @@ edition = "2021"
crate-type = ["cdylib", "staticlib"]
[dependencies]
-wayland-scanner = "0.31"
flutter_rust_bridge = "=2.11.1"
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }
futures = "0.3"
@@ -15,5 +14,4 @@ wayland-client = "0.31"
serde = { version = "1", features = ["derive"] }
serde_json = "1"
-wayland-backend = "0.3.15"
-bitflags = "2.11.1"
\ No newline at end of file
+wayland-protocols = { version = "0.32.12", features = ["client", "staging"] }
diff --git a/rust/protocols/ext-workspace-v1.xml b/rust/protocols/ext-workspace-v1.xml
deleted file mode 100644
index 7b58d45..0000000
--- a/rust/protocols/ext-workspace-v1.xml
+++ /dev/null
@@ -1,422 +0,0 @@
-
-
-
- Copyright © 2019 Christopher Billington
- Copyright © 2020 Ilia Bozhinov
- Copyright © 2022 Victoria Brekenfeld
-
- Permission to use, copy, modify, distribute, and sell this
- software and its documentation for any purpose is hereby granted
- without fee, provided that the above copyright notice appear in
- all copies and that both that copyright notice and this permission
- notice appear in supporting documentation, and that the name of
- the copyright holders not be used in advertising or publicity
- pertaining to distribution of the software without specific,
- written prior permission. The copyright holders make no
- representations about the suitability of this software for any
- purpose. It is provided "as is" without express or implied
- warranty.
-
- THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
- SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
- FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
- SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
- AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
- ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
- THIS SOFTWARE.
-
-
-
-
- Workspaces, also called virtual desktops, are groups of surfaces. A
- compositor with a concept of workspaces may only show some such groups of
- surfaces (those of 'active' workspaces) at a time. 'Activating' a
- workspace is a request for the compositor to display that workspace's
- surfaces as normal, whereas the compositor may hide or otherwise
- de-emphasise surfaces that are associated only with 'inactive' workspaces.
- Workspaces are grouped by which sets of outputs they correspond to, and
- may contain surfaces only from those outputs. In this way, it is possible
- for each output to have its own set of workspaces, or for all outputs (or
- any other arbitrary grouping) to share workspaces. Compositors may
- optionally conceptually arrange each group of workspaces in an
- N-dimensional grid.
-
- The purpose of this protocol is to enable the creation of taskbars and
- docks by providing them with a list of workspaces and their properties,
- and allowing them to activate and deactivate workspaces.
-
- After a client binds the ext_workspace_manager_v1, each workspace will be
- sent via the workspace event.
-
-
-
-
- This event is emitted whenever a new workspace group has been created.
-
- All initial details of the workspace group (outputs) will be
- sent immediately after this event via the corresponding events in
- ext_workspace_group_handle_v1 and ext_workspace_handle_v1.
-
-
-
-
-
-
- This event is emitted whenever a new workspace has been created.
-
- All initial details of the workspace (name, coordinates, state) will
- be sent immediately after this event via the corresponding events in
- ext_workspace_handle_v1.
-
- Workspaces start off unassigned to any workspace group.
-
-
-
-
-
-
- The client must send this request after it has finished sending other
- requests. The compositor must process a series of requests preceding a
- commit request atomically.
-
- This allows changes to the workspace properties to be seen as atomic,
- even if they happen via multiple events, and even if they involve
- multiple ext_workspace_handle_v1 objects, for example, deactivating one
- workspace and activating another.
-
-
-
-
-
- This event is sent after all changes in all workspaces and workspace groups have been
- sent.
-
- This allows changes to one or more ext_workspace_group_handle_v1
- properties and ext_workspace_handle_v1 properties
- to be seen as atomic, even if they happen via multiple events.
- In particular, an output moving from one workspace group to
- another sends an output_enter event and an output_leave event to the two
- ext_workspace_group_handle_v1 objects in question. The compositor sends
- the done event only after updating the output information in both
- workspace groups.
-
-
-
-
-
- This event indicates that the compositor is done sending events to the
- ext_workspace_manager_v1. The server will destroy the object
- immediately after sending this request.
-
-
-
-
-
- Indicates the client no longer wishes to receive events for new
- workspace groups. However the compositor may emit further workspace
- events, until the finished event is emitted. The compositor is expected
- to send the finished event eventually once the stop request has been processed.
-
- The client must not send any requests after this one, doing so will raise a wl_display
- invalid_object error.
-
-
-
-
-
-
-
- A ext_workspace_group_handle_v1 object represents a workspace group
- that is assigned a set of outputs and contains a number of workspaces.
-
- The set of outputs assigned to the workspace group is conveyed to the client via
- output_enter and output_leave events, and its workspaces are conveyed with
- workspace events.
-
- For example, a compositor which has a set of workspaces for each output may
- advertise a workspace group (and its workspaces) per output, whereas a compositor
- where a workspace spans all outputs may advertise a single workspace group for all
- outputs.
-
-
-
-
-
-
-
-
- This event advertises the capabilities supported by the compositor. If
- a capability isn't supported, clients should hide or disable the UI
- elements that expose this functionality. For instance, if the
- compositor doesn't advertise support for creating workspaces, a button
- triggering the create_workspace request should not be displayed.
-
- The compositor will ignore requests it doesn't support. For instance,
- a compositor which doesn't advertise support for creating workspaces will ignore
- create_workspace requests.
-
- Compositors must send this event once after creation of an
- ext_workspace_group_handle_v1. When the capabilities change, compositors
- must send this event again.
-
-
-
-
-
-
- This event is emitted whenever an output is assigned to the workspace
- group or a new `wl_output` object is bound by the client, which was already
- assigned to this workspace_group.
-
-
-
-
-
-
- This event is emitted whenever an output is removed from the workspace
- group.
-
-
-
-
-
-
- This event is emitted whenever a workspace is assigned to this group.
- A workspace may only ever be assigned to a single group at a single point
- in time, but can be re-assigned during its lifetime.
-
-
-
-
-
-
- This event is emitted whenever a workspace is removed from this group.
-
-
-
-
-
-
- This event is send when the group associated with the ext_workspace_group_handle_v1
- has been removed. After sending this request the compositor will immediately consider
- the object inert. Any requests will be ignored except the destroy request.
- It is guaranteed there won't be any more events referencing this
- ext_workspace_group_handle_v1.
-
- The compositor must remove all workspaces belonging to a workspace group
- via a workspace_leave event before removing the workspace group.
-
-
-
-
-
- Request that the compositor create a new workspace with the given name
- and assign it to this group.
-
- There is no guarantee that the compositor will create a new workspace,
- or that the created workspace will have the provided name.
-
-
-
-
-
-
- Destroys the ext_workspace_group_handle_v1 object.
-
- This request should be send either when the client does not want to
- use the workspace group object any more or after the removed event to finalize
- the destruction of the object.
-
-
-
-
-
-
- A ext_workspace_handle_v1 object represents a workspace that handles a
- group of surfaces.
-
- Each workspace has:
- - a name, conveyed to the client with the name event
- - potentially an id conveyed with the id event
- - a list of states, conveyed to the client with the state event
- - and optionally a set of coordinates, conveyed to the client with the
- coordinates event
-
- The client may request that the compositor activate or deactivate the workspace.
-
- Each workspace can belong to only a single workspace group.
- Depending on the compositor policy, there might be workspaces with
- the same name in different workspace groups, but these workspaces are still
- separate (e.g. one of them might be active while the other is not).
-
-
-
-
- If this event is emitted, it will be send immediately after the
- ext_workspace_handle_v1 is created or when an id is assigned to
- a workspace (at most once during its lifetime).
-
- An id will never change during the lifetime of the `ext_workspace_handle_v1`
- and is guaranteed to be unique during its lifetime.
-
- Ids are not human-readable and shouldn't be displayed, use `name` for that purpose.
-
- Compositors are expected to only send ids for workspaces likely stable across multiple
- sessions and can be used by clients to store preferences for workspaces. Workspaces without
- ids should be considered temporary and any data associated with them should be deleted once
- the respective object is lost.
-
-
-
-
-
-
- This event is emitted immediately after the ext_workspace_handle_v1 is
- created and whenever the name of the workspace changes.
-
- A name is meant to be human-readable and can be displayed to a user.
- Unlike the id it is neither stable nor unique.
-
-
-
-
-
-
- This event is used to organize workspaces into an N-dimensional grid
- within a workspace group, and if supported, is emitted immediately after
- the ext_workspace_handle_v1 is created and whenever the coordinates of
- the workspace change. Compositors may not send this event if they do not
- conceptually arrange workspaces in this way. If compositors simply
- number workspaces, without any geometric interpretation, they may send
- 1D coordinates, which clients should not interpret as implying any
- geometry. Sending an empty array means that the compositor no longer
- orders the workspace geometrically.
-
- Coordinates have an arbitrary number of dimensions N with an uint32
- position along each dimension. By convention if N > 1, the first
- dimension is X, the second Y, the third Z, and so on. The compositor may
- chose to utilize these events for a more novel workspace layout
- convention, however. No guarantee is made about the grid being filled or
- bounded; there may be a workspace at coordinate 1 and another at
- coordinate 1000 and none in between. Within a workspace group, however,
- workspaces must have unique coordinates of equal dimensionality.
-
-
-
-
-
-
- The different states that a workspace can have.
-
-
-
-
-
-
- The workspace is not visible in its workspace group, and clients
- attempting to visualize the compositor workspace state should not
- display such workspaces.
-
-
-
-
-
-
- This event is emitted immediately after the ext_workspace_handle_v1 is
- created and each time the workspace state changes, either because of a
- compositor action or because of a request in this protocol.
-
- Missing states convey the opposite meaning, e.g. an unset active bit
- means the workspace is currently inactive.
-
-
-
-
-
-
-
-
-
-
-
-
-
- This event advertises the capabilities supported by the compositor. If
- a capability isn't supported, clients should hide or disable the UI
- elements that expose this functionality. For instance, if the
- compositor doesn't advertise support for removing workspaces, a button
- triggering the remove request should not be displayed.
-
- The compositor will ignore requests it doesn't support. For instance,
- a compositor which doesn't advertise support for remove will ignore
- remove requests.
-
- Compositors must send this event once after creation of an
- ext_workspace_handle_v1 . When the capabilities change, compositors
- must send this event again.
-
-
-
-
-
-
- This event is send when the workspace associated with the ext_workspace_handle_v1
- has been removed. After sending this request, the compositor will immediately consider
- the object inert. Any requests will be ignored except the destroy request.
-
- It is guaranteed there won't be any more events referencing this
- ext_workspace_handle_v1.
-
- The compositor must only remove a workspaces not currently belonging to any
- workspace_group.
-
-
-
-
-
- Destroys the ext_workspace_handle_v1 object.
-
- This request should be made either when the client does not want to
- use the workspace object any more or after the remove event to finalize
- the destruction of the object.
-
-
-
-
-
- Request that this workspace be activated.
-
- There is no guarantee the workspace will be actually activated, and
- behaviour may be compositor-dependent. For example, activating a
- workspace may or may not deactivate all other workspaces in the same
- group.
-
-
-
-
-
- Request that this workspace be deactivated.
-
- There is no guarantee the workspace will be actually deactivated.
-
-
-
-
-
- Requests that this workspace is assigned to the given workspace group.
-
- There is no guarantee the workspace will be assigned.
-
-
-
-
-
-
- Request that this workspace be removed.
-
- There is no guarantee the workspace will be actually removed.
-
-
-
-
diff --git a/rust/src/internal/wayland.rs b/rust/src/internal/wayland.rs
index 53fb7f2..cee6d5e 100644
--- a/rust/src/internal/wayland.rs
+++ b/rust/src/internal/wayland.rs
@@ -1,10 +1,11 @@
use crate::{frb_generated::StreamSink, workspace_api::Workspace};
-
use std::collections::HashMap;
-use wayland_client::{self, Connection, Dispatch, QueueHandle, event_created_child, protocol::{__interfaces::{WL_OUTPUT_INTERFACE, wl_output_interface}, wl_output, wl_registry}};
-wayland_scanner::generate_interfaces!("protocols/ext-workspace-v1.xml");
-wayland_scanner::generate_client_code!("protocols/ext-workspace-v1.xml");
+use wayland_protocols::ext::workspace::v1::client::{
+ ext_workspace_manager_v1,
+ ext_workspace_handle_v1,
+};
+use wayland_client::{self, Connection, Dispatch, QueueHandle, event_created_child, protocol::wl_registry};
pub struct AppState {
pub workspaces: HashMap,
@@ -12,9 +13,9 @@ pub struct AppState {
}
impl AppState {
- fn emit(&self) {
- let _ = self.sink.add(self.workspaces.values().cloned().collect());
- }
+ // fn emit(&self) {
+ // let _ = self.sink.add(self.workspaces.values().cloned().collect());
+ // }
}
impl Dispatch for AppState {
@@ -78,42 +79,6 @@ impl Dispatch for AppState {
_qh: &QueueHandle,
) {
println!("workspace event: {:?}", event);
- match event {
- ext_workspace_handle_v1::Event::Id { id } => {
- // let id: u32 = id.parse().unwrap_or(0);
-
- // state.workspaces.insert(
- // id,
- // Workspace { activated: false }
- // );
-
- // state.emit();
- }
-
- ext_workspace_handle_v1::Event::State { state: flags } => {
- // let active = matches!(
- // flags,
- // wayland_client::WEnum::Value(
- // ext_workspace_handle_v1::State::Active
- // )
- // );
-
- // // IMPORTANT: we don't know which workspace this refers to reliably
- // // so we treat it as a refresh signal OR update heuristically
-
- // for ws in state.workspaces.values_mut() {
- // ws.activated = active;
- // }
-
- // state.emit();
- }
-
- ext_workspace_handle_v1::Event::Removed => {
- // state.workspaces.clear();
- // state.emit();
- }
-
- _ => {}
- }
+
}
}
\ No newline at end of file