HERMES Mail - A full-featured eMail client for Haiku?

Development
21

For the exact same reason we aren’t interested in the Linux kernel. It’s not about lack of functionality, it’s about a disagreement in philosophy.

It’s also more than “barely functional” at this point, but, whatever.

Uh, if MS Outlook doesn’t have it, I am pretty sure we are allowed to make an excuse as to why we don’t have it. We are a small, unpaid team, remember; we aren’t expected to be innovating beyond massive corporations just yet.

That sounds completely unsustainable; especially when you are an open-source project with (currently) almost no developers. Why would you ever do that?

Inkscape is GTK, not Qt, and it stands out because GTK doesn’t really care about this. Adobe Illustrator was actually built on Qt for a while. Maybe it still is? (Or was that just Premiere?) So, it’s pretty amusing you’ve used it as an example.

Uh, than what? Certainly they’re quite literally hundreds of times faster than Electron apps…

They fixed this in 5.10 by doing a complete overhaul of the accessibility subsystem.

Can you really identify all the Qt apps on your system correctly? It’s actually surprisingly difficult to do on Windows and macOS where the Qt devs strive for pixel-correct accuracy.

Personally I think Qt is a very good choice for a cross platform toolkit, in addition to being miles better than the competition. I’ve used it a lot myself. I’d prefer a cross-platform Be API better (and I’d be working on that, if I had time; there’s a significant amount of code towards this effort already as part of WonderBrush 3.)

2 Likes
22

Saying Haiku users wouldn’t be interested in this is probably not quite true. I for one would be interested in seeing this in the ports/depot tree.

I think what is being meant is that interest in having this as a part of the core OS is slim to none. If a port of this was modified to the point that it fit with the flow and philosophy of Haiku enough to be part of the core system, it would have little resemblance what it is now. This is taking into account that it is straight C++, without external libs. At best, some bits and pieces might be able to be ported into the Haiku system to help bring in new features.

23

@cb88 - Well, it’s C++, so it should be entirely possible. Other than the GUI, HERMES Mail is really nothing more than a collection of libraries for sending and receiving POP and SMTP mail, as well as authenticating with SSL and Kerberos, Hunspell… it’s fully modularised. If you need a library, of course you can compile just that library. The project’s used Visual Studio since, well, forever, but that doesn’t mean you can’t compile it in GCC instead (some assembly required).

@waddlesplash What I’m unsure about, and tried to express but couldn’t really find the words, was how does the collection of GUI, libraries, etc called HERMES Mail disagree with the Haiku philosophy? Consider an approach where you simply take whatever libraries you need (be it an updated SMTP stack, Kerberos authentication, etc) and use it in Haiku. Now, that wouldn’t be in the spirit of my original proposal, but there we are. It’s a big collection of files, and I refuse to believe that nothing in there would be useful.

On the other hand, my original idea was to create a whole new GUI for the libraries and business code as a whole. I mentioned a one-codebase-per-system philosophy because, as given to us, the source tree had one codebase for Windows in C++, and an entirely unrelated codebase for Mac in C and Carbon (this was frozen in the Intel transition days). Ignoring Mac for a second, it’s clear we can use most of the libraries and business code in Windows, Haiku, and Linux, and we can design a native GUI for each. That’s what I meant by one-codebase-per-system: we could (conceivably) have a common pool of libraries to draw from, and a separate application on each. Maybe we could extend the Haiku Mail GUI, keep the Haiku mailstore code as is, and crib the HERMES Mail feature code. If that’s what you object to, I understand, and we can agree to disagree.

The Mac stuff is fairly interesting (though REALLY off-topic for Haiku-discuss): would it be more useful to compile the “Windows” libraries (yeah, I know, libraries are usually cross-platform) on Mac and try to build a Cocoa GUI shell around them, or try to fit a PowerPC, Carbon-based peg into an Intel, Cocoa-based hole?

Back on topic: I didn’t say Qt was a bad toolkit, as cross-platform toolkits go. GTK is a good cross-platform toolkit, Qt is a great one, but I notice when an app is cross-platform. The look-and-feel is ever so subtly different, and there’s a slight lag (though I could be imagining this) compared to a pure-native app. Not that I dislike cross-platform apps, especially when they mesh well (compare GNU Emacs or Deluge running on Mac to, say, fontforge or qbittorrent).

I was just saying that it bears thinking about a native “port” (in a rather loose sense). We thought about Qt at the beginning of the project; perhaps we should’ve used it, because we’d likely have a fully cross-platform, Linux and Haiku-compatible product by now. Instead, we have a shell that runs on Windows only, and a vaguely cross-platform core.

P.S.—I’m running OS X as my daily driver, and I’m currently trying to make Haiku run on my MacBook Pro. The non-native apps running on my system are WireShare (Java; I developed it myself), Calibre (Qt?), qbittorrent (Qt for a fact), GNU Emacs (GTK), GIMP (GTK), LibreOffice (Qt), deluge (Qt), Fontforge (neither Qt nor GTK), and Inkscape (GTK?). Anything using the Tango icons is likely either Qt or GTK.

24

Haiku’s philosophy is rather apparent in it’s API. Currently, how well does HERMES core mesh with the Haiku API? I’m not saying it can’t be done. I welcome such a project in the Haiku ecosystem. How familiar are you with the history and philosophy of BeOS and Haiku? How well does the coding and design philosophy of HERMES match Haiku? Not just the GUI has to be made native, but the way the underlying messaging is handled within the system.

1 Like
27

Well, the “core” (by which, I assume, is meant the libraries that introduce various features, such as POP3, SMTP, Kerberos, spellcheck) is whatever you make of it. These can bring extra functionality to any system that favours C++: Windows, Haiku, even Linux and OS X. There aren’t that many Open Source SMTP stacks; the one in the HERMES Mail source is new to the ecosystem and, I think, warrants closer inspection.

But the main treasure is the UI. Yes, it’s MFC and the code is replete with Windowsisms, but that’s somewhat beside the point. When compiled, the app looks like Haiku. I’d actually say it was an attempt to render the Haiku idiom in Windows. By port, I didn’t mean we’d run the existing code through a compiler on Haiku, see the errors, fix the errors. I meant we’d have the Windows code on half the screen, and then translate the MFC/Windowsisms into their BeAPI equivalents, of course leveraging the included libraries, on the other half.

Keep in mind, this is exactly what Søren and Pete spent the last six months doing on Windows. The original app used a 100% proprietary toolkit and API (which we did not get), and we had to convert all of that into straight MFC.

Because of that, a lot of the Windowsisms actually work better on BeAPI than they do on Windows. For example, BeOS had a tabbed interface a long, long time before Windows did, and implemented it a lot more elegantly; in fact, a lot of the proprietary API was used just so Qualcomm could have a tabbed interface and floating, dockable windows and toolbars in 1997. BeOS had all of this built in; I distinctly remember playing with tabs and floating windows as a 10-year-old tyke on BeOS R5 (the last before Be folded).

I respect your point about file system and attributes. I won’t even pretend to understand low-level file system stuff, but UI/UX I can handle, and there is a very long-winded reason that a (totally hypothetical) HERMES Mail/H would integrate much better with Haiku on a user-experience level than Eudora ever did, or HERMES Mail/W ever will, with Windows.

