Postsack causes MacBook Pros with two GPUs to switch to the dedicated GPU, causing increased battery drain.

There's no reason I can see why it would need to do that; I presume it's a consequence of the Egui library usage.

Please investigate and fix, so battery life usage can decrease. Thanks!

Very cool project, and I just wanted to try it out (without pulling the repo and compiling myself). Sadly, the pre-compiled macOS binary only seems to work for macOS 12 (Monterey) and later.

It would be great if you can provide pre-compiled binaries that work on older versions too.

I see you already set the osx_minimum_system_version to 10.14, but it seems that didn't have the desired effect or was it maybe added after the initial release was made?

The link is a bit of a terrible abstraction to handle background threads via egui. The way it works is that when an action should be performed in the background, it will send the action over a crossbeam channel to a separate thread which continuously listens for input from the channel. The thread processes the action (e.g. performs a query) and sends it back.

Egui, in the default event loop, will check for any response in the receiver crossbeam channel (e.g. 30 times per second on 30fps). If a response is available it will be applied.

There're a couple of downsides to this:

• Request and Response are separated which makes it very difficult to use the Engine via Link in a non-async context.
• WASM doesn't support threads, so there is a wonky abstraction to allow sync access (with way too many cfg(target_arch = wasm32)
• This solution requires multiple additional abstractions which make it all a bit confusing to understand.

Egui apparently would work from separate threads but this might not work for other UI libraries (if we ever port it). So maybe a solution would be to have a SyncLink and AsyncLink with a closure that makes sure the request matches the response.

If the users clicks an email in the mail panel, the email is currently only printed out to the console. There're a couple of possible behaviours here:

• Use the importer email parsers and display the email in a window
• Open the email in Nautilus / Finder / Explorer
• Open the email in the installed mail app for reading.

Maybe this can be made configurable.

It would be useful to automatically draft a release with binaries form GitHub Actions once a new tag is pushed. Maybe even deploy to web once WASM is also part of the CI

Currently only the native builds are being run on CI.

Postsack currently uses mbox-reader for MBOX parsing, but it doesn't properly implement the standard. It only checks for the FROM string at the beginning of a line which means any email containing a newline with a FROM somewhere in the body is regarded as two different emails. The correct way to detect a new email in MBOX according to the RFC 4155 is:

Each message in the mbox database MUST be immediately preceded
by a single separator line, which MUST conform to the following
syntax:

• The exact character sequence of "From";

• a single Space character (0x20);

• the email address of the message sender (as obtained from the message envelope or other authoritative source), conformant with the "addr-spec" syntax from RFC 2822;

• a single Space character;

• a timestamp indicating the UTC date and time when the message was originally received, conformant with the syntax of the traditional UNIX 'ctime' output sans timezone (note that the use of UTC precludes the need for a timezone indicator);

• an end-of-line marker.

Right now, Postsack only displays emails. However, most of the code is written in a way that it could easily be used on any kind of groupable information.

• The importer is abstracted away from the dabs
• The database is abstracted away from the guy
• The gui only uses a couple of currently hardcoded information from ps_core which can be extracted into a trait
  • The Field::all_cases and the fields that are available for grouping
  • Everything in the FilterPanel and the MailPanel. Those would need to be more generic
  • The importer flow (select mail folder)
  • The copy texts

It would still be some work, but in the end Postsack could be more generic and be applied to most groupable data.

The Apple Mail importer currently fails on Windows. No, I doubt many people would want to import Apple Mail folders on Windows, but I think the issue is just something with the \n / \r\n line endings.

Hi there,

I'm the author of the Pimalaya project, which aims to provide Rust tools to manage your personal information. One of the subproject we have is a library to manage emails, and few clients built at the top of it (a CLI, a Vim plugin and an Emacs plugin). We plan to implement a GUI using egui. Then I found your project (I love the concept!). It could be so great to work together, here some ideas I had in mind:

• We plan to implement the mbox backend, and I see that you have issues with your actual parser, we could work together on implementing our own.
• You could use pimalaya-email to fetch emails and do your reports instead of reimplement standards (IMAP, Maildir, mbox, archives etc).
• If your project can be exported as a component then it could be integrated inside our email GUI.

Let me know!

Currently the basics for supporting a light theme are in place, but it is not working yet. While Egui does support light themes, the platform specific theme customisation is not finished for light themes yet (in ps-gui/src/platform)

Copy-Pasting from postsack-native:

Building for Windows works but doesn't create a proper application (e.g. with an icon) and also doesn't create a proper installer.

• cargo bundle doesn't currently work on Windows
• cargo wix should work, but I could not get it to work
• cargo build --release works, but then the binary has no icon.

Currently, Postsack only works if the emails are already downloaded to the users system, which means for Gmail to use Gmvault. However, this function could be added to be available out of the box via gbackup-rs. This would make it easier for a potential user to use the app without having to resort to third party tools before being able to actually use it.

https://github.com/marketplace/actions/windows-signtool-exe-code-sign-action

I'm using the Archlinux aur package with wayland (sway wm) but it crashes with the following error:

[wayland-client error] Attempted to dispatch unknown opcode 0 for wl_shm, aborting.
[1]    3407478 IOT instruction (core dumped)  postsack

I can launch it with WINIT_UNIX_BACKEND=x11 postsack but that's not ideal.

When receiving emails with attachments, the mailbox may get bloated.

Especially in conjunction with eventually deleting emails as in #16 , it would be useful to add filters specific to the size of an email.

Possible filters

Items marked with MVP seem desirable to have in the first incarnation.

• min size in Kb (MVP)
  • a slider to filter emails smaller than the minimum size.
  • Probably '0' as value would mean the filter is disabled, but there might be better ways to indicate this from a UX perspective.
• attachment
  • a checkbox to require emails to have an attachment
  • file extension multi-selection
    • Lists all actually used extensions and allows to focus on emails which have at least one of them.

Possible GUI Improvements

Extended statistics about displayed emails

Along with knowing how many emails are currently displayed, it would certainly be useful how much storage space they require. Maybe this information could be added to the top of the GUI.

Real-time updates when changing the filter

This would allow to remove the 'apply' button and would probably make it fun to play with sliders. It might also be an interesting exercise in async programming to make it deal with possibly longer filtering times gracefully. If filtering through 650k emails gets sluggish, one might consider throwing multiple threads into the mix.

As Postsack has a good separation between the individual parts, it would be possible to re-implement the ui nee ps-gui in another Rust UI toolkit such as Druid or Iced. This could be interesting in order to have a comparison how these different toolkits fare for a slightly more complex desktop app (also, to have a nice overview).

It seems there're no Outlook file parsers (PST / OST) for Rust. It would be possible to sys-wrap this C library.

https://www.five-ten-sg.com/libpst/

There's a crate for notmuch email folders, so adding support should be reasonably easy:

https://crates.io/crates/notmuch

One of the initial features I wanted to implement was being able to drill down to a specific set of emails (say everything from @groupon.com that was send in December 2016) and generate a deletion rule for my mail app (or gmail) so that I could safely remove those emails.

However, there is no standard around this, different apps have different rules, and most of them are not open / documented:

• The gmail rule system is very simple and the only way to generate rules from the queries in Postsack would be to generate a rule for each email with the email identifier which would be a huge rule list
• Apple Mail has a ruling system, but there is no way to import or export them, they're saved in a Plist in the V9 Mail folder and not documented.
• I didn't look into other apps

The better solution would be to write a Pop3 / IMAP client which understands these rules and uses them to delete emails. I started on something like that but gave up quickly because the focus was to finish Postsack first.

The yaml currently contains the hard coded version for the generated deb package. This can probably be read from the environment. Apart from that, it might also be useful to generate Fedora packages and maybe even ARM64 builds?

Hi there! I tried to run this on my single maildir. After about 30 minutes the process dies:

Basic Structure

The setup:

When it's processing:

When it hangs, it only adds one additional line that says killed

P.S. Thanks for the Nix shell file. That rocks!!

There's a crate for maildir email folders, so adding support should be reasonably easy:

https://crates.io/crates/maildir