Given that you have a Windows version that is already working, porting to Haiku using wine seems like the best approach. There’s no easy way to port the Mac version to Haiku, or the Windows version either, except by using wine.
As for assets, Haiku doesn’t quite use a resource fork quite like Mac OS does/did, instead it embeds all the assets it needs right into the binary. So you’ll need to take the assets, possibly from the Mac version, create a Hermes.rdef (or whatever you want to call it) file, add the assets you need to it like app icon, and all the toolbar icons, create a small BApplication wrapper and load the assets from the binary.
I was a user of Eudora way back when I first became a Mac user. On BeOS I think my go to was Mail-It from Beatware. Too bad the Mail-It source code isn’t around.
I used Mail-It, too, at work! I don’t remember that it used IMAP, must have been POP3. (On a Mac that had been running MacOS 8, where I was using Eudora.)
The pain of HTML emails … I’m obliged to spawn a browser for them. I can’t imagine grafting that capability into the email application itself - taking on too much there.
The proposed project, wherever it goes, will of course make not one dime of money, nor will it be a springboard to fame and wealth in any conceivable scenario. If packaging Eudora up with Wine sounds like the best kind of fun, that’s the ticket. It seems like this started out as a question, but the exact nature of the question is kind of unclear and it’s getting bogged down by your natural inclination to tell us all about Haiku. At this point is there some concrete information that would help?
I think using NetSurf’s rendering engine for html emails would be reasonable. Not supporting Javascript would be an advantage here (I don’t want my mail client to run any arbitrary code from emails I receive). And it’s not so complex to integrate in another app.
In Haiku, WebKit will also be an option once we get to providing a reasonable API for that.
I don’t know the system very well here, I don’t suppose it’s possible to archive the rendered scroll view off of (for example) WebPositive, and bring it up on your application’s shelf?
Not in the current version of Haikuwebkit. The way it currently works require special support from both the app and the window that it will be running in. It is not so easy to fit webkit to the way Haiku works.
With webkit2, the web engine would run in a separate process, and the webview will be redaced to just rectiving and rendering a bitmap of the page (and sending input events the other way). hopefully it will be much simpler.
The Eudora™ Email Client Source Code - CHM (computerhistory.org)
“The last Qualcomm Windows version of Eudora continues, with some glitches, to work well under Windows 10. The Apple Macintosh version, unfortunately, did not survive the transition to the modern Mac processors and operating systems, and can now only run using emulators.”
So, using Wine makes sense in this case and well supported for Eudora 7.1.0.9.
You can run HERMES as needed on a similar plan of Win/Mac virtualization//emulation/whatever on Haiku without much “porting” effort…
The idea is for Aurora to be a fallback, interim thing (at least, on the Haiku side), and I don’t see myself allocating someone to replenish Haiku’s wine cellar.
Explain the multiarch thing for me. We are compiling Aurora for Win(e) x64. Haiku runs on x64. I don’t see a problem. (Unless we’re talking about the ability to support RISC processors in future, such as ARM and RISC-V. Then it’s something we can plan for but really isn’t a pressing concern.)
Well, what I want is to open a discussion and seek a certain level of consensus. Right now, based on what I’ve read, this’ll be a C++ app (unless someone wants a Web app written in Elixir or something, and at that point I’m sorely tempted to advise them to bugger off, considering how much I push using native tools wherever reasonably feasible) but it will follow the user interface of Eos, rather than Aurora. Quite literally, splitting the difference (Aurora is C++/MDI, Eos is C/SDI, Helios? will be C++/SDI with stack-and-tile).
I agree with this, which is why I’m pushing the native idea hard. Aurora-on-Haiku is not bad as the user experience goes, though it’s Haiku’s “second language”, as it were.
By this I mean that Haiku, by-and-large, “likes” the Single Document Interface: i.e. each relevant “document” has its own window. In an e-Mail client, it’s logical to treat the inbox as one “document”; a message open for composition as another “document”; the message viewer, which can “page” through inboxed messages, as another “document”; and the toolbar as its own “document”. Aurora is not like this; it’s an MDI app that has captive windows, its own taskbar, etc. So the UI, even as a cross-platform app, doesn’t jibe with commonly accepted Haiku User Interface Guidelines.
Dependency overhead doesn’t affect WebKit, because Haiku already includes WebKit. The point of the comment above was that, for example, supposing I had Aurora in the ports tree, now I download it, and before I can install it, HaikuPorts has to install Wine first. Basically, the idea is to rely on system resources whenever possible.
Maybe not. The Mac version already works, more or less; not much has to be changed in the code. Yes, an Aurora package will be made available, and it will pull in Wine etc., but whether I can mop my brow and heave a sigh of relief is still moot (i.e. arguable).
The thing is, if we’re talking about a native rewrite, it’ll of course be in C++, because Haiku is very much “C++ unless good cause is found to the contrary”. Just like Aurora. But the accepted Haiku User Interface Guidelines stipulate single-document interfaces. Just like Eos.
So at the moment, I’m still rolling it over in my head.
I’ll PM you.
Well, what happens there is you spawn not the whole browser with all the window decorations and everything… but just the so-called HTML engine, i.e. the bit that shows web pages. And then you basically plop some window decorations, icons, menus, toolbars and other doodads around it to make it yours (along with the necessary code).
I’m trying to gain consensus and buy-in, basically. First question: “Wine port or re-write in C++?” Second question: “If re-write in C++, follow Aurora (Windows) or Eos (Mac)?” And people asked follow up questions that I hadn’t really given much thought. This is a brainstorm.
That’s a very reasonable point. If I want a WebKit-powered mail client (because the two others are WebKit-powered also), I’d need to wait for that API to be fleshed out.
That Web page is loooooong out of date. Particularly the bit about “The Apple Macintosh version, unfortunately…” The reason Eudora for Mac can only run on emulators is because 1) Apple transitioned from PowerPC processors to Intel, and eventually removed PowerPC compatibility entirely; 2) Eudora for Mac’s resources got clobbered, so it was impossible to compile it to run on an Intel Mac.
Except, 3) I, personally, managed to reconstruct those resources, and have a developer on call to reintegrate them into the source. Eos now targets Intel Macs running Mojave or older (it’s a Carbon app, going to Cocoa will be a pain).
Multiarch in this context means being able to use 32-but software in a 64-bit system.
For example if your installer is 32-bit but your app is 64-but, then it will fail to install in Wine on Haiku x86-64. If you also happen to use any 32-bit libraries, then your app will also not work in Wine on Haiku.
That part doesn’t make sense. Either an executable is built as 64bit and uses 64bit libraries, or it is 32bit and uses 32bit libraries, you can’t mix and match.
Anyway, the main hroblem wih Wine is not really “hybrid” support, it’s that Wine on Haiku is 64-bit only. So the 32bit version of Haiku gets nothing at all.
There are instances (most commonly games) wherein for backwards compatibility, multiarch is needed to run both 32-bit and 64-bit code on a 64-bit system. Wine without multiarch cannot run 32-bit apps on 64-bit systems, which often includes 64-bit apps with 32-bit installers. Windows app developers frequently do this, since they see no need to update installers for 64-bit due to Windows having multiarch support.
That would be quite a while still, i think. We still need to actually finisht he webkit2 port :g
Though, input would be valued. (And i Think for example BeMail could use this too)
I would prefer we (That is, pulkomandy and me, and others who develop on haikuwebkit) Add two apis for embeded webkit usage. One that is “this is a web application”, which includes network access and javascript. and a second api that gives you just html5+css. No network access, and no javascript (or only “opt-in” network access, as in “do you want to download these ressources?”)
It could also be possible to add a netsurf-backed implementation as a second option for the second case (to be installed by the user if wanted)
What do you mean by configuration profile?
I think stuff like loading ressources later after the user has acknowledged this does need a different api.
I would not want developers to accidentally use the full web view too, one option could be to have the application call a function to enable the network or javascript later on.
At least for javascript, enabling and disabling it should already be possible using BWebSettings (but I’m not sure if it works). Something similar can be done for the network, but you will quickly hit a problem if you completely disable network access in an email client: people will want network access, to load and display images. So a édisable all network access" wouldn’t quite work, and more complex rules are needed.
Sending the images in the email itself is possible and works fine.
The default should be to block all network access, only after a user request should this be allowed. Similar to how the iOS email client does it, which is displaying blank images and having a UI element above the mail that asks the user whether they would like to load images afterwards.
The main use of these inline images is tracking users, so we should definitely only load these on explicit request.
(Perhaps display a “load image…” ui element on the images themselves?)
But that’s not what people or companies sending emails do.
That’s completely different from “no network access at all”. So, yes, what we need is a way for the client app to decide if a request should be allowed or not. This can be by having a callback method in the api, that returns true by default to allow everything, but can be overriden to have more control.
Yes, render the pure html parts of the message, and block the network access, and allow the user to allow/approve the download of the networked content. Like in MS Outlook, for example, with a banner where one can click to download the images in the message.
