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.
wait_for_objects, then sending back the list of objects sounds like it could be racy also. Like if something happens while you are sending the list back…
In that case wait_for_objects will immediately return, telling you that an event is already pending on one of the objects. this works the same as select/poll for file descriptors, and there are no problems with those in that regard.
Yeah that makes sense… so it’s just that it’s slower due to being less efficient.
Slack seems to be a browser issue, same error in otter/qupzilla. Webpositive loads general but side panel is not rendererd at all.
I guess Netsurf has the same problems.
Note there is a preliminary recipe I’m working on getting into haiku ports for slack++
I may have time to finish cleaning it up this evening.
What is slack++? I only found a chrome extension.
— maybe this in c++?
or c++ in slack?
It’s the command line client you originally posted…
1 Like
Except that doesn’t work, it is indeed a bug in wait for objects though. I haven’t gotten around to investigating yet.
For UV epoll code you would need that to work, but also have a fd that can be feed as input for the os close functions like a normal file descriptor, and/or autocloses on exit. As having a parent fd that polls some children fd.
Would it be possible for you to test the slack ncurses client? I could send you the packages.
I’m not 100% sure on how to set up the API token to get it to work so am wondering if you know how that works…