to me the idea of having a Pidgin plugin is really appealing, this will allow users to use Delta Chat in all OS where Pidgin runs, including 32bit OS, also will allow multi-accounts which is a “must-have” since almost everybody use more than one email account and all Delta Chat clients seems to ignore this :-/
2 Likes
deltachat-desktop supports multiple accounts.
I had never used it but, I was thinking desktop app was behind Android in dev/functionality terms, seems like I was wrong haha
Well, make feature requests on KDEs & Gnome’s issue trackers. AFAIK both KDE Plasma and the Gnome Desktop come with their own pre-installed instant messengers, I think KDE’s was named Telepathy.
I don’t use Electron apps due to privacy concerns, so I was thinking about creating a Java app which displays the HTML generated or served by Node.js in a JavaFX web view. Being based on Java, such an application would be cross-platform, too, while avoiding the privacy issues.
I have already experimented with showing some other app built with Node.js in a JavaFX web view. This works in general, but some details like favicon, handling window resize, data exchange with Javascript etc. would have to be addressed.
Fixing such details might get frustrating, so I’m planning on making a proper JavaFX client using the core library. I’ll have to check if I can just extract and use the bindings from the Android app, i.e. find which classes are needed and if I have to strip out Android specifics from them.
Try that if you want - make sure you use the rust core.
Here is whats planned for desktop clients:
- A version using https://crates.io/crates/webview <- If it works it will likely be the successor of the electron app, because using the systems browser and not shipping nodejs saves drasticly on download size.
- A desktop client with PyOt
- I think about creating an Rust / GTK app using libhandy for use on gnu+linux phones like the upcomming purism librem 5, which would also work on desktop.
PS: Node.js is build on chromes javascript engine V8 https://duckduckgo.com/?q=v8+js
I don’t know, maybe its easier to develop, but it would add another layer.
Compared to rust+webview it would have 3 layers (rust, python, javascript) instead of 2 (rust, javascript).
I mean as an alternative to the PyQT implementation, since with pywebview it will be an html based gui and guess it will be easier to port the current desktop gui, pywebview has an interesting feature of letting you define a Python API, that can be called from javascript, so this will do really easy to create a bot/game api that can be called from js
I believe qt also has a webview.
1 Like
actually pywebview can use the qt’s webview, but when you mentioned Python + PyQT I was thinking you was talking about a native qt app not an html based app
2 Likes
Thanks, I’ll definitely use the Rust core because I already fell into the trap of posting a PR against the C core which won’t be merged now 
So you had the same idea as I had with the web view, just with Rust, good to know. But seeing the status of the project and my experience with the Java web view, it sounds even more reasonable to me not to package the web app into a desktop window, but to use a cross-platform framework directly.
It looks like Electron has been so successful and has put so much effort into this solution that alternative solutions were left underdeveloped.
Would unhosted apps help to avoid the need for that?
What are you referring to?
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.