That’s fine, but for the people who did display at least peripheral interest, here’s an attempt to explain in more specifics, from a UI/UX design perspective, how HERMES Mail fits better into BeOS and Haiku than it does into Windows:

  1. The sine qua non of HERMES Mail is really nothing more than a floating, dockable (to edges of screen), tabbed window listing a) your mailboxes for each account, b) your accounts, c) metadata search. QUALCOMM gave this window the rather unappetising name of Wazoo, because it had “functions coming out the…” On Windows, until recently, the Wazoo required either some complicated trickery or a proprietary toolbox/API. With BeAPI, it Just Works and has Just Worked since 1997.
  2. When you click on a mailbox in the Wazoo, it opens up in a separate window, with (on Windows) a tab bar across the top. On Windows, the mailbox view and Wazoo would be constrained within/children of a parent window, which IMHO drags the experience down. With BeAPI, I think it’s entirely possible to click on (say) Inbox in the Wazoo, which opens as described, as a “maximised” window taking up most of the screen space (ofc not covering the Wazoo itself, or the toolbar if not docked). With BeAPI, it would open, by default, as Tiled with the Wazoo. Then, you click on Outbox in the Wazoo, and it opens automatically, with zero user intervention, as a maximised window on top of the Inbox—i.e. the Stack part of Stack and Tile.
  3. The mailbox view has a toggle for preview of messages (i.e. embedded Blink/Webkit) but if you want to see a full message, you double-click it, and again, it opens up a maximised window in the Stack. With this switching between mailboxes, messages, templates, etc., we end up with an ad hoc tabbed user interface. Windows had to bury it in parent/child, with proprietary trickery to generate the tabs themselves… BeAPI Just Does It. Imagine the Haiku Tracker, now substitute “files” and “folders” with “messages” and “directories”. There’s your UI in a nutshell.
  4. The toolbar. I haven’t mentioned it much, but there is unprecedented flexibility with it. The toolbar is nothing but a user-defined one-click collection of menu items (for example, the user could place the menu item Message → Send to Group… on the toolbar so it’s there at one click).
  5. The main sticking point is the menu bar. On Windows, it’s the only non-floating, non-tabbed, non-dockable part of the system: it’s at the top of the screen and stays there. How would we do it on Haiku? Make it a floating and dockable part of the Toolbar? Or do we put a copy of the menu bar on every message/mailbox/whatever window? The latter choice is more Tracker-like.

All in all, the UI/UX that took an almost literal eternity to design on Windows would be a piece of cake with BeAPI. That is the power of Stack and Tile.

28

Just FYI stack and tile is a recent addition to the BeAPI that was not part of BeOS back in the day but just makes sense given the tabbed windows. Which previously were a a curiosity but now made more functional.

AS far as the floating menu, it can probably stay that way… there are a couple QT apps that do that I think like Audacious for instance so I guess it can be done natively as well. I could see there being some R2 ideas for that though with extensions to the deskbar to allow some applications to integrate more closely there perhaps as a replicant area in Deskbar? FYI a replicant on BeOS/Haiku is basically a windowless applet that lives on the desktop wherever you place it.

2 Likes
29

I have no doubt that HERMES would make a great addition to the Haiku ecosystem. I bet it would become a rather popular app in the depot.

However, the kitchen sink philosophy kind of rules it out for being a replacement for Mail in the default install. BeOS took the Unix philosophy of small, simple programs that talk and integrate with each other to perform complex tasks. They then made this philosophy graphical. Haiku follows this philosophy.

I’m not trying to discourage work on making HERMES native. I’m just pointing out the reality check that it doesn’t make a good candidate for being part of the base system. This does not preclude it from being a replacement available through the ports system.

1 Like
30

The more I think about it, the more I feel like the sending and fetching of mail on Haiku is all right. The spam filter could be co-opted as is, ditto for the way messages are stored. What I think could be improved is the interface and the features.

Essentially, what we received as “Eudora/W” was a bunch of mail support code (as mentioned, POP, SMTP, SSL, etc), a shell written using API’s that we couldn’t legally touch, and the glue to link it all together and store messages on local disk. We decoupled the shell from the libraries and the glue, and reverse-engineered the bits of the shell that required proprietary API’s so we could clone it all in (modern) MFC.

Now, some of the mail support code/libraries might fill a niche in Haiku, but I’m not banking on that. We’ve got mail_daemon and it works, to the credit of its developers, amazingly well. Same for the other parts of the whole eMail system.

Again, from a UI/UX perspective, we could embed a Tracker replicant (don’t know if Tracker is replicantable, but let’s assume it is—not writing from Haiku at the moment) into the top of a MailboxViewWnd, the HTML viewer from WebPositive (hat tip to @PulkoMandy) into the bottom, and now whenever we click Inbox/Outbox/Junk/Bin in the Wazoo, it just launches a MailboxViewWnd with the target of the Tracker replicant set to Inbox/Outbox/Junk/Bin. I’m starting to love the modularity.

Strange minds think alike! It would really be a matter of “gluing” the various windows together. I’d almost call it a script—takes me back to my LISP projects that more-or-less consisted of the same thing. What I want from HERMES Mail is simply that I click the icon, it gives me the Wazoo on my left-hand side or wherever I put it last, it gives me the floating toolbar-cum-menubar (we can call it a Deskbar), and everything else would be an external program.

