Tauri Friction Log - HackMD

[found this issue](https://github.com/tauri-apps/tauri/issues/2278)). I decided to keep the tray icon even if user runs in foreground mode. - Otherwise it works great. ## What took work - **Auto launch**: - There was no option to auto-launch on startup in Tauri, which I think is fine. I used the … 't supported. However, I again forked Tauri and added `set_activation_policy` to the window object (again, `AppHandle` would've been nicer), so I could use it at runtime. It works great! Happy to send PR. - Summary: It feels as if the concept of "application" and its lifecycle doesn 't map well to the MacOS model, instead you have to fumble with `Window` objects - which didn't work too well. ## What was confusing *NOTE: Most things here are architectural, and many are probably not worth the churn of breaking changes. Also, I am new to the code base so some of these opinions may be misinformed.* … (internal to Tauri): - The dependency tree across the different internal crates in Tauri, Tao, Wry and Winit was quite susbstantial - I needed to fork several projects to make relatively small changes. I also needed to create a couple of mirror types and proxy functions (boilerplate, duplication). - Btw, not saying this is easy to simplify. Dependencies are really difficult and I understand Tauri do not control all of them. - **Builder/App/Window/Runtime separation of concerns**: - I can't quite put my finger on it, but it felt like the responsibilities and relationships between each of these entities, as well as the proxy- and handler types, were not entirely clear. - A couple examples: - (See above): MacOs puts a strong emphasis on the application, yet there is not much you can do with the