Is it just an experiment or you have an actual plan? Any help needed?

[Ivan Balashov]

I'm willing to help

[Dirk Van Haerenborgh]

Currently, it's basically an experiment to learn Rust, but as I am becoming increasingly frustrated with thunderbird, and evolution (and I find geary not extensible enough), I am actually aiming to make this into a functional mail client.

I probably won't get there alone though. This is just something that I like to work on in my spare time, so any help would definitely be appreciated.

I'll knock up a plan where I want to go with this soon. I am still in the process of coming up with the global architecture:

• notmuch bindings (those seem functionally complete)
• gmime, as that seems to be the most robust mail parser: big work in progress. I generated the ffi bindings just this morning. It builds, but I'm not sure if it works...

[Ivan Balashov]

i've never used rust for anything more than a simple experiments for fun, so i'm probably not going to be very helpful, but i'l look into the code.

[Gaute Hope]

Hi, astroid maintainer here. I was curious about wether we would be able to join efforts with astroid and this project. Astroid needs some major redesigns. Some parts are good, but some parts have grown out of hand. The WebKit interface is obsolete, and I’m not sure if the current model is the correct one. Maybe there should be some kind of service supporting a web interface, since we currently rely on us bindings anyway to update dom tree this should not be a big deal. It would be great to consolidate the rest of the ui into one toolkit, but I’m not sure if it is the right way to go with a web interface for the rest aswell. Either way, rust looks very interesting, and at least the c++ implementation could be more rusty (separate data, more smartpointers).

I don’t have the time to do a complete rewrite of astroid anymore, but it could be an option to collaborate. As I read your plans you want an internal editor, which I think is great especially for quick inline replies. But I’d also like to keep the option for an external editor. Any thoughts? Do you think this is viable?

[Dirk Van Haerenborgh]

Hi!

Development on enamel is a bit stalling a.t.m. Even though I'm planning to eventually use this as my daily driver, it's still very far away from that. I'm currently just experimenting with how I'd like to design the basic building blocks. Currently, I'm trying to get rust-cap'n'proto to work with the new Rust futures api. I'd like to use that for all client/server comm stuff.

I'd certainly like to join forces! As you may have noticed, Enamel draws a lot of inspiration from Astroid, but since I'm not a vi user, the user interface wasn't everything I'd have liked it to be.

An internal editor is indeed something I envision, but I certainly don't want to be limited by that. For a lot of emails a decent editor is just a must, and it seems silly to implement all of that again. So, at least an option to 'edit in your preferred editor' has to exist.

Also, a gtk interface may not be for everyone, so I was working towards a separation of purely visual vs functional with a daemon for async tasks. That would make other UI's, (ncurses?) an option.

The WebKit interface is obsolete

What do you mean? what should be replaced by?

[Gaute Hope]

fre. 28. jun. 2019 kl. 15:11 skrev Dirk Van Haerenborgh < [e-mail]>:

Hi! Development on enamel is a bit stalling a.t.m. Even though I'm planning to eventually use this as my daily driver, it's still very far away from that. I'm currently just experimenting with how I'd like to design the basic building blocks. Currently, I'm trying to get rust-cap'n'proto to work with the new Rust futures api. I'd like to use that for all client/server comm stuff.

Is this partly due to library bindings not being ready? I remember this was a major factor when I choose C++. And it is probably my biggest concern with rust (which I am very positive about). I'd certainly like to join forces! As you may have noticed, Enamel draws a

*lot* of inspiration from Astroid, but since I'm not a vi user, the user interface wasn't everything I'd have liked it to be.

Definitely, the interface should not be locked to a particular set of keybindings. This was not the intention with astroid, but it probably shows in the implementation what is my preference. Either way the astroid keybinding system is not flexible enough. An internal editor is indeed something I envision, but I certainly don't

want to be limited by that. For a lot of emails a decent editor is just a must, and it seems silly to implement all of that again. So, at least an option to 'edit in your preferred editor' has to exist. Also, a gtk interface may not be for everyone, so I was working towards a separation of purely visual vs functional with a daemon for async tasks. That would make other UI's, (ncurses?) an option.

Yes, I am also considering rewriting as an CEF application. This would make it cross platform, and we need a web engine anyway. I would have to make some tests about performance for the other views except the thread view. Which is probably the place where performance issues are the least noticeable. This would work with a backend serving maybe a web assembly (rust?) app, and could also serve other type of interfaces. Even a web interface. At this point it is probably worth thinking about which niche this applications fills: fast, lightweight, GUI (can render and write html emails). For text there is alot, and there are other webby clients like nylas derived(probably slower, at least searching, which is pretty instant now - and I would say one of the determining advantages: much faster than gmail, so that you don’t even think about doing a new search.) The WebKit interface is obsolete

What do you mean? what should be replaced by?

First astroid used the dom bindings in WebKit1, then after a huge effort I moved to the webextensions part. This seems to be a wrapper around jscore. Shortly after completing, these bindings were also deprecated. So now I think the correct way is to somehow use the jscore. But with an setup like mentioned above, maybe it is easier with an typescript or webassembly app interfacing via rest or grpc/jsonrpc/whatever (but fast, maybe http/2 or more direct sockets like astroid does now). —

…

You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAN363R5BWEXSB4XUZUURDP4X5W3ANCNFSM4EXZUZ3Q> .

[Gaute Hope]

Hi, I have an (basic) experiment going.. let me know if you want to check it out and I can add you to the repo. Currently based on your notmuch-rs, still no e-mail rendering (only thread-index), but seems like gmime-rs is the only viable option.

[Dirk Van Haerenborgh]

Cool! I'd love to check it out. I've been very busy with other stuff so progress on enamel has stalled a bit.
As for gmime-rs: I've seen that the gtk-rs folks have been making some API changes here and there, so I'll probably have to re-run gir again.

[Gaute Hope]

Great! Let me know how it works out. Idling on matrix.org or freenode.