So, for example, Message → Send to Group would query People for the appropriate contact(s), pre-populate the To: field in Mail, etc etc etc. But the HERMES Mail app bundle would be the Wazoo, and the Deskbar. Maybe 1/10 the size of HERMES Mail/W. If that.

Who says it’s a replacement? Given Haiku’s modular, parallel style, it’d more likely be an addition, for power users, to make eMail more manageable. It could not be a replacement, because it would depend on the resources of the programs it replaced (unless we wanted to make it a Windows-style behemoth, which I, for one, don’t). As mentioned before with @waddlesplash, Haiku Mail by itself can’t be set up to send a message at a particular date and time. HERMES would take care of that… by using Haiku Mail. Mutatis mutandis for Send to Group.

Theoretically, we could just forget the repo, and go high-level (i.e. write code from scratch, using either visual reference or verbal instructions in English as a guide).

1 Like
31

A lot of this, you all understand, is fluid. Consultation with the community is just as important as fingers-to-keys coding; it tends to crystallise ideas, and I am nothing if not an idea man.

Just as an example, I earlier had the idea of a Tracker-like mailbox view, but after consultation, I’ve realised: why not simply have the mailbox view be the Tracker? From this came the idea that the only real code HERMES Mail needs to contain is to display the Wazoo, to display the Menu Bar/Task Bar, and to leverage the business code of Haiku itself.

Which is why HERMES Mail can’t be the only mailer on the Haiku system; it’s essentially an add-on to provide a Eudora-like interface and Eudora-like features to a system that is distributed. Basically, it’s only the interface.

1 Like
32

Having more software is always good. Personally, I don’t have the need for advanced ‘business’ features, but I suppose others do. Esp. should Haiku gain more users over time.

If there were someone willing to do the work of doing real integration into Haiku, there could be many benefits to the system in general:

  • Obviously a more feature rich mail_daemon with fewer bugs
  • Spell checking as a system service
  • Getting that index_server up and running to do full-text searches in any filetypes with a text translator
  • extending/hardening of the S&T API
  • possibly an extention of a styled BTextView as started in HaikuDepot
  • many new features and fixes to various areas of the whole system, same as with the WebKit port that revealed many bugs and shortcomings that had to be solved.

Yeah… that’s quite a list for 2 devs that really just wanted to quickly port an email client. :smile:

2 Likes
33

Quickly? No. Quicker? Yeah. The two devs I’m leading (I don’t code—they do) are elbows-deep in MFC, gearing up for the Windows release. There’s no timetable for a Haiku “port”/“rewrite”/whatever… but plenty of ideas.

Spellchecking as a system service? What’s wrong with Hunspell?

As for the rest of it, well, I can’t help there. The big chunks of service code are undeniably present, if not exactly stable. Mail etc.

But a wrapper, to hold it all together and present a nice, neat UI? That’s not there. Neither are, as you said, the advanced “business” features. I definitely didn’t see an option for, say, Kerberos authentication.

34

What is wrong with “beam”? Why an external program again, where we have a very good one. It just has to be worked on it again, eliminate errors and expanding the functionallity. For years, “beam” has always served me as a good email program.

Or is it your project and you want to bring it up on Haiku too?

35

The backend could be Hunspell. Spellchecking as a service in e.g. all BTextViews would enable spellchecking anywhere the user enters text. No extra work for the one coding the app.

2 Likes
36

Now that would be nice and is something I consistently bemoaned when working on HERMES Mail for Windows.

37

You must be joking.

38

Hi,

So, we are talking about some Windows-oinly software for which the GUI is already rewritten, and a port to Haiku would apparently mean using our existing mail infrastructure (throwing away Eudora’s core code) and writing an ative GUI (throwing away both Eudora’s code and Hermes rewrite).

Do you think it can be done in months? If so, do you think it can be done without using Eudora code at all? Because that’s what the plan is, now.

So, yes, our mail infrastructure is great but it lacks an actual client. I want my mail to show in threads. I want to use IMAP labels. I don’t want to use Tracker as an inbox, it’s not the tool for the job. I want the ability to display HTML emails. We are very, very far from a decent mail client. However, unfortunately I don’t think the Eudora codebase would help. The UI design, sure, but we will have to rewrite the code to fit our API and infrastructure.

It’s great that Hermes is a thing, and eventually I may use it on Windows or Linux (if it ever gets ported there). But if you’re to write something for Haiku, it will be a completely different mail client. Note that this isn’t so bad, after all, Eudora for Macintosh was also a completely different codebase.

1 Like
39

Well, it depends on what the plan is. If we follow @bullfrog’s implications to their logical conclusions, we’d have a very light bolt-on shell that would integrate Haiku’s current mail viewer, Haiku’s current mailstore (i.e. Tracker as an inbox), etc. as a graphical extension of the UNIX “pipe dream”. Features would be added from the Eudora codebase (things like spellcheck, kerberos, and just the layout of the application, with stack and tile) but it would be effectively a collection of C++ “scripts” and thus extremely “lightweight” compared to the Windows app. (As I said, maybe 1/10 the weight of HERMES Mail/W, if that).

If I followed the advice and criticism of @bullfrog? Yes, it would be a multi-codebase effort (which is something @waddlesplash mocked me for);

Would it take under six to eight months, though? Yes, you bet.

If we take a more full-featured approach (my original plan, which would be porting the whole MFC codebase over to Haiku, meaning a proper inbox, HTML display ability, and so on)… we’d maybe take a longer time, still less than a year, though.

Note that whichever way we take this (lightweight or full throated), we would also not be throwing away any of Eudora’s core code that Haiku doesn’t have an equivalent for. We’d integrate the Eudora code/libraries/infrastructure with Haiku, either way.

In general, the big issue is one of risk. If we scrobble together a quick-fix wrapper with only the tools Haiku already has… and it’s rejected from the system distribution… no harm done, I’ll put it in the haiku-ports collection, and we’ll call it a teachable moment.

On the other hand, if we assemble a nice, full-featured, monolithic e-Mail client, with a proper inbox, message display in full HTML, etc, and it gets relegated to the ports collection, I’ll feel like we wasted a year that could’ve gone towards, say, watching paint dry. Especially if it’s just us three.

So this consultation is also a consensus building exercise. Input is especially appreciated from whomever accepts or rejects pull requests.

40

There is nothing wrong with the “ports collection”. It is not an insult for software to be there. The packages are automatically built and available in HaikuDepot. That’s as far as it will get. We are not going to merge Hermes sources in the Haiku git repository. We may or may not ship it in our release DVDs. Currently we only ship a quite limited set of tools there, because we have no way to filter them out at install time.

So, there will be no pull requests here. You keep your codebase, make a great client out of it, using native Haiku features, and Haiku users will like and use it. That’s all you will get.

3 Likes
41

To clarify, Outlook does have the future-send feature and has for years. Last week I needed to send my weekly update to our head of Finance, but didn’t want to bug her while she was out on vacation. So I sent the mail to be delivered Monday morning. Thanks for pushing the envelope forward, developers and users!

1 Like
42

Truth.

@nmatavka Many fine Haiku native apps live in our ports system. As well as the likes of software such as Blender, Krita, LibreOffice, etc. HaikuPorts and HaikuPorter was not only developed as a convenient way of porting and packaging software from other systems for Haiku. It’s also useful for building and packaging native apps. Not everything can or should live in base Haiku. Who knows? If enough users and devs like it, it may just become a candidate of becoming the base Haiku email system. It’s way too early for that talk now though. The proof is in the pudding. You don’t even have your haikuporter recipe made yet. You can’t make pudding without a recipe.:wink:

From humdinger’s blog post on haikuporter:
“HaikuPorter is a python tool that takes a so-called recipe that describes the dependencies of a software and how to download, build and package it.”

That’s a great way of looking at it. It gathers sources and dependencies (if any), applies patches (if any), and builds it into a package that can easily be installed on Haiku. It works great for both Native and Ported software.

My advice would be to pick one platform that you really like to focus development of HERMES on. It sounds like you favor Haiku for this. It also sounds that windows API possibly doesn’t want HERMES in the Windows ecosystem, regardless of what users want. I understand user base is important. However if making something work for a user base is a headache, why endure the headache? Coding should be fun, right? If other user bases want to use it, it doesn’t need to be the main dev teams job to port it to them.