I found some that could work for Haiku. I don’t have any knowledge in QT nor have the developer source files installed.
Ncurses:
I would really love to see slack in Haiku
1 Like
Just beware scudcloud seems to have discussed switching to electron.
At least TeamWords is as easy as qmake; make. This produces a binary which I didn’t test because I don’t have an account.
1 Like
Sounds nice. Is it easy to setup your development environment for QT?
I don’t have any particular development environment. I just have qt5_devel and qtwebkit_devel packages installed.
TeamWords compiled fine. #general works, but no other channels 
1 Like
Is #general an unauthenticated channel? perhaps there is some option or library not getting build with it…
Probably check the build log to see that during the configuration phase.
Good day,
@konrad, actually I asked in the VSCode place to port it to Haiku, then they sent me to ask the same for Electron, which needs Node.js, they said no interest, no demand, so no one cared. Checking the Electron website we can see the apps that are “based” on Electron, among them, Slack and VSCode. Having Electron would theoretically allow us to have Code, Slack, Skype… But that is a huge task.
Different approach is what you list there in your post, Slack clients. That might be the way to go.
Regards,
RR
We need NodeJS, Chromium even before we start to port Electron.
NodeJS is a huge task (not compiling right now).
Chromium is probable a even bigger task, but if that happens, Haiku may have the possibility of using it embedded and/or run webassembly apps.
And that would be a pro for quick apps done on linux/win/mac, run here.
Electron applications are actively discouraged on Haikuports as they are bloated garbage. One Electron app uses more ram than Haiku itself… each Electron app is like a separate browser it’s just crazy.
I think the official policy at the moment is if you wanted to work on it and support it ok they’d let it in, but you’d probably get little to no help from anyone on the haikuports team.
So, probably the best course of action is to continue trying to get QT based clients working.
3 Likes
Looks like TeamWords is unmaintained which leaves scudcloud and Slacken.
Your desktop todo app is probably written in Electron and thus has userland driver for Xbox 360 controller in it, can render 3d graphics and play audio and take photos with your web camera.
I was just reading a rant and that was in there. Thought it was funny.
It came from here, if anyone is interested in a guy going off on how inefficient programs have become.
2 Likes
As much as i can agree to you and @MrEntropy quote, having support for other “multiplatform” tools should be done… eventually, for a desktop usage OS.
Not so for Slack/Discord/etc which are consumer-only type of apps, but for others like Visual Studio Code, which work to create things (and apps… maybe).
I think the sentiment of most people with regard to any Electron app is at best Meh. I mean have you tried to Type in VSCode… that thing is a laggy mess.
Electron is not a multiplatform app framework, it is an embedded platform in itself, and I think that is the rub.
Yeah, i work as a developer and tested it (+uninstall). Fortunately i just have to work with the real VS (and that’s getting much heavier now).
Also, i know it’s not a mp framework. I mean most “modern” companies devs just throw electron based app whenever electron is supported and forget other native options (if any).
On a lower level, we need updated and working ports of libuv and V8. While the latter may be easier to port, libuv requires platform-specific patches.
Specifically, it requires some sort of event queueing system call interface similar to kqueue (Darwin/BSD), epoll (Linux). Haiku has wait_for_objects() which does something similar, but I think that these patches done by hamishm[1] are a better alternative for having a viable event queuing system.
This will be helpful for getting a tokio [2] and mio [3] port mostly working in Haiku.
[1] https://github.com/hamishm/haiku/commits/eventqueue
[2] https://github.com/tokio-rs/tokio
[3] https://github.com/carllerche/mio
I’m working on a custom non-public compilation of NodeJs to test how far I can go with it, and can asure that libuv and v8, in that order, are a pain in the ass to solve compilations errors (just to see if i can get an executable to test).
I think that as many libs may detect the compilation as linux (the configure for node does and propagates its options), a epoll compatibility layer would be a way to solve libuv problems. As in keep the headers, implement the backend in what goes better.
wait_for_objects needs a few API tweaks, but IMO a full-blown kqueue is not needed, as that branch has.
It is.
The point of kqueue is that you 1) give a list of objects to the kernel, and 2) get notified everytime something happens
wait_for_objects is: 1) give a list of objects to the kernel, 2) get notified the first time something happens, 3) give that list to the kernel again, etc. It is similar in that aspect to select or poll. This means you spend most of the time sending that list of objects to the kernel again and again.
It is possible to kind of emulate kqueue behavior with it, but the performance will not be nearly as good. And we’re talking about porting heaviweight Electron (what a name choice…) here, so we should not start with a big performance penalty like that.