Linux and Windows native apps

[jeremyckahn]

Linux and Windows native apps

[dillfrescott]

Oh. I don't think one is necessarily better than the other, but an .apk install feels more "official" to me I guess? I actually forgot about the ability to use it as an icon. oops! 😅

If you think its better just to keep it as a PWA I trust you ofc. But when I saw the official clients planned for Linux and Windows an .apk feels more native than a webapp to me.

[dillfrescott]

Adding Android .apk support is a distinct effort from Windows/Linux, so I'll break that out into a new issue.

I agree!

And yeah, having to maintain the app on something like the play store is too much of a hassle.

[jeremyckahn]

In the Linux native app, some way to share screen with desktop audio would be very nice, along with a separate volume bar ofc. Right now there is no way to screen share with desktop audio via the browser on Linux.

I think that via either web or native apps, the user would need to manually create an audio loopback device and select it from Chitchatter's UI. As far as I know there's no reasonable way to automate this on the user's behalf (certainly not via the web), so I don't know if such functionality could be delivered by Chitchatter.

[jeremyckahn]

tauri &/ wails pls, electron b slow

These seem really interesting. Thanks for sharing @africa552036012020255252355634346346346! Tauri seems like the more appealing option here. Is it meant to be a more performant alternative to Electron? I haven't used it before.

[dillfrescott]

This would be awesome! Possibly Android as well? It doesnt have to be in the store, just an .apk

I consider Android separate from Linux even though its technically a distro.

[jeremyckahn]

I'd be open to providing an .apk file! I don't know if I'd want to set Chitchatter up in the Google Play store. It costs money and there's administrative overhead I don't really want to deal with there.

I'm planning to use https://www.electron.build/ for the desktop native apps, and we'd need a separate build solution for Android. Perhaps https://github.com/GoogleChromeLabs/bubblewrap?

[dillfrescott]

Sounds good to me! .apk is more than enough!

[jeremyckahn]

@dillfrescott out of curiosity, why is having an .apk advantageous over an installed PWA? Chitchatter can be installed as a PWA to the Android/iOS home screens already, so it's not clear to me what additional value an .apk-based app would provide. I don't mind having the automation to provide the .apk as a build artifact, but the use case isn't clear to me.

[jeremyckahn]

That makes sense. The value in any Chitchatter native app seems more psychological than anything else, including Windows and Linux. I'm okay with providing them as options so long as it doesn't create too much maintenance burden (like MacOS does, which is why I'm not planning to support that platform).

Adding Android .apk support is a distinct effort from Windows/Linux, so I'll break that out into a new issue.

[dillfrescott]

In the Linux native app, some way to share screen with desktop audio would be very nice, along with a separate volume bar ofc. Right now there is no way to screen share with desktop audio via the browser on Linux.

[africa552036012020255252355634346346346]

This can be achieved with electron-builder

tauri &/ wails pls, electron b slow

[the-homeless-god]

@jeremyckahn
WDYT about just neutralinojs application? I can wrap it

[jeremyckahn]

WDYT about just neutralinojs application? I can wrap it

I'm not familiar with NeutralinoJS, so I don't have an opinion about it. That said, I welcome experimentation here. Regardless of the platform used, it's critical that the app wrapper supports automatic updating. Without that, users will have broken experiences as installed Chitchatter versions diverge. This is handled automatically for the web versions, but it's not something that necessarily comes for free with native app platforms.

[the-homeless-god]

WDYT about just neutralinojs application? I can wrap it

I'm not familiar with NeutralinoJS, so I don't have an opinion about it. That said, I welcome experimentation here. Regardless of the platform used, it's critical that the app wrapper supports automatic updating. Without that, users will have broken experiences as installed Chitchatter versions diverge. This is handled automatically for the web versions, but it's not something that necessarily comes for free with native app platforms.

Under update do you mean deployments to "GitHub Pages"?
We can do the same for artifacts per platforms to the Releases section of repository

[jeremyckahn]

Under update do you mean deployments to "GitHub Pages"?

Yep!

We can do the same for artifacts per platforms to the Releases section of repository

💯

The links I shared in the initial issue description are prior art for how this might work. Here’s what a release with web and native app build artifacts looks like: https://github.com/jeremyckahn/farmhand/releases/tag/1.18.10

[the-homeless-god]

@jeremyckahn

WDYT if I will provide an example with usage of neutralino to generate other platformed packages?

[jeremyckahn]

WDYT if I will provide an example with usage of neutralino to generate other platformed packages?

Let's give it a shot!

I think we're going to run into a blocking issue with this - Chitchatter does not have any sort of versioning system. That's intentional, as people should only ever be using the latest version for the sake of peer compatibility.

I'll need to figure out a solution for this before we can incorporate native builds distributed via GitHub Releases. I think I can reuse the solution from my other project Farmhand, but I'll need to think on it some more. I'll look into this once I wrap up my other in-flight tasks.

[the-homeless-god]

WDYT if I will provide an example with usage of neutralino to generate other platformed packages?

Let's give it a shot!

I think we're going to run into a blocking issue with this - Chitchatter does not have any sort of versioning system. That's intentional, as people should only ever be using the latest version for the sake of peer compatibility.

I'll need to figure out a solution for this before we can incorporate native builds distributed via GitHub Releases. I think I can reuse the solution from my other project Farmhand, but I'll need to think on it some more. I'll look into this once I wrap up my other in-flight tasks.

I can configure semantic-release tool first

https://github.com/semantic-release/semantic-release

PTAL this link.

It will provide for us an ability to release artificats with version based on version at package.json

[jeremyckahn]

@the-homeless-god Semantic Release looks like a great option for us. Let's use it!

Feel free to put together a PR that incorporates Semantic Release and I'll help you get it merged. 🙂