Closed georgeowell closed 3 years ago
If one of us has the energy, it would be nice to make a little graphical launcher:
https://docs.nodegui.org/ is a lightweight alternative to Electron
Yup, I had a PR open for adding Electron #42 but it didn't get any attention so I assumed others didn't dig it. The only really big concern I have is that we don't have an auto-updater, and most of the butts I know irl don't update their Patchwork unless I beg them to.
Evil idea: if we build an Electron installer, make it stop working after 90 days so that people are absolutely forced to update. :smiling_imp:
Yup, I had a PR open for adding Electron #42 but it didn't get any attention so I assumed others didn't dig it. The only really big concern I have is that we don't have an auto-updater, and most of the butts I know irl don't update their Patchwork unless I beg them to.
Evil idea: if we build an Electron installer, make it stop working after 90 days so that people are absolutely forced to update. smiling_imp
Signal messenger actually does this lol.
I'm very much tending away from Electron. Maybe nodegui is the answer as @cinnamon-bun said?
Electron has consistently been a pain in my ass, and I hate working with it, but it's the only solution I've found that lets us compile native modules and pack them into an ASAR archive without constant trouble. It's also how Patchwork and Patchbay work, and so we already have all of the configs written and battle-tested in Patchwork. I've banged my head against pkg and nexe and a few other "node compiler" apps for dozens of hours and not made any progress.
If someone would like to use nodegui (packer) I'd be supportive, but personally I don't think it's something I can spend any more sanity trying to explore. :dizzy_face:
No problem. I don't really have any knowledge in this area so happy to defer to those that do.
I'm just wondering whether we should package something up on the next "stable" release. I think there's probably a silent majority of people who don't want to wrestle with npm but want to try Oasis but could be tempted into contributing if they like the concept.
Could we use an additional label to prioritise the important issues e.g. https://github.com/fraction/oasis/issues/47 https://github.com/fraction/oasis/issues/205 and https://github.com/fraction/oasis/issues/208 before an initial packaged release. I feel like Patchwork Parity has become a slightly more ambitious list than we actually need.
Then perhaps we could recruit people from the community to work together on each issue. I won't call it a "sprint" but maybe more an amble towards the specific goal of a packaged release with a minimum set of features without goalposts that keep moving.
Then we list Oasis on the Scuttlebutt website or anywhere else there are lists of SSB clients.
Rômulo Alves has got Oasis working on Android! They posted about it on SSB.
pkg install nodejs
pkg install libsodium
I just had a really silly idea: what if we just distribute a .zip
file with:
node
and npm
binaries for a given platformoasis
, that runs npm start || npm install && npm start
Bonus points for pre-installing node_modules
so we don't have to make the user npm install
, but cross-platform building isn't charming or suave. Here are some examples I just made:
These were build with the code in #251.
I think if you unzip the directory then you should be able to double-click the oasis
file and it'll open a terminal that runs the installer. On macOS you will get security warnings because we haven't paid Apple for the privilege of distributing this application. If it opens a text editor, maybe right-click and try to open with the terminal? Sorry, I only have a Linux machine which makes it hard to test macOS/Windows.
On my machine, double-clicking a shell script did nothing, so I had to tell my computer to prompt me to run it with:
gsettings set org.gnome.nautilus.preferences executable-text-activation ask
Anyway -- is this a dead end, or something worth exploring?
(Just updated my above comment with new binaries -- the old ones weren't working correctly.)
I think it is worth exploring. But what happens when there's a build error? A non-technical person is just stuck at that point.
I agree that it's best to do the least building on their machine, and since we have prebuilds for our native modules we shouldn't have to deal with that, but whenever we ship binaries to someone's machines we have a risk that they won't work.
Ideally we can build node_modules
for each platform/architecture, so that we don't need to ship npm
or have them run it locally, but I'm not really sure how to do that.
Can we close this now?
We have two ways of packaging now:
I'd like to have #251 merged or have the Oasis-Desktop more usable before closing this, if possible. I don't think I'd be comfortable recommending either option to non-programmer friends yet.
Yup! And Oasis-Desktop works too, which is much easier to use than the binary thing I worked on. Now all we need is some install instructions in the readme pointing to https://github.com/fraction/oasis-desktop/releases/latest
Perhaps, one day we can have a simple website that helps you download in a visually nicer way than Github.
I think this is ready to close now that oasis-desktop is a thing that works. :fireworks:
Once everything on the Roadmap is done, should we perhaps package up a stable release? If we could do a cross platform release like Patchwork, that would be amazing.
I've been using Oasis as my day to day SSB client and I've had few issues. I think we need to attract more users and therefore more developers for the low hanging fruit.
@christianbundy I think you identified some issues with packaging before but I can't find what you said. Perhaps it was on SSB.
All I'm gonna say, is if we have to go electron... it's a price we have to pay :weary: :cry:
Maybe if we improved some of the documentation and linked to some good sources for getting setup with node on different operating systems, anyone who is vaguely techy-y can use that.