stardustxr / core Goto Github PK

To recap: Items are a specific type of Node containing data and methods, with no inherent UI. Item UI handlers are clients that will register to handle the UI for that specific type of item globally, and have access to all the methods. Item acceptors can be created to temporarily capture those items with full access to all the nodes. Item UI handlers decide when to capture the items into the acceptors.

The Launcher Item type would be a unified representation of an app to launch.
Its data would contain FreeDesktop Application Desktop file's fields including:

• Name: human-readable name
• Exec: command to run to launch the app
• Categories: list of categories for app launchers to filter
• Icon: 2D (or potentially 3D) icon

Pros:

• Unified representation of a common concept meaning stability and reliability instead of the alternative, a rough spec based on pulse senders/receivers
• Lets people design universal UIs that can take in app launchers like grabbing an app from a list and dropping it on a dock
• Ensures consistent behavior for launching apps when they're outside the launcher

Cons:

• Hard to update, breaking changes affect everything
• Making non-global UIs for objects that represent apps to launch would require hacks with item acceptors, doable reliably but an extra layer of indirection
• More specified in core means more rigid structure

This is the first RFC for Stardust, feel free to comment if you don't understand the concepts or have suggestions for a different format.

This is a lot of just rearranging code.

The idea here is to take every single message that goes over IPC and force it to be a struct inside the schemas crate so we can see the protocol in 1 place, edit it in 1 place, and so on. To do this, I've created the unified_protocol branch that already has schemas arranged to do this.

What needs to be done is to get fusion and the server to use these crates, as well as take all of their internal schemas and put them inside the crate. There's a new Schema trait that everything serialized or deserialized must implement so we can be sure they're all inside the schemas crate. That way, you can just follow the errors to tell what needs to be converted next.

I recommend starting with the core crate, getting fusion and schemas fully sorted out. Then, the server will be a lot easier! Make sure all the method returns that the client gets do not borrow anything (e.g. /startup_settings/[instance]:generate_startup_token needs to return a struct with String in it, not &str).