Skip to content
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

Closed
vitamins opened this issue Mar 24, 2018 · 20 comments
Closed

Signal Desktop Without Electron #2178

vitamins opened this issue Mar 24, 2018 · 20 comments

Comments

@vitamins
Copy link

Are there alternatives to Signal-Desktop that don't use electron?
Here are some current issues with electron.

  • UI inconsistency, eg. bad font rendering that does not comply with OS settings
  • sluggish performance
  • high CPU usage, even when idle
  • high memory usage
  • requires 167MB of dependencies to be installed
    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
  • increased power usage, users have noted that electron apps cause a noticeable increase in battery discharge speed
  • accesibility, no screen reader support, or font rendering

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/

@Dyras
Copy link

Dyras commented Mar 25, 2018

No alternatives so far but I did see something about a third party native Windows 10 app for Signal.

@scottnonnenberg-signal
Copy link
Contributor

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.

@MBLHarrison
Copy link

@scottnonnenberg-signal Is there a specific reason why Signal may not be available on anything other than Electron at this time?

@Dyras
Copy link

Dyras commented Mar 27, 2018

@MBLHarrison The primary reason is time and money. Creating native programs that work for Windows, Mac and Linux takes some serious time and effort.

@jcrben
Copy link

jcrben commented Mar 30, 2018

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.

@gasi-signal gasi-signal changed the title Signal-Desktop but without electron Signal Desktop Without Electron Apr 2, 2018
@ghost
Copy link

ghost commented Apr 3, 2018

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.

@vitamins
Copy link
Author

vitamins commented Apr 3, 2018

Regarding the RAM usage you might want to consider the results of the hardware survey https://hardware.metrics.mozilla.com .
Around 35% of users have 3GB of RAM or less.

@MBLHarrison
Copy link

@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.
I know there are alternatives like github.com/servo/servo which may be suited but may not have the technical overlap with the current team.

@kaimast
Copy link

kaimast commented Apr 16, 2018

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.

@thibaultamartin
Copy link

thibaultamartin commented Apr 20, 2018

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:

  • The expected client behaviour against Signal's servers. I want to keep the lowest footprint as possible on Signal's server
  • The best integration as possible within the mobile OS Purism develops

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 :)

@scottnonnenberg-signal
Copy link
Contributor

@thibaultamartin Send me a direct message; this issue isn't the right place for the discussion.

@Trolldemorted
Copy link
Contributor

@thibaultamartin signal-cli has dbus support, I suggest you ask for help in the community forum or their issue tracker.

@thibaultamartin
Copy link

@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 😄

@211217613
Copy link

Would something like packaging signal-desktop in flatpak or snap be a better solution?

@Dyras
Copy link

Dyras commented Apr 23, 2018

@vitamins
Copy link
Author

Packaging in flatpak/Snap is not relevant to the issue, i dont have any issues with installing, the issue is about electron.

@miksuh
Copy link

miksuh commented Apr 27, 2018

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.

@MBLHarrison
Copy link

@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.
electron/electron#11544
Is an issue on the electron repo that addresses this. If we can apply pressure, then hopefully one day greater accessibility features may be present for all electron apps.

@gasi-signal
Copy link
Contributor

gasi-signal commented Apr 27, 2018

@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.

@signalapp signalapp locked and limited conversation to collaborators Apr 27, 2018
@EvanHahn-Signal
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests