astroid
astroid copied to clipboard
astroidmail
Astroid as Webmail Interface
I was wondering how hard it would be to turn astroidmail into a web interface and if anyone has tried / is working on that project. One option that I came accross was streaming qt with WebGL, but I'm also wondering given how much of the project seems to be html and css based, how hard it would be to simply use a website as a backend directly?
I ended up with a similar conclusion since we need a html viewer for html email anyway, I did experiment with a rust backend and an inferno frontend: https://github.com/gauteh/ragnarok using either a browser, electron or node-webkit (which I think is using chrome now).
It's pretty fast. The backend can stream the results as quickly as notmuch-search can output them. Inferno handles 100s of 1000s of rows. I never progressed any further. Some of the dependencies broke in newer versions, so try pinning them if trying to build.
Yes, through the backend.
tor. 25. jun. 2020, 16:17 skrev Max Mehl [email protected]:
Thrilling! But would that still allow for using external editors like gvim?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/issues/689#issuecomment-649573433, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN363GM5E4UKE5YP4T573RYNL75ANCNFSM4OICXO5Q .
If anyone wants to take responsibility for the frontend I would be happy to help out on the backend.
I'm going to try to look into it this week.
Just so I'm clear what I'm dealing with: What state is this currently in? Is it working but needs testing & fixes, or did it dead-end a while ago and needs to be overhauled? Was it just a concept that never got implemented?
It is at concept level, maybe a bit more, I was just starting to implement sending/editing, then it would be possible to use as a provisional email client. But it is not much code yet, so it could be completely redone. I experimented with several js/ts frameworks and this was the only one fast enough. Unless just skipping frameworks completely. It would have nice to stick to traditional toolkit to avoid memory, but we need some web engine anyway.
søn. 28. jun. 2020, 16:55 skrev Taeer Bar-Yam [email protected]:
I'm going to try to look into it this week.
Just so I'm clear what I'm dealing with: What state is this currently in? Is it working but needs testing & fixes, or did it dead-end a while ago and needs to be overhauled? Was it just a concept that never got implemented?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/issues/689#issuecomment-650774467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN367LQTC5SZ4XR7TXW7LRY5KV3ANCNFSM4OICXO5Q .
Gotcha, thanks.
And how were you imagining this interfacing with the existing Astroid code? What parts can get reused? Is there a nice place in the structure of Astroid that this can slip in as a replacement for some component?
Taeer Bar-Yam writes on June 28, 2020 17:31:
Gotcha, thanks.
And how were you imagining this interfacing with the existing Astroid code? What parts can get reused? Is there a nice place in the structure of Astroid that this can slip in as a replacement for some component?
It does not interface with the existing code, and it cannot really replace a part of the existing code since the existing code is very integrated. The code will be very useful for guidance and solutions to problems. It was also originally inspired by the sup code (e.g. the chunks structure). It was easier to re-do the UI using bootstrap and components from there. GUI parts will be very different. The nice thing is that this can separate UI and data strictly. It does use the notmuch command line tools though. E.g. the generation of message structure into JSON.
I'm confused. Would this basically be a re-implementation of astroid? Sharing only the guiding philosophy and aesthetic and such?
Taeer Bar-Yam writes on June 28, 2020 18:21:
I'm confused. Would this basically be a re-implementation of astroid? Sharing only the guiding philosophy and aesthetic and such?
Yes.
Taeer Bar-Yam writes on June 28, 2020 18:27:
Gotcha. Okay, I will try to look at it this week.
Nice :) I'll try to clean up the backend a bit tonight.
I could definitely give a few hours a week for the front end. I'm worried however - one of the things I like the most about Astroid is how light it is. Wouldn't we lose much of that if we turn it into an electron app?
on the a second thought: this would open the possibility of exposing Astroid over the web and using it on my phone too.
bjesus writes on June 29, 2020 19:19:
I could definitely give a few hours a week for the front end. I'm worried however - one of the things I like the most about Astroid is how light it is. Wouldn't we lose much of that if we turn it into an electron app?
Yeah - I agree. I think nw.js is a bit lighter, but I am not totally convinced. There is another project with a GTK GUI: https://github.com/vhdirk/inox, but I haven't tested it. We briefly discussed sharing backend, but it petered out: https://github.com/gauteh/ragnarok/issues/1. We rely on the notmuch bindings from @vhdirk. There does seem to be several projects started, but maybe not ready yet, also came across this: https://gitlab.com/rhn/quemail. So I think this will can only be a success if it can be a continuation of astroid, with the lessons learned there, possibly a re-write like this project.
I think the niche for astroid is as lightweight as possible, but still GUI + keyboard-driven, and that is what I am looking for too. We don't want to re-create gmail, so lets avoid angular.
The main reason why I think it might still work (and be less complicated to implement) is that we already do embed webkit in astroid, and we would have to embed some engine, probably chromium. If we move the rest of the UI into webkit, astroid will just be a trimmed down browser -- almost like electron/nw.js. I think this might also be a good way to do it: launch the web renderer from the backend with whatever toolkit. It probably has to be chromium though. I don't think servo is ready for it yet. Also, I think it is more people that can contribute to the frontend. You can run the frontend in a regular browser tab as well, testing out: 1) electron, 2) nw.js and 3) browser tab at the moment.
I have tested the prototype on Mac OS and Linux.
FWIW, as a daily and hardcore astroid user, I am not sure about the implications of moving astroid UI to the web – but since I do not know these frameworks very well and how they influence workflows, please allow me to just share my thoughts.
- I completely agree to the analysis that astroid's core benefits is being leightweight, notmuch-native, and usable with keyboard and optionally mouse. It follows the UNIX approach and does not try to reinvent editors or mail fetchers. Any reworking should built on top of these principles IMHO
- It makes sense that using a web interface probably increases the likelyhood of more contributors. I am often asked about my mail client and that it's great, and people are eager to use and contribute, but when they learn that it's C++, motivation quickly shrinks.
- What I also appreciate with astroid it that it's accessible in a sense that I can easily watch debug logs, include my crappy shell scripts, and fine-tune the CSS at some places. I am not sure whether electron etc. would allow for the same level of customisability.
- The electron apps I know (e.g. Signal Desktop, Rambox) look nice, but carry some other problems that come with the framework's complexity. I am too little of a programmer to estimate whether arising problems are caused by the framework or by bad programming, but it should be considered.
- It would be nice if the rework would solve some issues that have been caused by the webkit rework, e.g. printing, mouse-clicking attachments etc.
Just my 2 cents. Do not misunderstand me: I am a happy astroid user, and I would be so glad if this application will continue to live a long and stable life :)
Max Mehl writes on June 29, 2020 20:31:
FWIW, as a daily and hardcore astroid user, I am not sure about the implications of moving astroid UI to the web – but since I do not know these frameworks very well and how they influence workflows, please allow me to just share my thoughts.
- I completely agree to the analysis that astroid's core benefits is being leightweight, notmuch-native, and usable with keyboard and optionally mouse. It follows the UNIX approach and does not try to reinvent editors or mail fetchers. Any reworking should built on top of these principles IMHO
- It makes sense that using a web interface probably increases the likelyhood of more contributors. I am often asked about my mail client and that it's great, and people are eager to use and contribute, but when they learn that it's C++, motivation quickly shrinks.
- What I also appreciate with astroid it that it's accessible in a sense that I can easily watch debug logs, include my crappy shell scripts, and fine-tune the CSS at some places. I am not sure whether electron etc. would allow for the same level of customisability.
- The electron apps I know (e.g. Signal Desktop, Rambox) look nice, but carry some other problems that come with the framework's complexity. I am too little of a programmer to estimate whether arising problems are caused by the framework or by bad programming, but it should be considered.
- It would be nice if the rework would solve some issues that have been caused by the webkit rework, e.g. printing, mouse-clicking attachments etc.
Just my 2 cents. Do not misunderstand me: I am a happy astroid user, and I would be so glad if this application will continue to live a long and stable life :)
Thanks a lot. I think these are a very good starting point. And perhaps it would be a good idea to state the goals with a detail level similar to what you have here. I had a list in the README (https://github.com/astroidmail/astroid#main-features) that I started to work from when I first created astroid. Some fell out (like displaying math with mathjax). This would be a good idea whether the work continues on the existing codebase or on a re-write.
I did feel that there are some problems with the current code, memory issues, webkit, GTK not being perfect for the type of modal keyboard-driven UI. This is the reason that I contemplated doing a re-write. Having done some work on web frontends I think they can get sluggish very quickly, but it is definetely possible to avoid that. As you mention, I share your experience with some electron apps. On the other hand; Electron has been used to write e.g. VSCode or Atom, which while not lightweight, are waaay more complex than astroid needs to be and still fast(-ish). The memory and concurrency issues which has been the main source of bugs in astroid could be mitigated by using Rust. A lot of the functionality will have to be implemented on the frontend (in typescript hopefully), so we won't get the same benefit there. Unless we use something like Yew with wasm (https://yew.rs/docs/). Which I think would be interesting! It is probably easier to use now than when I looked at it last year. But then we will maybe have fewer potential contributors.
Max Mehl writes on June 29, 2020 20:31:
- The electron apps I know (e.g. Signal Desktop, Rambox) look nice, but carry of a programmer to estimate whether arising problems are caused by the framework or by bad programming, but it should be considered. * It would be some other problems that come with the framework's complexity. I am too little nice if the rework would solve some issues that have been caused by the webkit rework, e.g. printing, mouse-clicking attachments etc.
By the way, the current prototype (frontend using nwjs) uses less memory (120mb) than current astroid (170mb), and is faster/snappier at displaying email threads. Add some memory for the backend.
I am all in for a re-write if the use and feel will be the same or better! Thanks for considering this, it could be a great evolution for the whole project :)
I'm not sure if a doing everything in a web app is the solution, but the whole thread view and webkit part should be re-done.
I personally would rather go native rather than web, but maybe we can "abstract" the whole thing enough so that astroid can be started with a web UI if someone implements it? But first we should get back to the current state of the app, if we want to reimplement it in Rust. After that, we could refactor everything to make a web UI possible.
I'd love to collaborate on a port to Rust, if we can get a few people together and get this actually done!
Yes. Note that the thread view is a webkit webview minimal web app. With all logic on c++ side.
ons. 22. jul. 2020, 16:17 skrev Matthias Beyer [email protected]:
I personally would rather go native rather than web, but maybe we can "abstract" the whole thing enough so that astroid can be started with a web UI if someone implements it? But first we should get back to the current state of the app, if we want to reimplement it in Rust. After that, we could refactor everything to make a web UI possible.
I'd love to collaborate on a port to Rust, if we can get a few people together and get this actually done!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/issues/689#issuecomment-662479856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN36YMVJR5V4YTZQJJTYDR43YGRANCNFSM4OICXO5Q .
