@elb Just tried it out in Element... which rudely put the GIF behind a 'don't animate unless mousing over' widget. How will I arbitrarily waste other people's CPU cycles now?!?
@okennedy That's fine, Element is using 40% of your CPU because you didn't opt into replies, or whatever.
@elb indeed! Maybe switch to weechat with the python modules for slack and element, both of those have worked quite well for me. :)
@unrznbl I might be able to get away with that for slack, because I don't use it a lot, but every time I've tried a third-party Matrix app, I've been stymied by missing features or capabilities. (FluffyChat is the only reception, for Android.). I'll give it another try, though!
@elb yeah, to be fair I've only used weechat a bit with matrix :( I keep wanting to write my own clients anyhow, more like suckless ii would be nice :)
Electron makes it easy to access a large pool of developers and a rich ecosystem of libraries to add features. Adding features quickly usually also doesn't use the most performant implementation of those features.
I can understand if one doesn't want to use an Electron app, but it is clearly used for a reason. It makes development easier. Either accept less features or the Electron tax (that isn't actually usually the performance issue).
@bob Look. I agree that apps should be fast. I don't write my apps in Electron. I even wrote this recently: https://matrix.org/blog/2022/06/17/this-week-in-matrix-2022-06-17#nheko-website
But! If you complain that every other client lacks features, but the Electron based client does not, maybe acknowledge that Electron does have benefits to users, by giving them access to new features faster. If you don't want that, use a client that is faster, but has fewer features or if you value FOSS that much, contribute to clients so that they have features.
@bob yes. I worked on an electron app (not FOSS FWIW) top-to-bottom a few years ago. It all seemed great when I was just working on the app mostly and nothing else. After a while though the reality sets in.
I think UNIX is pretty easy for the user. More small tools written without frameworks please. :)
(Consider also that Element is buggy, confusing, plays poorly with the desktop environment, etc. -- and that that is also true of Slack et al. Its tooltips don't even pop over other windows!)
@elb @unrznbl There are lots of clients that support spaces and E2EE though. Some have a bit limited spaces support, but in my case that is mostly because I didn't feel like implementing the UI for that yet (the backend is all there). And just because you want those features, doesn't mean that someone else doesn't want threads, edits, group calls, widgets or whatever. People always have one feature that client X lacks. For me Element is lacking knocking and custom emoji, so I use another client.
@elb @unrznbl Arguably Element isn't even the client with the biggest spec coverage atm. And even if it does, spaces are mostly a UI feature. If Electron makes UIs easier, then it does help there. Same with calls. Electron of course already supports webrtc, since that is a browser technology for the most part. Widgets are just embedded websites. Which is why Element has an easier time shipping some stuff. (Well, and they have more developers.)
It would also be quite OK with me if it moved more slowly, and if they focused on the REALLY TERRIBLE AND UNUSABLE parts of the system, like session and key management -- but the same thing that makes people say "woo web dev!" makes them say "ok half broken is fine, let's do that." </cynic>
@elb gomuks is a good TUI Matrix client. I'm not sure about spaces (I only use it for IM), but it does support E2EE. When I want as little resources as possible used, but still get notified if someone messages me and want to be able to reply quickly, I usually use it.
Even for Element I see no point in running the Electron app, why not a Firefox window with Element web app? For me it consumes less than one percent of CPU when not focused and idle.
@elb are you suggesting that packing a browser and a compiler in a framework that needs the equivalent computing power of an earlier supercomputer to make a cursor blink is the wrong trade-off for having emojis in your text interface?
@elb are you using finch3? if so.. note that we've been doing a best effort to keep it compiling but haven't tested it much.. That said, i'm going to need some info here...
Also you can see how often I check mastodon 😂
@grimmy I am, but it's a pretty old build, because I couldn't easily compile the new stuff on Buster. I'm on Bullseye now, but haven't checked recently. It's on my TODO.
@elb ah yeah we've been targeting the next releases of every distro so you might be sol for the moment... according to repology bullseye-backports only has glib 2.66 and we require 2.70 now.. I can finish the flatpak i started but that's kind of orthogonal to our goals right now about getting the subproject builds working, but maybe that'll work for finch..
@elb that came out weird.. we're trying to get pidgin to gtk4 so we can then focus on getting the subprojects builds going so that mac, windows, flatpak, and app image builds just build all of the dependencies. So while doing that work for finch now is doable, it's orthogonal to getting the gtk4 port finished which has been a months long project.
"I appreciate SDF but it's a general-purpose server and the name doesn't make it obvious that it's about art." - Eugen Rochko