I'm new to this project, and also in setting up Microsoft help files. But
there's a directory called "Help", containing a file called "Eudora.hhk".
This file looks like an obvious candidate but I'm not sure the answer is to
edit this file directly. Maybe some of the more experienced developers
versed in Microsoft help would lend a pointer.
I'm the resident MS Help person, so I'll try to explain that as well as the other parts of the i18n and l19n process. First of all, MS Help is all in (X)HTML, so it can be edited with any HTML editor (I suggest Nvu or Spacemacs). I'd ask you to leave compiling to me, because I actually compile it as two different formats (CHM for Windows XP/7, and MSHC for Win 8/10).
Second: it's more important, in my opinion, to localise the actual strings in the resource files. I'll have a look for what exactly needs to be localised to-morrow and I'll drop you a line (I'm off my meds for to-day and my pain is making it difficult to focus)
Third: the latest versions of so-called ancillary files (documentation both for devs and users, help files, even some deleted code) is in a project called hermesancil. Google it and you'll find it. That's partly why I haven't been checking code in here; I've been working on the ancillary files. If you want to localise the help, be my guest - hermesancil has all the files you'll need.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm the resident MS Help person, so I'll try to explain that as well as
the other parts of the i18n and l19n process. First of all, MS Help is all
in (X)HTML, so it can be edited with any HTML editor (I suggest Nvu or
Spacemacs). I'd ask you to leave compiling to me, because I actually
compile it as two different formats (CHM for Windows XP/7, and MSHC for Win
8/10).
Second: it's more important, in my opinion, to localise the actual strings
in the resource files. I'll have a look for what exactly needs to be
localised to-morrow and I'll drop you a line (I'm off my meds for to-day
and my pain is making it difficult to focus)
Third: the latest versions of so-called ancillary files (documentation
both for devs and users, help files, even some deleted code) is in a
project called hermesancil. Google it and you'll find it. That's partly why
I haven't been checking code in here; I've been working on the ancillary
files. If you want to localise the help, be my guest - hermesancil has all
the files you'll need.
So basically, users should just translate the hhkhhk file?
Regards
On Tuesday, September 4, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
I'm the resident MS Help person, so I'll try to explain that as well as
the other parts of the i18n and l19n process. First of all, MS Help is all
in (X)HTML, so it can be edited with any HTML editor (I suggest Nvu or
Spacemacs). I'd ask you to leave compiling to me, because I actually
compile it as two different formats (CHM for Windows XP/7, and MSHC for Win
8/10).
Second: it's more important, in my opinion, to localise the actual strings
in the resource files. I'll have a look for what exactly needs to be
localised to-morrow and I'll drop you a line (I'm off my meds for to-day
and my pain is making it difficult to focus)
Third: the latest versions of so-called ancillary files (documentation
both for devs and users, help files, even some deleted code) is in a
project called hermesancil. Google it and you'll find it. That's partly why
I haven't been checking code in here; I've been working on the ancillary
files. If you want to localise the help, be my guest - hermesancil has all
the files you'll need.
Not the hhk file. Clone the hermesancil repository (Google it) and navigate to Help/newhelp8/_helpsource/html. You will find the HTML Help source there. Use an HTML editor to localise/edit it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. But the language thing is really a task for the actual users of the
program. I'm not omnilingual :) But yeah, I can put together a help file
for ordinary users to read and understand. There was already one person
interested. As you may have noticed.
I signed up because I miss coding for Windows. I'm already helping out with
a Linux project but it moves at a leisurely pace. The head of that project
doesn't move a comma without documenting it. Not a bad thing, to be sure,
but I think he's overdoing it a little. He's also 70 and a professor
emeritus, so that may explain a few things. :)
Not the hhk file. Clone the hermesancil repository (Google it) and
navigate to Help/newhelp8/_helpsource/html. You will find the HTML Help
source there. Use an HTML editor to localise/edit it.
Now that I'm properly medicated for pain, and per Pete Maclean's request, here is a project roadmap, to be allocated according to your abilities and best judgement.
QCSSL
Our top priority right now is to compile QCSSL.dll statically linked to modern OpenSSL. Eudora is still serviceable as an eMail client, but has trouble validating certificates. The reason is that both its rootcert store and its SSL package are heavily outdated. While I was able to create a new rootcert store (it's in the Hermes files section), I need someone else to do QCSSL, so I can distribute it to the Eudora community. It will be a drop-in replacement (i.e. navigate to Program Files/Eudora, delete qcssl.dll, and put in our new version).
I can not emphasise this fact enough: distributing this file is crucial. Six weeks have passed on this project, with no binaries to show except for the rootcerts. The community is at risk of dismissing our hard work as vapourware, and if people form such an opinion, I'll have trouble disabusing them of the notion.
(Update: It appears that Maclean has compiled a preliminary release of this, but forgot to attach it in his eMail to me. It IS a preliminary release, though, so if you could look through and perhaps test it, that'd be great)
Stingray
As I have already mentioned, Eudora 7.1 is built with an old version of the Stingray Objective Toolkit that has been modified by Qualcomm. While I do have access to a version of OT that's "close enough for government work", and I can legally supply it to you, we should be aiming to replace it with a native toolkit (for Windows, this will of course be the Microsoft Foundation Classes).
There are two reasons for this. First, native toolkits have advanced enough that there is no technical justification to use OT instead (especially an old version). Second, while I do have a limited licence to use OT so that Hermes may be compiled, it is not Open Source and we should really be migrating to fully Open Source before we go gold. (FYI: I looked at buying a new version of Stingray but I was not impressed with the features, especially not for the price of €3700!)
HTML Rendering
Eudora came with two HTML renderers. The first is DataPak Paige. While Prickett originally wrote in the blog that he would remove it, we subsequently agreed that this would not be the case, because Paige is a nice, lightweight renderer and it is above all secure. There was talk of "upgrading" it from C to C++; I'll leave that to your judgement, as long as it works.
The second renderer was MSHTML, also known as Trident. This is where our problems lie. Trident is the rendering engine included with Internet Explorer—not Edge, Internet bloody Explorer—a poor excuse for a Web browser that, in addition to its legion of other problems, has been deprecated by its authors. Its continuing use in Hermes is fraught with problems; just for an example, it's entirely possible to craft an eMail message that, when previewed in Trident, will open its attachment automatically. The decision has therefore been made to replace it with the Gecko renderer from Firefox/Thunderbird. I don't know what kind of work has been done in re: actually replacing it, but it is certainly a priority to do so.
Build Hermes
Self-explanatory. We need to release a version of Hermes that one can download and install on his computer. It would be nice to have the features listed below before we release, but only if we can do it in good time.
Installer
Allied to the above agendum is the fact that Eudora 7.1 installs using InstallShield. This is a proprietary package and we certainly can't use it for when we release. We must therefore convert the InstallShield script to NSIS. I'd do it myself, but I have to have a compiled version of Hermes first.
The reason I need the compiled version is that Eudora 7.1 had a lot of user-tracking code in all sorts of places (registration, ad server, Lite Mode, Sponsored Mode, Full Mode); thanks to Prickett and Maclean, this has been removed, but until I see a directory listing of the compiled software, I don't know what lines to remove from the InstallShield script.
Spell Check
The spell checker included with Eudora is an old version of Wintergreen Sentry. Much the same justifications apply here as in the case of Qualcomm Stingray (with the one difference that we have the right to distribute the source of the version included with Eudora)... plus one more issue, which gives me conniption fits. I have no idea how the dictionary files are compiled, which means that I can not edit the dictionary for any of the languages already supported, nor can I create new dictionaries.
I propose replacing Sentry with either hunspell or nuspell. These are Open Source packages under active development, used by numerous other projects. I have discussed this with Prickett and we have decided to move forward with this plan; I'll copy you on his implementation details so you can work in tandem (briefly, he proposes writing a class that's configurable for multiple spell checkers).
Unsolicited Mail Filtering
The "junk" mail filter included with Eudora is simplistic to say the least, and that whirring sound you hear is that of Tom Bayes rolling over in his grave. We should be replacing Eudora's junk filter with a Bayesian alternative. Our two choices, as far as I can ascertain, are Spam ButtButtin and Bogofilter. I have no preference between the two, but whichever one we choose, we'll have to integrate it seamlessly, so it's part of the project and not a clumsy bolt-on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that I'm properly medicated for pain, and per Pete Maclean's request,
here is a project roadmap, to be allocated according to your abilities and
best judgement.
QCSSL
Our top priority right now is to compile QCSSL.dll statically linked to
modern OpenSSL. Eudora is still serviceable as an eMail client, but has
trouble validating certificates. The reason is that both its rootcert store
and its SSL package are heavily outdated. While I was able to create a new
rootcert store (it's in the Hermes files section), I need someone else to
do QCSSL, so I can distribute it to the Eudora community. It will be a
drop-in replacement (i.e. navigate to Program Files/Eudora, delete
qcssl.dll, and put in our new version).
I can not emphasise this fact enough: distributing this file is crucial.
Six weeks have passed on this project, with no binaries to show except for
the rootcerts. The community is at risk of dismissing our hard work as
vapourware, and if people form such an opinion, I'll have trouble
disabusing them of the notion.
(Update: It appears that Maclean has compiled a preliminary release of
this, but forgot to attach it in his eMail to me. It IS a preliminary
release, though, so if you could look through and perhaps test it, that'd
be great)
Stingray
As I have already mentioned, Eudora 7.1 is built with an old version of
the Stingray Objective Toolkit that has been modified by Qualcomm. While I
do have access to a version of OT that's "close enough for government
work", and I can legally supply it to you, we should be aiming to replace
it with a native toolkit (for Windows, this will of course be the Microsoft
Foundation Classes).
There are two reasons for this. First, native toolkits have advanced
enough that there is no technical justification to use OT instead
(especially an old version). Second, while I do have a limited licence to
use OT so that Hermes may be compiled, it is not Open Source and we should
really be migrating to fully Open Source before we go gold. (FYI: I looked
at buying a new version of Stingray but I was not impressed with the
features, especially not for the price of €3700!)
HTML Rendering
Eudora came with two HTML renderers. The first is DataPak Paige. While
Prickett originally wrote in the blog that he would remove it, we
subsequently agreed that this would not be the case, because Paige is a
nice, lightweight renderer and it is above all secure. There was talk of
"upgrading" it from C to C++; I'll leave that to your judgement, as long as
it works.
The second renderer was MSHTML, also known as Trident. This is where our
problems lie. Trident is the rendering engine included with Internet
Explorer—not Edge, Internet bloody Explorer—a poor excuse for a Web
browser that, in addition to its legion of other problems, has been
deprecated by its authors. Its continuing use in Hermes is fraught with
problems; just for an example, it's entirely possible to craft an eMail
message that, when previewed in Trident, will open its attachment automatically. The decision has therefore been made to replace it with
the Gecko renderer from Firefox/Thunderbird. I don't know what kind of work
has been done in re: actually replacing it, but it is certainly a priority
to do so.
Build Hermes
Self-explanatory. We need to release a version of Hermes that one can
download and install on his computer. It would be nice to have the features
listed below before we release, but only if we can do it in good time.
Installer
Allied to the above agendum is the fact that Eudora 7.1 installs using
InstallShield. This is a proprietary package and we certainly can't use it
for when we release. We must therefore convert the InstallShield script to
NSIS. I'd do it myself, but I have to have a compiled version of Hermes
first.
The reason I need the compiled version is that Eudora 7.1 had a lot of
user-tracking code in all sorts of places (registration, ad server, Lite
Mode, Sponsored Mode, Full Mode); thanks to Prickett and Maclean, this has
been removed, but until I see a directory listing of the compiled software,
I don't know what lines to remove from the InstallShield script.
Spell Check
The spell checker included with Eudora is an old version of Wintergreen
Sentry. Much the same justifications apply here as in the case of Qualcomm
Stingray (with the one difference that we have the right to distribute the
source of the version included with Eudora)... plus one more issue,
which gives me conniption fits. I have no idea how the dictionary files
are compiled, which means that I can not edit the dictionary for any of the
languages already supported, nor can I create new dictionaries.
I propose replacing Sentry with either hunspell or nuspell. These are Open
Source packages under active development, used by numerous other projects.
I have discussed this with Prickett and we have decided to move forward
with this plan; I'll copy you on his implementation details so you can work
in tandem (briefly, he proposes writing a class that's configurable for
multiple spell checkers).
Unsolicited Mail Filtering
The "junk" mail filter included with Eudora is simplistic to say the
least, and that whirring sound you hear is that of Tom Bayes rolling over
in his grave. We should be replacing Eudora's junk filter with a Bayesian
alternative. Our two choices, as far as I can ascertain, are Spam
ButtButtin and Bogofilter. I have no preference between the two, but
whichever one we choose, we'll have to integrate it seamlessly, so it's
part of the project and not a clumsy bolt-on.
Until I can help with the actual code, maybe I can put together some kind
of document that the normal users can follow to localise the program to
their language.
If you're the Resident MS Help person, maybe you can tell me if my
suspicion is correct that the localised help files, after compilation, can
be tagged on to installed versions?
I'm the resident MS Help person, so I'll try to explain that as well as
the other parts of the i18n and l19n process. First of all, MS Help is all
in (X)HTML, so it can be edited with any HTML editor (I suggest Nvu or
Spacemacs). I'd ask you to leave compiling to me, because I actually
compile it as two different formats (CHM for Windows XP/7, and MSHC for Win
8/10).
Second: it's more important, in my opinion, to localise the actual strings
in the resource files. I'll have a look for what exactly needs to be
localised to-morrow and I'll drop you a line (I'm off my meds for to-day
and my pain is making it difficult to focus)
Third: the latest versions of so-called ancillary files (documentation
both for devs and users, help files, even some deleted code) is in a
project called hermesancil. Google it and you'll find it. That's partly why
I haven't been checking code in here; I've been working on the ancillary
files. If you want to localise the help, be my guest - hermesancil has all
the files you'll need.
Yes, indeed. The help files are compiled into a .chm file for old versions of Win, and .mshc for newer versions. It's a simple matter of generating new installers for every language, as and when they become available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I have a pretty good grasp of Mercurial by now, thanks to Pete. He
may have he's own problems with it it, but I just need the final "hg push"
to work and the error I get is HTTP 403 Permission denied. So. either I'm
using the wrong password, or some settings are wrong at "your" end.
Yes, indeed. The help files are compiled into a .chm file for old versions
of Win, and .mshc for newer versions. It's a simple matter of generating
new installers for every language, as and when they become available.
As I wrote to Pete: I have never had so much difficulty with a source
system, OK, we found out that one was a wrong configuration at "your" end.
That brought me further one. But this last one...?
I think I have a pretty good grasp of Mercurial by now, thanks to Pete. He
may have he's own problems with it it, but I just need the final "hg push"
to work and the error I get is HTTP 403 Permission denied. So. either I'm
using the wrong password, or some settings are wrong at "your" end.
Yes, indeed. The help files are compiled into a .chm file for old
versions of Win, and .mshc for newer versions. It's a simple matter of
generating new installers for every language, as and when they become
available.
I suspect it has to do with my password. Can you set one manually in my
user profile?Or do I need to that myself.? m slowly moving towards
passwordless SSH login. But it really shouldn't ne necessary....
As I wrote to Pete: I have never had so much difficulty with a source
system, OK, we found out that one was a wrong configuration at "your" end.
That brought me further one. But this last one...?
I think I have a pretty good grasp of Mercurial by now, thanks to Pete.
He may have he's own problems with it it, but I just need the final "hg
push" to work and the error I get is HTTP 403 Permission denied. So. either
I'm using the wrong password, or some settings are wrong at "your" end.
Yes, indeed. The help files are compiled into a .chm file for old
versions of Win, and .mshc for newer versions. It's a simple matter of
generating new installers for every language, as and when they become
available.
Update: you'll find the files to localise by searching for ".rc" (all files ending in extension .rc). You can localise anything that's identifiably English in those files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: you'll find the files to localise by searching for ".rc" (all files ending in extension .rc). You can localise anything that's identifiably English in those files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a suspicion that the reason it doesn\t work is that Im not logged
in under my real name. Ill try with another laptop. This one doesn't accept
the Mercurial.ini file. Obviously, I want to use my own name.
You definitely didn't go over the line. If I couldn't laugh at my pain,
I'd have to cry about it, and big boys don't cry ;)
By the way, it's multiple conditions: scoliosis (twisted spine) so severe
as to occasion a visible pelvic tilt/one leg shorter than the other,
reconstructive surgery to the left foot, and thanks to a bad driver, the
bones in my left lower leg were reduced to the consistency of coffee
grounds (they were pulled out and replaced with a titanium prosthetic).
So if you happen to have some Sevredol laying around, I just might take
you up on that offer :D
I'm slowly going bersærk here just trying to commit a single file. Do I
need to use my username (and password?) for every commit? I downloaded a
GUI client but that just kinda made things worse. If I can't even commit a
single file I'll sink into madness…
I'm slowly going bersærk here just trying to commit a single file. Do I
need to use my username (and password?) for every commit? I downloaded a
GUI client but that just kinda made things worse. If I can't even commit a
single file I'll sink into madness…
On Tue, Sep 4, 2018 at 6:35 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
OK..At least now when I do a commit I get a notepad asking me to write a
line. But what to do with this notepad file I have no idea. I've tried just
closing it and I've tried saving it. Still no result.
Ok. I've tried creating a directory, running "hg init" and "hg cloning" the
code into it. I've tried "hg cloning" the code and then "hg init".
Nothing really works. I get the code, yes, but I can't do a simple commit.
"hg diff" doesn't show any changes when I've made one.
Should I perhaps "hg pull" the code instead of cloning it? Is that it?
I must be doing something wrong. That's for sure. What do you guys do?
Regards
On Wednesday, September 5, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
I'm slowly going bersærk here just trying to commit a single file. Do I
need to use my username (and password?) for every commit? I downloaded a
GUI client but that just kinda made things worse. If I can't even commit a
single file I'll sink into madness…
On Tue, Sep 4, 2018 at 6:35 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
You add your commit message (what you did), save it, and quit. Here's how: https://www.mercurial-scm.org/wiki/Tutorial Also, you need to hg push after you hg commit. hg commit merely saves the changes into Mercurial's "journal".
Last edit: Ted Matavka 2018-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the help of Pete Mclean I've reached the point where all the only thing that doesn't succeed is the final push command. Although it says it want's me to use my sourceforge password, (I'm sure I do. I logged in and out of Sourceforge several times to verify.) It fails with a
403: HTML Forbidden error.
So it must still be a case of permission. Does anyone have a suggestion? Am I really using the correct password? Is my account on the project set up correctly?
TIA,
Soren
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe that .hhk files are intermediate files created by "Microsoft HTML
Help" (see https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help).
https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help).%A0While
still available, I think this program is too limited for our purposes.
That said, I do not have an immediate suggestion for a better one. The one
I use in my business is a commercial product so probably not a good choice
for an open-source project.
At 06:13 PM 8/25/2018, Soren Bro wrote:
I'm new to this project, and also in setting up Microsoft help files. But
there's a directory called "Help", containing a file called "Eudora.hhk".
This file looks like an obvious candidate but I'm not sure the answer is to
edit this file directly. Maybe some of the more experienced developers
versed in Microsoft help would lend a pointer.
Regards
On Sat, Aug 25, 2018 at 11:06 PM Soren Bro sbrothy@users.sourceforge.net
wrote: I'' gladly help with Danish. Probably not as pressing. I'll try to
locate the relevant files too.
Localization
https://sourceforge.net/p/hermesmail/discussion/general/thread/1bb77547/?limit=25#ed76
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/hermesmail/discussion/general/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
Localization
https://sourceforge.net/p/hermesmail/discussion/general/thread/1bb77547/?limit=25#ed76/433b
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/hermesmail/discussion/general/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
I suspect these projects are loadable in VS, but I'm far from sure.
Regards.
No I seem to be wrong. You need the correct program.
On Thu, Aug 30, 2018 at 6:23 PM sbrothy@gmail.com wrote:
I'm the resident MS Help person, so I'll try to explain that as well as the other parts of the i18n and l19n process. First of all, MS Help is all in (X)HTML, so it can be edited with any HTML editor (I suggest Nvu or Spacemacs). I'd ask you to leave compiling to me, because I actually compile it as two different formats (CHM for Windows XP/7, and MSHC for Win 8/10).
Second: it's more important, in my opinion, to localise the actual strings in the resource files. I'll have a look for what exactly needs to be localised to-morrow and I'll drop you a line (I'm off my meds for to-day and my pain is making it difficult to focus)
Third: the latest versions of so-called ancillary files (documentation both for devs and users, help files, even some deleted code) is in a project called hermesancil. Google it and you'll find it. That's partly why I haven't been checking code in here; I've been working on the ancillary files. If you want to localise the help, be my guest - hermesancil has all the files you'll need.
Oh you meant compilation of the help files!
So basically, users should just translate the hhkhhk file?
Regards
On Tuesday, September 4, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
hhk file. Dunno what went wrong there....
On Tuesday, September 4, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
Not the hhk file. Clone the hermesancil repository (Google it) and navigate to Help/newhelp8/_helpsource/html. You will find the HTML Help source there. Use an HTML editor to localise/edit it.
Ok. But the language thing is really a task for the actual users of the
program. I'm not omnilingual :) But yeah, I can put together a help file
for ordinary users to read and understand. There was already one person
interested. As you may have noticed.
I signed up because I miss coding for Windows. I'm already helping out with
a Linux project but it moves at a leisurely pace. The head of that project
doesn't move a comma without documenting it. Not a bad thing, to be sure,
but I think he's overdoing it a little. He's also 70 and a professor
emeritus, so that may explain a few things. :)
Regards
On Tuesday, September 4, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
Now that I'm properly medicated for pain, and per Pete Maclean's request, here is a project roadmap, to be allocated according to your abilities and best judgement.
QCSSL
Our top priority right now is to compile QCSSL.dll statically linked to modern OpenSSL. Eudora is still serviceable as an eMail client, but has trouble validating certificates. The reason is that both its rootcert store and its SSL package are heavily outdated. While I was able to create a new rootcert store (it's in the Hermes files section), I need someone else to do QCSSL, so I can distribute it to the Eudora community. It will be a drop-in replacement (i.e. navigate to Program Files/Eudora, delete qcssl.dll, and put in our new version).
I can not emphasise this fact enough: distributing this file is crucial. Six weeks have passed on this project, with no binaries to show except for the rootcerts. The community is at risk of dismissing our hard work as vapourware, and if people form such an opinion, I'll have trouble disabusing them of the notion.
(Update: It appears that Maclean has compiled a preliminary release of this, but forgot to attach it in his eMail to me. It IS a preliminary release, though, so if you could look through and perhaps test it, that'd be great)
Stingray
As I have already mentioned, Eudora 7.1 is built with an old version of the Stingray Objective Toolkit that has been modified by Qualcomm. While I do have access to a version of OT that's "close enough for government work", and I can legally supply it to you, we should be aiming to replace it with a native toolkit (for Windows, this will of course be the Microsoft Foundation Classes).
There are two reasons for this. First, native toolkits have advanced enough that there is no technical justification to use OT instead (especially an old version). Second, while I do have a limited licence to use OT so that Hermes may be compiled, it is not Open Source and we should really be migrating to fully Open Source before we go gold. (FYI: I looked at buying a new version of Stingray but I was not impressed with the features, especially not for the price of €3700!)
HTML Rendering
Eudora came with two HTML renderers. The first is DataPak Paige. While Prickett originally wrote in the blog that he would remove it, we subsequently agreed that this would not be the case, because Paige is a nice, lightweight renderer and it is above all secure. There was talk of "upgrading" it from C to C++; I'll leave that to your judgement, as long as it works.
The second renderer was MSHTML, also known as Trident. This is where our problems lie. Trident is the rendering engine included with Internet Explorer—not Edge, Internet bloody Explorer—a poor excuse for a Web browser that, in addition to its legion of other problems, has been deprecated by its authors. Its continuing use in Hermes is fraught with problems; just for an example, it's entirely possible to craft an eMail message that, when previewed in Trident, will open its attachment automatically. The decision has therefore been made to replace it with the Gecko renderer from Firefox/Thunderbird. I don't know what kind of work has been done in re: actually replacing it, but it is certainly a priority to do so.
Build Hermes
Self-explanatory. We need to release a version of Hermes that one can download and install on his computer. It would be nice to have the features listed below before we release, but only if we can do it in good time.
Installer
Allied to the above agendum is the fact that Eudora 7.1 installs using InstallShield. This is a proprietary package and we certainly can't use it for when we release. We must therefore convert the InstallShield script to NSIS. I'd do it myself, but I have to have a compiled version of Hermes first.
The reason I need the compiled version is that Eudora 7.1 had a lot of user-tracking code in all sorts of places (registration, ad server, Lite Mode, Sponsored Mode, Full Mode); thanks to Prickett and Maclean, this has been removed, but until I see a directory listing of the compiled software, I don't know what lines to remove from the InstallShield script.
Spell Check
The spell checker included with Eudora is an old version of Wintergreen Sentry. Much the same justifications apply here as in the case of Qualcomm Stingray (with the one difference that we have the right to distribute the source of the version included with Eudora)... plus one more issue, which gives me conniption fits. I have no idea how the dictionary files are compiled, which means that I can not edit the dictionary for any of the languages already supported, nor can I create new dictionaries.
I propose replacing Sentry with either hunspell or nuspell. These are Open Source packages under active development, used by numerous other projects. I have discussed this with Prickett and we have decided to move forward with this plan; I'll copy you on his implementation details so you can work in tandem (briefly, he proposes writing a class that's configurable for multiple spell checkers).
Unsolicited Mail Filtering
The "junk" mail filter included with Eudora is simplistic to say the least, and that whirring sound you hear is that of Tom Bayes rolling over in his grave. We should be replacing Eudora's junk filter with a Bayesian alternative. Our two choices, as far as I can ascertain, are Spam ButtButtin and Bogofilter. I have no preference between the two, but whichever one we choose, we'll have to integrate it seamlessly, so it's part of the project and not a clumsy bolt-on.
Invaluable! [private content deleted.]
Regards.
On Tue, Sep 4, 2018 at 5:36 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
Last edit: Ted Matavka 2018-09-04
Until I can help with the actual code, maybe I can put together some kind
of document that the normal users can follow to localise the program to
their language.
If you're the Resident MS Help person, maybe you can tell me if my
suspicion is correct that the localised help files, after compilation, can
be tagged on to installed versions?
Regards.
On Tue, Sep 4, 2018 at 12:11 AM Ted Matavka nmatavka@users.sourceforge.net
wrote:
Yes, indeed. The help files are compiled into a .chm file for old versions of Win, and .mshc for newer versions. It's a simple matter of generating new installers for every language, as and when they become available.
I think I have a pretty good grasp of Mercurial by now, thanks to Pete. He
may have he's own problems with it it, but I just need the final "hg push"
to work and the error I get is HTTP 403 Permission denied. So. either I'm
using the wrong password, or some settings are wrong at "your" end.
Regards.
On Thu, Sep 6, 2018 at 2:48 AM Ted Matavka nmatavka@users.sourceforge.net
wrote:
As I wrote to Pete: I have never had so much difficulty with a source
system, OK, we found out that one was a wrong configuration at "your" end.
That brought me further one. But this last one...?
Regards.
On Thu, Sep 6, 2018 at 11:59 PM sbrothy@gmail.com wrote:
I suspect it has to do with my password. Can you set one manually in my
user profile?Or do I need to that myself.? m slowly moving towards
passwordless SSH login. But it really shouldn't ne necessary....
Regards.
On Fri, Sep 7, 2018 at 12:01 AM sbrothy@gmail.com wrote:
Update: you'll find the files to localise by searching for ".rc" (all files ending in extension .rc). You can localise anything that's identifiably English in those files.
Update: you'll find the files to localise by searching for ".rc" (all files ending in extension .rc). You can localise anything that's identifiably English in those files.
I have a suspicion that the reason it doesn\t work is that Im not logged
in under my real name. Ill try with another laptop. This one doesn't accept
the Mercurial.ini file. Obviously, I want to use my own name.
Regards.
On Tue, Sep 4, 2018 at 6:16 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
"too" dammit. hate it when I ef up!
Regards
I'm slowly going bersærk here just trying to commit a single file. Do I
need to use my username (and password?) for every commit? I downloaded a
GUI client but that just kinda made things worse. If I can't even commit a
single file I'll sink into madness…
On Tue, Sep 4, 2018 at 6:35 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Ok. I've tried creating a directory, running "hg init" and "hg cloning" the
code into it. I've tried "hg cloning" the code and then "hg init".
Nothing really works. I get the code, yes, but I can't do a simple commit.
"hg diff" doesn't show any changes when I've made one.
Should I perhaps "hg pull" the code instead of cloning it? Is that it?
I must be doing something wrong. That's for sure. What do you guys do?
Regards
On Wednesday, September 5, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
OK..At least now when I do a commit I get a notepad asking me to write a
line. But what to do with this notepad file I have no idea. I've tried just
closing it and I've tried saving it. Still no result.
This is slowly driving me up the wall....
Regards.
On Wed, Sep 5, 2018 at 11:29 AM Soren Bro sbrothy@users.sourceforge.net
wrote:
You add your commit message (what you did), save it, and quit. Here's how: https://www.mercurial-scm.org/wiki/Tutorial Also, you need to hg push after you hg commit. hg commit merely saves the changes into Mercurial's "journal".
Last edit: Ted Matavka 2018-09-06
With the help of Pete Mclean I've reached the point where all the only thing that doesn't succeed is the final push command. Although it says it want's me to use my sourceforge password, (I'm sure I do. I logged in and out of Sourceforge several times to verify.) It fails with a
403: HTML Forbidden error.
So it must still be a case of permission. Does anyone have a suggestion? Am I really using the correct password? Is my account on the project set up correctly?
TIA,
Soren
Try hg push ssh:// instead of http://. HTTP mercurial access is read-only.