BOINC
develop new GUI using Electron
Electron (https://electronjs.org/) is a possible framework for developing a new GUI. It's cross-platform, uses HTML for layout and CSS for styling. It seems to be widely used and well-supported.
If anyone is interested in working on this, please let me know.
BTW, the BOINC client exposes GUI RPCs via HTTP; I've verified that these work with the HTTP and XML features built into Javascript.
This is similar to issues #2112, #2113 and PR #2275. Even though the BOINC client exposes GUI RPCs via HTTP, it is not possible to use this directly from a browser. As far as I understand Electron uses Chromium so will have the same issue. To make this work the client needs to provide a Web socket. There are some security concerns related to this that have been discussed in PR #2275. I believe that it is possible to do this but have not had time to make any progress but could do so if we consider this a direction we would like to go.
I'm working on a complete rewrite of the Boinc Manager. It uses a shared code (.NET Standard) and some platform-specific code. It will work on:
- iOS, Android (Xamarin)
- Windows (.NET Core WPF)
- Web (ASP.NET Core).
Electron.NET could be a good candidate for Linux and Mac.
Electron might not but to make it communicate with the BOINC client you need to add a WebSocket. I remember us discussing this during the hackathon at the workshop in Paris. As soon as you do this you open the client to JS drive by attacks. Hence we have to be quite sure regarding the security considerations of this approach. It is one of the reasons why PR #2275 was closed rather than merged.
I have an Electron app that communicates with the BOINC client over TCP, just like the WxWidgets GUI does. Take my word for it.
That's interesting. I wonder how it works. Do you have any sample code to try?
Electron creates a stand alone app. The chromium inside electron is a browser just for rendering html/css and running javascript. It doesn't has the "same origin policy" and other security feature which a normal browser has. I wrote already electron applications which communicate via http to different server or which run soap operations and also parses xml.
If BOINC Manager uses Electron, it'll become too bloated and, moreover, it'll be harder to make packages for Linux distros (*sad gentoo user sounds*)
The current GUI, based on WxWidgets, is about as bloated as you can get, in terms of source code which is what matters. Electron could reduce this by a factor of 10.
If BOINC Manager uses Electron, it'll become too bloated and, moreover, it'll be harder to make packages for Linux distros (sad gentoo user sounds)
yes thats my thought too! but on the other hand i know not to much about the current old gui BM has.
to be honest im using most of the time the BoincsTask v1.78 app on windows. it does so much compared to BM.
Electron is a bad idea. It's bloated as others have mentioned, and it's also extremely resource hungry and will eat into the compute power that could have been used for actual BOINC tasks. On something like a phone, Raspberry Pi or older computer set aside for BOINC computation, this can be significant. Even on a high end computer it's undesirable.
Worse, Electron relies on Chromium which Google controls, and if I recall correctly has been shown to have privacy issues (like phoning home to Google) even though it's not full Google Chrome. I implore you to use something else, like GTK, Qt, one of the Java/Kotlin GUI libraries.
The current GUI, based on WxWidgets, is about as bloated as you can get, in terms of source code which is what matters. Electron could reduce this by a factor of 10.
At the cost of significantly higher resource usage on the user's computer and possible privacy issues with the embedded Chromium instance.
Well... I already have GTK and Qt installed on my Gentoo Linux system, and I prefer not installing other packages, especially if they require long build times.
@fturco, GTK isn't truly cross-platform so it isn't an option. Also there are more important tasks than reimplementing GUI.
https://github.com/BOINC/boinc/issues/3185#issuecomment-636077288
Yeah, @CyberTailor, GTK4 wouldn't be a good choice. It's as close to CSD-only as you can get with a GUI toolkit, and doesn't support theming whatsoever (which is dreadful for accessibility).
https://github.com/BOINC/boinc/issues/3185#issuecomment-614295276
@davidpanderson, is that due to WxWidgets? I imagine not, so would it not be easier to merely remake the WxWidgets app?
To my knowledge, if you're trying to make a cross-platform, performant GUI, you want Qt6 QtWidgets (maybe QML is quick too, but IDK) or WxWidgets (my LINX 1010's EFI GUI is written in it).
@RokeJulianLockhart, with Electron you can make much nicer GUI in a significantly easier way. Also, this will give us a possibility to introduce WebGUI that was also requested by users. So no, we don't want to rewrite GUI neither with wxWidgets nor with Qt.
https://github.com/BOINC/boinc/issues/3185#issuecomment-2531450500
@AenBleidd, good to hear!
I'm fairly impartial to each option, but I'm surprised that everyone here offers Electron as the sole method by which they can implement a web technology-based GUI. Does it offer something that, for example, CEF (think Steam) or QtWebEngine (RStudio) do not?
@AenBleidd, good to hear!
I'm fairly impartial to each option, but I'm surprised that everyone here offers Electron as the sole method by which they can implement a web technology-based GUI. Does it offer something that, for example, CEF (think Steam) or
QtWebEngine(RStudio) do not?
Tauri is "Electron but better". It uses OS's native web renderer instead of making each application carry its own copy of Chromium.
Though either Tauri or Electron would make it basically impossible for many Linux distributions to make own packages of BOINC manager, and they'll have no other option than using upstream-provided prebuilt packages.
Though either Tauri or Electron would make it basically impossible for many Linux distributions to make own packages of BOINC manager, and they'll have no other option than using upstream-provided prebuilt packages.
@CyberTailor, why?
Does it offer something that, for example, CEF (think Steam) or QtWebEngine (RStudio) do not?
You can make a research and provide us with a comparison why any of your options better than ours. At the moment we created this ticket and basically came to this idea, Electron was (and still is I think) modern and popular way of creating nice looking applications (e.g. VSCode and many others). So for us this is still the best option.
You can make a research and provide us with a comparison why any of your options better than ours.
@AenBleidd, I didn't think they were, until I saw @CyberTailor's comment: ^1
Tauri is "Electron but better". It uses OS's native web renderer instead of making each application carry its own copy of Chromium.
That's a significant advantage. The embedded chromium in Electron applications can quite easily become out-of-date if the packager doesn't keep atop their update regimen, because unlike on AOSP and i(Pad)OS, there is no WebView component to keep it updated.
It's also a lot smaller, and more efficient.
Additionally, https://github.com/electron/electron/issues/41551#issue-2175565420 remains open, which means that Electron applications must be invoked via XWayland on Linux-based OSes, which introduces another layer of instability (and slowness, very slightly).
https://github.com/BOINC/boinc/issues/3185#issuecomment-2531574752
@CyberTailor, it wouldn't make packaging as difficult as you state. You've mentioned at https://github.com/BOINC/boinc/issues/3185#issuecomment-614254696 that you utilize Gentoo, so you should expect to spend your life compiling dependencies!
Multiple Electron-based applications are packaged for Fedora 41. It's of no consequence, @AenBleidd.
Additionally, https://github.com/electron/electron/issues/41551#issue-2175565420 remains open, which means that Electron applications must be invoked via XWayland on Linux-based OSes, which introduces another layer of instability (and slowness, very slightly).
This is not something we are working on at the moment. So there is a big possibility that when we will actually start developing it, this might be already solved or we can even consider using completely different framework. As you can see, this ticket was open more than 5 years ago, and we haven't started working on it yet.
Also, this is a very low priority ticket, since we have currently a GUI that is stable and functioning. Yes, we want to get rid of it in favor of something more popular and easy to develop, but such kind of work will require a lot of resources and this is something we don't have at the moment.
So this also mean that right now this discussion will not move this ticket in any direction.
Multiple Electron-based applications are packaged for Fedora 41
as Fedora package maintainer and after having had a talk with some other fellow Fedora devs, I can tell you that Fedora is NOT shipping any Electron based application on its repository because nobody has done the work to make a packaged electron runtime.
Hereunder I paste some messages (with the permission of the author) extracted from a talk with from Neal Gompa (@conan-kudo), one of the most important Fedora developers, who kindly wrote the following statements regarding this boinc-client GUI discussion
-------
if cross-platform is what they want, they should consider Qt even the Android GUI could be written in Qt if they use the Kirigami stuff. There's a Matrix room aimed to help people learn about developing applications using KDE technologies if you want to forward them to it: https://matrix.to/#/#kde-streamlined-app-dev:kde.org Here's a website about KDE Frameworks too: https://develop.kde.org/products/frameworks/
Qt + KDE Frameworks gives you a leg up on a lot of common patterns and interfaces. It simplifies development and gives you clean, ABI stable extensions on top of Qt to support application development.
Usage of KDE frameworks does not imply that it's a KDE application, and indeed you can have whatever UX or platform preferences you want even with it.
Things like config files (KConfig), push notifications (KUnifiedPush), status icons/appindicators (KStatusNotifierItem), clean window layouts and extra widgets (Kirigami and KWidgetsAddons), network detection (NetworkManagerQt), idle detection (KIdleTime), gettext-style translations (K18n), and others, it becomes much easier to implement a consistent and useful user experience across Windows, Mac, Linux/Unix, and Android.
The frameworks and platform support for each framework module is listed here: https://api.kde.org/frameworks/index.html The benefit here over wxWidgets is that Qt is a complete platform abstraction layer, so the GUI codebase can be much simpler than it is now and there's a lot of people developing with Qt all over, with professional documentation, tutorials, and examples to work from
Qt has the ability to interface with web-based protocols too, so client-server interactions should be pretty straightforward. I've seen applications use RESTful HTTP, XML-RPC, JSON-RPC, and gRPC fairly easily with the stuff provided by Qt itself
I can tell you that Fedora is NOT shipping any Electron based application on its repository because nobody has done the work to make a packaged electron runtime.
@Germano0, I was thinking of RPMFusion. ^1 Apologies.
If cross-platform is what they want, they should consider Qt even the Android GUI could be written in Qt if they use the Kirigami stuff.
I'll affirm this. However, keep invent.kde.org/frameworks/kirigami/-/issues/81 in mind.
I have worked a lot with Qt, and will not consider doing that anymore. My personal opinion: there is no good framework for GUI development available for c++.
Anyway, we don't need to rely on any OS, and can include Electron engine inside the application installation package (like this is done by vscode for example).
And one more note: this ticket is not supposed to be started soon (for sure not in 2025). And before we start working on the new GUI, there could happen a lot, including appearing new technologies and frameworks.
I suggest to stop this discussion now, because at this moment it's completely useless.
https://github.com/BOINC/boinc/issues/3185#issuecomment-2536365697
@AenBleidd, I understand you being dead-set on using a web technology GUI framework, considering the significant reduction in effort to make a cross-platform application that way.
However, why are you also apparently dead-set on Electron? Another user previously mentioned Tauri, which appeared to be an improvement (in all respects that I've researched).
Anyway, we don't need to rely on any OS, and can include Electron engine inside the application installation package (like this is done by vscode for example).
Yeah, I think that's what all applications currently packaged as RPMs do, whether built on RPMFusion (like Discord) or not (like VS Code, Stable and Insiders).
I suggest to stop this discussion now, because at this moment it's completely useless.
...How?
However, why are you also apparently dead-set on Electron?
I'm not dead-set. I'm open for suggestions. I just see no reason to discuss it now since we don't plan doing any development in the near future.