Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tauri #753

Merged
merged 64 commits into from
Jun 13, 2024
Merged

Tauri #753

merged 64 commits into from
Jun 13, 2024

Conversation

martpie
Copy link
Owner

@martpie martpie commented Mar 17, 2024

yarn
cargo test --manifest-path src-tauri/Cargo.toml
yarn tauri dev

Let me keep track of what's working and what's yet to be fixed using the tauri branch. Non-exhaustive. Hard bockers are marked with 🚫.

Screenshots

Screenshot 2024-03-05 223247

Screenshot 2024-03-12 at 16 31 17

martpie and others added 9 commits March 16, 2024 22:46
This is a half-working copy of Museeks ported to Tauri 2.0.

This is highly experimental, many things are broken. Lots of non-idiomatic Rust (and React actually).

```bash
yarn
cargo test --manifest-path src-tauri/Cargo.toml
yarn tauri dev
```
* Use app_local_data_dir() for database
* Move get_app_storage_dir() into config
I tried to upgrade `ts-rs` to v8, but the new export mechanism is extremely confusing, and `TS_RS_EXPORT_DIR` does not seem to be respected (types should be outputted in the TS codebase, not the rust codebase).
@Serial-ATA
Copy link

Hey @uklotzde & @martpie , I fixed that bug in WebKit and enabled MediaSession by default. The player should work fine on Linux now whenever my commits make it into a release (I'm still not entirely sure about how their release schedule works).

@uklotzde
Copy link
Contributor

Generating TypeScript bindings is a burden.

Those definitions are probably better defined once as part of the application API in museeks. Every integration then needs to implement the bridging code manually instead of bringing their own definitions.

@martpie
Copy link
Owner Author

martpie commented Mar 29, 2024

Generating TypeScript bindings is a burden.

I would argue this is a setup issue and not a philosophical issue.

Types generated from the backend is a very very useful feature, I just need to automate it, without slowing the devX too much.

Edit: Typically, by running cargo test in the beforeDevCommand. But that would run cargo twice (test + build), but maybe things are cached.

@uklotzde
Copy link
Contributor

uklotzde commented Mar 29, 2024

Edit: Typically, by running cargo test in the beforeDevCommand. But that would run cargo twice (test + build), but maybe things are cached.

Only a single TypeScript API is needed and those definitions should be driven by the requirements and use cases of the app and rendering. If you want pluggable backends then backends need to adapt these definitions instead of bringing their own.

I already have JSON representations and JSON schema mapping and started to utilize ts-rs. But this turns out as complicated and wouldn't really help if you need a second layer of type adapters for app integration anyway. Mapping the idiomatic, native Rust types directly instead of opinionated, JSON-serializable types makes more sense here.

@martpie
Copy link
Owner Author

martpie commented Mar 29, 2024

I think I don't fully understand what you mean.

Can you detail how using JSON schemas would be an improvement and how the dev workflow would look like?

* Prevent re-importing tracks already in the DB
* Misc cleaning (comments, todos, etc)
* Fix 'build' CI, passing TypeScript
* Attempt to actually build the binaries by GitHub actions
* Keep generated types in Git

- This provides a working copy of the repo without having to generate the types manually.
- Types should be manually updated when changing the definition of one of its corresponding Rust struct.
- The CI will catch if any artifact is not correctly generated.

* Update .prettierignore + re-run prettier

* Clean generated types, replace action + create script for gen
Breaking change for the DB. This will place the DB content in the "Museeks" folder instead of "io.museeks.app".

This is cleaner, more aligned with what other apps are doing, and will prevent macOS from thinking it's an app file (when it's a folder)
- Don't listen and emit the same event from the back-end AND front-end, each process should have different event names
- The code removed was used in Electron but not anymore (it was useful for dock actions or tray, but they're gone)
@martpie
Copy link
Owner Author

martpie commented Jun 13, 2024

Let's merge this. It's not ready, but it will show the project is alive :)

@martpie martpie merged commit d95ad85 into master Jun 13, 2024
6 checks passed
@martpie martpie deleted the tauri branch June 13, 2024 18:34
@martpie martpie mentioned this pull request Jul 15, 2024
80 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants