I was talking abou a native one, I mean gamewise we can use that.
1 Like
It’s not exactly from me (If you mean me by “you”), dignifiedquire and @karissa already played with the idea, @karissa even started a small prototype https://github.com/karissa/deltar.
You want to make a webview based java app or a “native” java app?
You mean our current deltachat desktop project?
Thats written with electron because it’s convenient cross-platform UI to have a webapp as a desktop app, but the actual webapp has not too many dependency to electron itself, so you would likely able to replace the electron ipc with the api you have in java and reuse the webapp in src/renderer/. Then re-implement the backend from src/main in java. No need to start from scratch.
No this topic is unrelated to this. But you remind me here of the idea to have deltachat as standalone webapp or as browser extension - only problem with that is that we can’t use the core in the web yet, because raw tcp sockets aren’t a thing in most browsers, but you need them for communication with the email server (IMAP and SMTP).
You wrote that chromium can potentially be a backdoor for google, so I mentioned that I guess nodejs could also contain google binary blobs from V8.
1 Like
I first wanted to make an app based on a JavaFX web view. I tried that out with another, small web app which was built with Node.js as static HTML with client-side Javascript. Even this simple app had issues in the web view, so I started to favour a “native” JavaFX app.
I was speaking about Electron in general in the context of the other web view options being alpha (rust-webview) or needing more work to use all functionalities of the contained web app (JavaFX webview).
Sounds good, I first thought it’d be complicated to separate out the Google stuff. If I could replace the backend and make the web app work in a regular browser, that’d already be a great and maybe sufficient step forward.
I see, that’s good background information I didn’t have before, thanks.
Good catch, I didn’t think about that. One more a reason to inform the users about this risk or move away from Electron and Node.js.
If you are going to implement that or have plans about that, I want to discuss it. Especially the background engine to render pages in the webview (bot or default), QtWebkit and QtWebEngine.
I prefer the idea from adb, using PyWebview
The-Compiler wants to start a PyQt based desktop client. “Native” not just embedding a webapp frontend like electron. I meant that we could use the qt webview for ‘delta(web)Apps’ like games, but thats rather far in the future anyway, because now we have the priority to make deltachat stable (especially the rust core), before that it makes not much sense to build in too many new features. 
In this context it makes not much sense to use an extra library like pywebview only for the webview for deltachat webapps I guess.
Also the Deltachat Webapps depend on Chat resources to save/sync/share their state/data.
Chat resources themselves are still in the planning state, @hpk and @r10s have already a good idea how that feature could look.
Until then we’ll see what we can hack out of html(zip) files and mailto xD
I think @anon93826752 is talking more about web engines used in Delta in general (used for DC clients), including the current Electron one, not only of webview used for bots/games, and when I suggested pywebview, I was not talking about using it for web-apps only, but for the GUI of a DC client
2 Likes
Thx, it was just that.
I received the hint that this crate might be useful for you if you want to write a native client in Rust. It should also work on Librem systems.
Maybe that’s another option to consider.
I too would prefer a native JavaFX App.
In the early times of Android I’ve learned, that Android is a Java platform, so I’m wondering, why it could be difficult to have a Java desktop app.
hi @CoSoCo, first of all: welcome aboard!
yes, android is java, but apart from that, there are no similarities between android and other typical java-desktop-toolkits as java-fx.
so you probably could not share a single line of code between android and java-fx - esp. as delta chat has a core that is already shared between the platforms (the core is written in rust).
Hi,
why is DeltaChat core coded with RUST?
If I understand right, RUST is specialized for real time processes. It has the speed advantage of C/C++ combined with automatic object destruction, but without the need of an interrupting garbage collector.
But DeltaChat is not much more than a text editor with “bubble view” and network transmission. I see no timing critical needs.
So I can imagine, using Android’s Java engine would result in better portability to e.g. Linux, less dependencies and therefore a much smaller package footprint.
Bundling a whole android with deltachat makes no sense, the resulting package would be waaaaay bigger than the flatpack dependencies. If you want to use the android version on your desktop gnu/linux you can try https://anbox.io/.
The biggest reason that we migrated the deltachat from C to Rust is the simpler build process.
Before we couldn’t get the core to build successfully on windows, now with rust it builds fine.
There are more perks to rust over C that we enjoy:
- The rust compiler -> gives useful hints when there is an error in our code
- You don’t need to manually care about freeing stuff.
- No data-races which can lead to undefined behaviour and security vulnerabilities
The core is in written in rust https://github.com/deltachat/deltachat-core-rust and has also a C interface
At the moment all bindings use that C interface afaik.
We have 2 standalone bindings:
The bindings for java and swift are part of the mobile clients, so they are found in the respective repos.
The core is basically the whole deltachat logic (sending & recieving emails and so on), when you develop a new client you just need to program the UserInterface and hook it up to the core.
1 Like
Is there any news about this since 2019 ?
I would really like to be able to use a trully native package on debian, or at least a more lightweight version …
(Some rambling about how I really really like the idea of delta chat but I can't use it with electron because bloated things are a pain in my computer's resources)
When I heard of delta chat I was very exited about the idea of using the already existing email in a secure way !!!
It seemed very smart to build upon something that everyone already have !
I have had a lot of discussion with friends that don’t want to create yet an other account somewhere because I am the only people they know that won’t use hotmail, google, skype, zoom, facebook, instagram, whatsapp, etc… and I was ready to tell them “Hey ! I found the solution : it is free/libre and the evil corp that owns your phone and computer won’t be able to spy on me even if you don’t really care”
But then … I realized it’s based on electron. And that was the end for me.
I do not consider my computer particularly low end, it does have 2GB of ram and a 2 core CPU, most of the time it has a better response time that many computer running windows with sometimes more than 3x its specs. But that is mostly because I am careful of not bloating it with “native” software that weight >70mb without their deps, and will overload my cpu if I run firefox or libreoffice on the side… just to send and receive text messages
And if there is a kind of app that is often run beside other thing it is messaging apps…
I also do understand the need of some kind of universal multi-platforms solution,… but as I mentioned in my rambling it is not really universal if you need the latest computer on the market to make it work 
Anyway I am reviving this post is because it looks like a few alternatives to Electron have emerged since then, especially https://tauri.studio which is written in rust and is said to offer most advantages of electron without all the inconveniences and https://neutralino.js.org/ witch seem to be very close to electron but also relying on webview.
I have seen other messages about running delta chat as a web extension, I am not fond of the idea but at least it does stay in the spirit of using what is already there (the email account, the browser)
I also find @adbenitez’s idea of a pidgin plugin to be in this spirit and much more convenient than a browser plugin.
Having looked into matrix.org lately, I was impressed about the number of different existing clients and bridges, written in all kind of languages for all kind of platforms, there is even some text-based ui offering all the features of the fancy mobile apps. So… I wonder :
Does this mean that we can we excpect to see various clients in multiple langages emerge like for matrix.org ?
I myself lack the skills to be able work on any of the above, I guess I am way better at complaining than I am at doing the work, but I would gladly test any lightweight debian-compatible solution
There is a Qt-based client called KDeltaChat written by @link2xt and there is a terminal UI one written by @adbenitez. Both are far from feature parity with the official clients though. If you don’t want to compile anything when installing them, you can use Nix. Read through DeltaChat running on mobian (PineTab, PinePhone).
2 Likes
That’s great !! Thanks !
I started with curseddelta because it can be installed with pip and I already know how to do that 
And I must says that I found it particularly user friendly for a terminal based interface ! I like that it is very easy to see if the message was sent and if it was encrypted or not.
I’ve had a bit of trouble installing it because current version is not yet up to date with the latest deltachat on pip (1.58), but reverting it to the previous version fixed it. And there is already a pull request in progress for the update
I haven’t looked into KDeltaChat yet but I definitely will soon
I released a new version on PyPI just now with the new deltachat core, for now contact requests are accepted with the first message you send, there is no fancy buttons to accept/block, but well auto-accepting and notifications for contact requests are features for some people 
2 Likes
we actually plan to move the desktop away from electron to tauri, though I don’t expect that to be done soon. kdeltachat is native and if you want to test something that is web-based, but on tauri you can try GitHub - deltachat/dc40: Experimental deltachat client, though its only experimental at this stage.
5 Likes
Great news ! I will give it a shot as soon a possible !
… if I manage better than I did when I wanted to try kdeltachat.
Compiling it didn’t work – I will put some details below --, it’s probably possible to fix but it may or may not involve compiling the qt5 libraries or messing with OpenGL drivers, … and I shouldn’t do too much experiments on a computer from my work (the only one with enough disk space)
Anyhow, I went back to deltachat-cursed, reinstalled it,… and had an error and to set change self.focus_position = -1 to 0 at line 23 in chatlist_widget.py. But no dependency problems :yay: thank you @adbenitez
It was a surprise to see that it automagically fetched the previous messages stored on the mail server, even though I had deleted my previous installation and config
Since I don’t know how it is supposed to work otherwise, I’ll say “Cool feature !” and will go along with the idea that if I send a message, it probably mean that I accept the contact
About features, may I suggest a simple /help command to see all registered commands ?
I poked around in the sqlite db, to see if some non-features can be used by editing the config directly :
I was looking to set up an email alias so I edited addr and configured_addr in the config table, that seem to be enough, I think mail_user and send_user are only used as credentials against the imap/smtp server, right ?
I also wanted to see if/how bots are working so I installed simplebot-facts and simplebot-wikiquotes, but that didn’t seem to work out of the box… I’ll look more later.
Some reports of my failed attempt at compiling Kdeltachat; in case it is of some use
The computer was 64 bit running ubuntu 20.04 with Gnome desktop
I first tried installing using kdesrc-build with the instructions on the repository README
But I it failed because the apt Qt5 version is too old, and I didn’t want to compile a newer one
Updating sysadmin-repo-metadata (to branch master)
Building extra-cmake-modules from kf5-build-support (1/2)
Updating extra-cmake-modules (to branch master)
No changes to extra-cmake-modules source, proceeding to build.
Running cmake targeting Unix Makefiles...
Compiling... succeeded (after 0 seconds)
Installing.. succeeded (after 0 seconds)
Building kirigami from frameworks (2/2)
No source update, but the last configure failed
Updating kirigami (to branch master)
Source update complete for kirigami: no files affected
Preparing build system for kirigami.
Removing files in build directory for kirigami
Old build system cleaned, starting new build system.
Running cmake targeting Unix Makefiles...
Unable to configure kirigami with KDE CMake
kirigami didn't build, stopping here.
<<< PACKAGES FAILED TO BUILD >>>
kirigami - /home/data/log/2021-08-17-02/kirigami/cmake.log
Important notification for kirigami:
kirigami has failed to build 5 times.
You can check https://build.kde.org/search/?q=kirigami to see if this is expected.
:-(
Your logs are saved in file:///home/data/log/2021-08-17-02
And the aforementioned log says this :
CMake Error at CMakeLists.txt:29 (find_package):
Could not find a configuration file for package "Qt5" that is compatible
with requested version "5.15.2".
The following configuration files were considered but not accepted:
/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake, version: 5.12.8
/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake, version: 5.12.8
-- Configuring incomplete, errors occurred!
See also "/home/data/deltachat_build/kde/us/frameworks/kirigami/CMakeFiles/CMakeOutput.log".
Then I tried using cmake, I managed to build and install the deltachat core, and after a few stop to install missing dependencies (libssl-dev and libsqlite-dev), I thought the compilation for Kdeltachat was almost done but it got stuck with some qml compliling error that I wasn’t able to resolve.
Error compiling qml file: /home/data/deltachat_build/kde/manual_build/kdeltachat/qml/ChatPage.qml:14:14: error: Expected token `:'
make[2]: *** [CMakeFiles/kdeltachat_autogen.dir/build.make:76 : qml_ChatPage_qml.cpp] Erreur 1
make[1]: *** [CMakeFiles/Makefile2:124 : CMakeFiles/kdeltachat_autogen.dir/all] Erreur 2
make: *** [Makefile:130 : all] Erreur 2
Finally I went for the nix installation. That was easy (although it felt like it was downloading half of the internet) and reported a successful installation … but kdeltachat crashed with some GLX error
qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile)
Could not initialize GLX
Abandon (core dumped)
That’s it
kdesrc-build is generally not needed if you install all the -dev dependencies from your repositories. It should be moved somewhere to the end of the README, it’s only needed if you want to run the latest Kirigami.
As for “expected token `:'” error, it’s because the required keyword for properties in QML is not supported, it indeed means your Qt5 is too old.
Could you try running with export QT_XCB_GL_INTEGRATION=none as suggested here: NixOS: qt + glx broken / segfault / "Could not initialize GLX" · Issue #85866 · NixOS/nixpkgs · GitHub
Another alternative you can try is ~link2xt/kdeltachat-flatpak - Flatpak build for KDeltaChat - sourcehut git, make sure to update git commit reference to build the latest version.
Yes it probably should because for me it looked like that was the recommended method
Yes that worked !! Thank you
Haven’t had the time to try it more though, I quickly looked if I could set it up with my work email since I don’t really want to use my personnal email on my work computer. But …it is a gmail address and I couldn’t get an API key but I do not have 2 factor authtentication, … so I didn’t get past the first account setup form, for now
Is it possible to use nix on my ubuntu work computer to make a .deb package that I could install on my personnal computer running debian 10 ?