Patchbay scuttle-shell

I'm working on cross platform installers which use scuttle-shell

This will help us move away from monolithic clients and towards flotillas of beautiful apps which do their one thing really well.

Please help test the installers

Get them here: github.com/ssbc/patchbay/releases/tag/v7.15.2-ss

I think the linux version is working, I'm moving onto other platforms now.

We particularly need testers who have not touched scuttle-shell at all (ironically, the people who've been experimenting with this already are probably the least helpful for testing, unless they have a "clean" side machine!)

awesome, thank you for such a prompt test @Mischa!
Yeah I saw some blank interface the first time too .. it's weird huh, not sure if there's a race condition or what, it's hard to reproduce.

To be 100% clear you downloaded the AppImage, and you are talking about making it executable like chmod +x styles.

writing this from patchbay scuttle-shell in windows! moving on to trying to make an installer now

Windows installers up

Only weird things I've seen are:

• when I hover over the hermes in the systray, he disappears (tho process seems to keep running fine)
• when I close patchbay, I can't see any process continuing to run in the background. (don't need this now, but needed in the future so that I can close patchbay but keep a standalone chess app open and it doesn't die)

cc @cryptix @SoapDog the windowsInstall branch of scuttle-shell seems to be behaving.

@zero @Avinash

Yeah, the Error { notFound: true, status: 404 } is bubbling up from the level-errors module, and I think it's caused by this.

@mix

Here's what happens when I try to start on Arch Linux:

$ ./patchbay-linux-7.15.2-scuttle-shell-x86_64.AppImage
STARTING electron
LOADING config
> scuttle-shell: starting
started sbot server v13.0.3
ssb-friends: stream legacy api used
/tmp/.mount_patchbDCQBag/systrayhelper: error while loading shared libraries: libdbusmenu-gtk3.so.4: cannot open shared object file: No such file or directory
scuttle-shell got exit: { code: 127, signal: null }
Error { notFound: true, status: 404 }

I was able to resolve the bug with pacman -S libdbusmenu-gtk3, so at least it's an obvious fix. I don't have a systray (GNOME Shell) but Patchbay seemed normal after clicking around a bit. I can test more extensively later.

when I close patchbay, I can't see any process continuing to run in the background.

Hmm.. We need to make a test for that in general. Currently the shell might be started as a child of electron in which case it will go down when any *bay exits, unless we disown it after starting.

On Linux there is the additional problem of the shell running outside of the AppImage. I’m not sure what happens when the image is released from the system.. I hope they just keep running but I’m not sure..

All that wanted to say that I think we should make the shell a separate tool that you need to install once you want to use more than one scuttlethingy.

that seems like a good idea @cryptixInTheCloud @cryptix, but also a little cumbersome.
I'f be keen for hermes to always be on.

Oh I just noticed running from the repo that the scuttle-shell menu might not be right. I see:

• @null (this seems wrong?)
• sbot version 13.0.3
• Quire

hey @صفر your report is appreciated AND it doesn't actually tell me enough to be useful.
As in what happened ... did the you see patchbay die... or was it a blank app, or did a bunch of flowers materialise?!

@christianbundy I figured out how to include .so files in the install, which seemed to work fine D:
I have no idea what including an .so from Debian in Arch might do, I'm a total beginner on this level

no that detail is good @صفر @صفر - knowing what you saw is really useful, telling me what did and did not happen (even if it sounds boring) is vital infomation.

I've seen something interesting in patchbay on mac where the interface does nothing for a full 90s, then works. quite different that my experience on linux thinkpad.

but also a little cumbersome.
I'f be keen for hermes to always be on.

@mix: Yes but I fear we have to make some medium term cut backs. when I looked into this last time, I got the impression that muxrpc can't change it's manifest at runtime ( %d5LMs6b... ). For plugins this means they have to be loaded during sbot server startup. The only real blocker for this I see currently is the module that patchwork loads out of it's own tree, not ouside of the user defined ones like .ssb/node_modules. Unless that is changed you always need to start patchwork first and everything else after.

Disowning the scuttle-shell process from electron must be done regardless. Butt I think the propper way forward would be to have real native packages brew install .. and better service integration (like systemd on linux) to have the shell spawned when you open your user session.

@null (this seems wrong?)

hmm.. yea - i tried to get the own name for the id by using sbot.about.get. The handling of a fresh keypair could be better. It also doesn't update later.

I'm currently contemplating to turn the forked-systray + systrayhelper (which currently relies on a weird qusi-json rpc) into a oop sbot plugin. this would allow us to use muxrpc and thus pull-streams and async calls on the js side.