Feature Request: Consider a Native GTK or Qt Client

[SeaDve]

Using a native client would be great as it will use a lot less resources (RAM, CPU, etc.). Also, it will make it less alien in the chosen desktop environment.

[themighty1]

@SeaDve , yes that would save 100-200 MB of RAM.
Signal is Electron-based and that provides a lot of convenience for the developers even at the cost of extra RAM for the users.
That's just how development goes. You select the tools that are most convenient for the developers. And only after your project matures and you have enough resources, then you may consider doing optimizations.
It is too early for Signal dekstop to optimize - look at all those bugs and feature requests pouring in.

[SeaDve]

I understood, but still a good thing to consider in the future.

[adityar-r]

will it be possible to start a project, on the side for the Qt counterpart?

[themighty1]

@bw-space , certainly, Signal Desktop is open source, one can simply port it's code.

will it be possible to start a project, on the side for the Qt counterpart?

Try this. UWP based unofficial client.
https://github.com/signal-csharp/Signal-Windows

[SeaDve]

It seems like this is a duplicate of #2178

[EvanHahn-Signal]

We're working on a number of performance and UX improvements, including evaluating Catalyst on macOS and reworking a lot of our logic to improve performance. But because this would be a massive rewrite of Signal Desktop and would dramatically increase the amount of work required, we have no current plans to drop Electron.

I wish we could say "yes" to everything, but there are some feature requests we won’t be able to address, so I'm going to close. And don't think we've forgotten about performance issues—this is stuff we're actively working on.

[lpcvoid]

I would like to try to develop the client in gtk + js in the future

js is not a native language. Please don't. This is about native clients.

[vixalien]

js is not a native language. Please don't. This is about native clients.

I didn't believe it either but GJS adds little overhead to the performance of an app. It is wildly different from the DOM and Node JS though so it may be harder.

[brochard]

I'm overly optimistic but making a QT Kirigami / GTK Libhandy app so it could be used on Plasma Mobile / Phosh as a main SMS app would be amazing.
Signal devs most likely wouldn't spend their time doing it but with the help from KDE/Gnome community I don't think it's impossible.

(making the electron app convergent is also an option but it wouldn't be as nice and isn't likely getting SMS support)

[wyatt8740]

I'd like to just add that I have a couple computers that Node.JS/the V8 javascript engine simply will not build for, due to a lack of support for their CPU architectures in V8. I have a 32-bit PowerPC Linux desktop, for instance.

C, C++, Python (2 or 3), Go, Java (though very slow; pure C JIT only for now), Rust, Common Lisp, or basically any other platform that isn't javascript and tied to V8 would work. A webkit (safari; meaning "not-blink") based javascript version would also work, since Webkit's javascriptcore currently still works on PPC32.

Ironically, Javascript via Electron, which was probably chosen for portability, is inherently un-portable to any architecture that V8 doesn't have a code generator written to target. If Node/Electron used even a different javascript backend, this would not be an issue (although I would still prefer not having to use an instance of a web browser).

[adonig]

I wish there would be a feature-complete native GTK Signal client. The electron app behaves just terribly on Wayland with fractional scaling enabled. Even when you get the fonts to not be blurry, the UI is still a buggy mess and the CPU fan spins all the time so I tend to open it only when it's really necessary.

[vixalien]

There's a GTK Signal client, but it's currently WIP (in development, unstable, etc): https://gitlab.com/Schmiddiii/flare

[AManNeedsAMaid]

I wish there would be a feature-complete native GTK Signal client. The electron app behaves just terribly on Wayland with fractional scaling enabled. Even when you get the fonts to not be blurry, the UI is still a buggy mess and the CPU fan spins all the time so I tend to open it only when it's really necessary.

How do you get the fonts to not be blurry? I am using swaywm and the fonts and UI are slightly blurry, I haven't been able to find a way to fix this. I've had the same issue with a previously installed flatpak version and my current version from the OpenSuse Signal RPM repo.