## Makepad modularization meeting notes Nov 7 2023

In general, Makepad platform components talk to platform-specific libraries, some of which Rust can talk to directly via regular C linking,
(sometimes it must be done on the UI thread, sometimes not)

**Web**:
needs JS files that can be hooked inot a root hub that knows about and can talk to a wasm blob, and Rust code needs to know about that and be able to receive data from the wasm blob
--> wasm sends a msg about a mouse mvmt event
--> Rust returns a message to update the cursor

**Java (Android)**
needs Activity with JNI that are tightly coupled to Rust files
--> functionality is already known, easy to reason about but hard to extend/modularize
--> much different module structure than JS, as it will use direct function calls (not messages)
--> some things need to run synchronously w.r.t. UI (within the context of a particular thread), others can run asynchronously
--> e.g., component for image picker needs to run 'synchronously' as a UI component, and it's connected to your activity/manifest since it needs perms to access photos on device

**Windows**
Makepad has a custom generated subset of the windows-rs crate in order to reduce the size and compile time. Subset only includes the features that Makepad needs.
--> One solution: when a module is important, we can add it directly into the Makepad-specific subset.
--> for macOS, it could be mostly the same. *-sys crates get auto-generated from C headers
--> Currently Makepad uses its own custom subsets of *-sys crate headers.

**Idea**
create an extension model that cargo makepad knows about, for build artifacts that should be packaged along with the application.
--> instead of resources, make a "platform" directory (with per-platform) where you can specify code and/or artifacts that should be packaged into the application.
--> challenge: how to define how those code blobs interact with the rest of the system, e.g., Android Java activity callbacks (onStart, onStop, onResume)
--> Currently, the source Java files are included directly in cargo makepad's platform-specific subdirs, and it uses those as a template for your application such that those java files can be renamed. This procedure needs to be customizable so that devs can add third-party custom Java files.
-- e.g., add a feature to access the camera roll (photos), plus add permissions to the manifest. Could allow the developer to provide an XML fragment (part of the manifest) that the build tool could integrate/combine into a single app-wide manifest file.

There are some related build crates, but nothing quite as flexible/powerful as cargo makepad. We basically just need the ability to expose hooks to inject pre- and post-build actions into the appropriate build phases of cargo.

Quake (atop nushell) supports or will support most of this.