conveyor VS wee-slack

Interesting timing! We're just in the middle of adding Python support to Hydraulic Conveyor, which is a similar tool [1]. There's a github issue [2] and mailing list that'll get notified when it's done. Disclosure: it's commercial but free for open source projects.

There are many of these open source packagers and they all share very similar problems:

1. They don't let you do software updates, even though software updates are practically mandatory for any real project. Electron is a stand-out here because it does address this, but their update engines are unmaintained for years and have some major unfixed problems (causes a lot of issues with Windows networks, for example).

2. Even in the very rare cases that they do, they don't let you force updates on launch even though many apps need something like this to keep up with protocol changes. It's one of the reasons people like web apps.

3. They don't help you with signing, usually being just thin wrappers around the native tooling. For example they don't simplify key management, they don't support cloud signing (essential since May because Microsoft now insist on HSMs for all keys, not just EV keys), they don't do notarization, they don't generate CSRs for you.

4. They require the use of CI to cross-build even when apps are written in portable frameworks that don't require compilation. This is because they are just thin wrappers around the native tooling.

5. They're invariably language specific even though there's no good reason to be because 80% of the work is the same regardless of what language or framework you use.

It's possible to bite the bullet, chew glass for a while and solve all these problems, which is what we did for Electron/JVM/Flutter/native apps. You can reimplement all the native tooling so users can cross-build (i.e. make Mac packages from Linux/Windows, Windows packages from Mac/Linux etc), which enables releasing from developer laptops or cheap Linux CI workers. You can support software update by integrating Sparkle on macOS, apt on Debian/Ubuntu and by using MSIX on Windows (and by then working around all the bugs in Windows to make it work well). You can generate download pages that work out the user's OS and gives them the right download, and instructions for how to install self-signed apps if the developer isn't code signing with a recognized certificate. You can abstract platform neutral things and expose platform specific things. Then you can write a parallel incremental build system so doing all the work is as fast as possible, and write lots of code to detect all the myriad mistakes people make and give good error messages or auto-fix them. Then you can make it support GitHub Releases. Then you can document it all.

But that big pile of glass isn't particularly tasty, which is why open source projects don't do it and we ask commercial users to pay for it.

Briefcase looks nice but it also seems to have all the problems listed above. I think once we add Python support Conveyor will be quite useful for the Python community, especially if we can find a workaround for pip not support cross-building of venvs. It would be great if you could just whip up a quick Python script, run one command and your installed clients start automatically updating, your download page updates, and the whole thing is no harder than releasing a static markdown-rendered website.

[1] https://hydraulic.dev/

[2] https://github.com/hydraulic-software/conveyor/issues/73

Haha, it's amusing that the history essays are one of the things you remember :)

Yes you can compile Scala and ScalaFX apps down to native binaries this way. Look at Gluon Substrate:

https://github.com/gluonhq/substrate

One of our customers is experimenting with shipping such apps with Conveyor. There's a discussion ongoing here:

https://github.com/hydraulic-software/conveyor/discussions/6...

We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way.

If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:

https://hydraulic.dev/blog/13-deploying-apps-with-jcef.html

I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.

I replaced the Slack client with wee-slack [https://github.com/wee-slack/wee-slack]. It brings a much more "zen" experience to using Slack and better compliments my keyboard-centric desktop/workflow (e.g. clear all unread channel notifications? keybind! Jump between all the high priority/@mentioned notifications? keybind!) It also helps if you're expected to be available via Slack, since it can keep you showing "green" while you've actually been ignoring it.

Fwiw, last time I looked, wee-slack was a decent improvement for slack text chat. These days maybe a matrix bridge?

https://github.com/wee-slack/wee-slack

> - My company uses Slack's enterprise auth, and all the CLI slack clients I could find haven't been updated in years and no longer work.

https://github.com/wee-slack/wee-slack is decent.

> - The web is using more javascript than in the past.

cli browsers are probably the only truly unrealistic thing. An idea that I've been kicking around for a while is to build a simple CLI "browser" that uses PhantomJS or similar under the hood to request, load, and render the page into an image, convert the image to sixel (https://en.wikipedia.org/wiki/Sixel) and display it that way (or use any of the various terminal emulator-specific features (KiTTY has https://sw.kovidgoyal.net/kitty/graphics-protocol/ for example)). Probably pretty clunky, but it's doable if you're in the mood to write something purely for fun.

> - Mutt doesn't handle multiple email accounts natively for work/personal. The solutions are hacks at best. Email servers are starting to use more complete auth mechanisms that don't work well with mutt.

I don't think they're hacks. You can define exactly how you want it to work. That's a feature, not a bug. Sure, it takes a little bit of work to set up but you can use https://github.com/cweagans/dotfiles/tree/master/.config/mut... as a starting point if you'd like.

It has been unable to log in for the last year: https://github.com/wee-slack/wee-slack/issues/844

When the IRC gateway stopped working, I found https://github.com/wee-slack/wee-slack worked pretty well. But I switched employers months ago and no longer have to use Slack, which is even better! (So, I don't know how well it works today.)

The weechat plugin unfortunately cannot coexist with wee-slack (https://github.com/wee-slack/wee-slack/issues/812, https://github.com/poljar/weechat-matrix/issues/248), so if one wants to participate in the Haskell Foundation Slack, or any other Slack (e.g. for work), then Matrix is off limits. Yeah, it's just a bug that will eventually get fixed, but it does make things unnecessarily complicated. :-/

Not really Vim but there is a plugin for WeeChat: https://github.com/wee-slack/wee-slack

NB. On integrating slack & other webby things. Terminal applications might be a big help here (the Windows terminal now has excellent compatibility if you’re using Windows). For instance, there’s a slack plugin for weechat (a terminal IRC / chat client) which by all accounts works pretty well. Or there’s this client that runs directly in a terminal.

Wee-Slack is a WeeChat plugin that is based on python WebSockets and delivers most of the basic functionality of the Slack client. To use this, you need to receive a Slack API token. One way is - after installing - to run on WeeChat: /slack register This command prints a link you should open in your browser to authorize WeeChat with Slack. Once you’ve accomplished this, you should run: