-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signal Desktop Without Electron #2178
Comments
No alternatives so far but I did see something about a third party native Windows 10 app for Signal. |
The right place for this kind of discussion is the forums: https://community.signalusers.org/ But I'll allow it as long as this conversation stays constructive. As long as everyone sticks entirely to potential solutions, I won't lock this conversation. |
@scottnonnenberg-signal Is there a specific reason why Signal may not be available on anything other than Electron at this time? |
@MBLHarrison The primary reason is time and money. Creating native programs that work for Windows, Mac and Linux takes some serious time and effort. |
Thumbs down. Electron apps sidestep many complex issues involved with native apps while hardware resources continue to improve. And sidestepping those complex issues also allows developers to spend more time thinking about performance (in addition to features!). Also, the platform also has lots of tools to profile performance. Some Electron apps will run when idle and have memory leaks - Slack is probably one of them (I typically run it in the browser instead). But that doesn't mean that's necessarily the case. |
Yeah like I want to use 2 gigs of ram and destroy my ssd with neverending read-write cycles (Signal on Linux reads and writes 10 times more data than Slack, which I use more often). I'm forced to use Signal, Atom, Slack and other Electron/webkit-based apps in the same time and it makes my dual xeon workstation suffer. Electron is bad, most of us know that. Using it to develop messenger is even worse. |
Regarding the RAM usage you might want to consider the results of the hardware survey https://hardware.metrics.mozilla.com . |
@Dyras I understand that. Perhaps I should have been more in depth with my question. With the current dev team is it only feasible to really use Electron. |
Maybe writing a client in Qt/QML could be feasible? QML uses javascript so there might be a way to reuse libtextsecure. Also, Qt runs on all platforms supported by the electron client. |
Disclaimer: I backed the Librem 5 project, but I am in no way related to Purism staff I would like to know the position of the Signal team about third-party clients which explicitly state they are not supported by Signal but still bind to Signal's servers. I would like to wrap the libsignal-service-java into a daemon and expose the messages/messaging capabilities through D-Bus services. The main reason behind that is I want to port it to the coming Librem 5 phone, and I want to write as little extra code as possible in order to have both:
I cannot realisticaly expect Signal team to support such a project and plan to do it myself. I want to stress out within the application that neither the Signal team, foundation, nor community are to be reached for support. As I don't want to backstab anyone, I would love to have the advice, opinion or even agreement of the Signal core team. Edit: friendly ping @scottnonnenberg-signal, you're my best bet on this thread :) |
@thibaultamartin Send me a direct message; this issue isn't the right place for the discussion. |
@thibaultamartin signal-cli has dbus support, I suggest you ask for help in the community forum or their issue tracker. |
@Trolldemorted I actually plan to use that project! But let's not discuss it any further here as @scottnonnenberg-signal asked. Thanks for the suggestion 😄 |
Would something like packaging signal-desktop in flatpak or snap be a better solution? |
@211217613 It's actually available as both. https://flathub.org/apps/details/org.signal.Signal |
Packaging in flatpak/Snap is not relevant to the issue, i dont have any issues with installing, the issue is about electron. |
It is an really bad idea to use Electron. Electron is completely 100% inaccessible and unusable with the Orca screen reader on Linux. None of the Electron applications work with the Orca screen reader. All of the Electron applications are completely unusable if you are visually impaired or blind like I am. Orca screen reader speaks absoletely nothing when you try to use Electron based applications. Electron is based on Chromium technology. Chromium web browser is also completely inaccessible and unusable with the Orca screen reader. During the last 10 years people have requested several times that Chromium developers should start to support the Orca screen reader. But nothing has happenened. People have requested the same from Electron developers but nothing has happened. Chromium and Electron are still completely inaccessible and unusable. Blind users like me must use computer using screen reader which speaks the content on scree. blind and other visually impaired people can not use any Electron applications because Electron does not work with the Orca screen reader. It also looks like situation will not change, looks like Chromium and Electron developers have no plans to supoort the Orca screen reader. There is now applications like Skype which is made using Electron. Because of that Skype on Linuxx is completely inaccessible and unusable if you are visually impaired. So visually impaired users can not use e.g Skype or e.g Signal on Linux. that is simply discriminitaing visually impaired users. So no, use of Electron is not ok. |
@miksuh I sympathise with your problem. I think the best course of action is for the community to rally behind adding screen-reader functionality to electron, well ideally chromium. on electron is about the ability to inject ChromeVox into Electron apps. ChromeVox being a screen-reader that could be shipped along with Electron apps, or at the very least be injected. |
@miksuh Thanks for sharing your personal account of being affected by the lack of accessibility features in Electron / Chromium. We are very sorry for the challenges you’ve encountered with Signal Desktop due to Electron. Given our limited resources, we are at this point committed to doing cross-platform development using Electron but welcome and support any accessibility improvements in the core Electron / Chromium project and will try to leverage them to the best of our abilities. Thanks to everyone for providing their perspective and we will now lock this issue as we have received enough information. |
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. |
Are there alternatives to Signal-Desktop that don't use electron?
Here are some current issues with electron.
Repo Packages (8) electron-1.8.4-1 http-parser-2.8.0-1 minizip-1:1.2.11-2 nodejs-9.9.0-1 npm-5.7.1-1 re2-20180301-1 semver-5.5.0-1 yarn-1.5.1-1
167.55 MiB
https://josephg.com/blog/electron-is-flash-for-the-desktop/
https://www.reddit.com/r/linux/comments/64s1qg/electron_is_flash_for_the_desktop/
https://www.reddit.com/r/linux/comments/81wemi/lets_discuss_electron/
The text was updated successfully, but these errors were encountered: