I'd suggest rebuilding the GUI in a multiple platform window system. Like
WxWidgets or similar. The differences between MFC and and, for instance,
the aforementioned WxWidgets are negligible. This would at least make the
GUI portable.
I'm new to this project, and having a non-workable application in the repo,
is giving me the creeps. Although, I appreciate the OP's thoughts about
having a plan before actually going to work.
What's scary is that I've only ever seen the application from a binary
install.
I was under the, apparently, wrong impression that there were more control
with the various management stuff. But I'm not scared. I'm sure someone
(matavka? Sorry for butchering your name, I'm on my cell)
I am not a C++ programmer, nor a project manager, but I have enough
experience to see this project spiraling into the dust. As several
people have said, it looks to be just a collection of random thoughts
about what needs to be done. There appears to be no big picture and
therefore no plan to get there. Without the big picture, some of the
tasks could end up being irrelevant or a waste of effort. And without
a plan, the number of people likely to back the Kickstarter is going
to be low.
As I see it, the phases in this project will include at least the
following:
1.
Get the Windows version working reliably to provide a platform for
testing future work. Do not add any new features.
2.
STOP ALL DEVELOPMENT! Put together a project team. Get a project
manager. Make a plan for what is to be done and a rough timeline.
This is important as without this there are unlikely to be many
volunteers to help. This needs to be done right at the beginning to
avoid the project getting a bad reputation.
3.
Put together a team with the required skills to implement the plan.
4.
Start working according to the plan.
Now the plan needs to identify what the final goal is, perhaps something
like:
To create an open source e-mail client based on Eudora that will run
on at least Linux, Mac, Windows.
One might also add which operating systems are going to be targeted,
eg, Windows XP and later, Mac OS X Snow Leopard and later, flavours
of Linux. This is important because different development software
and software libraries may be required to work with all those
operating systems.
It then needs to list all the major tasks that need to be done, and
to give them a priority. Dependencies need to be considered in
determining priority, eg, it is no good working on something that
cannot be tested until something else is finished.
Tasks then need to be allocated to developers or teams of developers.
This could be by people volunteering to do particular tasks, provided
that meets the priorities.
Estimates of the time needed for each task should be identified to
allow for organised allocation of work. If a task is going to take
six months, it needs to start earlier than one which will take one
month.
Regular monitoring of progress is needed, so that if one area is a
bit slow, additional resources can be directed that way.
Milestones will show that progress is being made.
Some major decisions are going to have to be made, particularly in
terms of supporting other platforms. It would be silly to implement
something that does not translate easily to another platform.
I'd suggest rebuilding the GUI in a multiple platform window system. Like
WxWidgets or similar. The differences between MFC and and, for instance,
the aforementioned WxWidgets are negligible. This would at least make the
GUI portable.
I'm new to this project, and having a non-workable application in the
repo, is giving me the creeps. Although, I appreciate the OP's thoughts
about having a plan before actually going to work.
What's scary is that I've only ever seen the application from a binary
install.
I was under the, apparently, wrong impression that there were more control
with the various management stuff. But I'm not scared. I'm sure someone
(matavka? Sorry for butchering your name, I'm on my cell)
I am not a C++ programmer, nor a project manager, but I have enough
experience to see this project spiraling into the dust. As several
people have said, it looks to be just a collection of random thoughts
about what needs to be done. There appears to be no big picture and
therefore no plan to get there. Without the big picture, some of the
tasks could end up being irrelevant or a waste of effort. And without
a plan, the number of people likely to back the Kickstarter is going
to be low.
As I see it, the phases in this project will include at least the
following:
1.
Get the Windows version working reliably to provide a platform for
testing future work. Do not add any new features.
2.
STOP ALL DEVELOPMENT! Put together a project team. Get a project
manager. Make a plan for what is to be done and a rough timeline.
This is important as without this there are unlikely to be many
volunteers to help. This needs to be done right at the beginning to
avoid the project getting a bad reputation.
3.
Put together a team with the required skills to implement the plan.
4.
Start working according to the plan.
Now the plan needs to identify what the final goal is, perhaps something
like:
To create an open source e-mail client based on Eudora that will run
on at least Linux, Mac, Windows.
One might also add which operating systems are going to be targeted,
eg, Windows XP and later, Mac OS X Snow Leopard and later, flavours
of Linux. This is important because different development software
and software libraries may be required to work with all those
operating systems.
It then needs to list all the major tasks that need to be done, and
to give them a priority. Dependencies need to be considered in
determining priority, eg, it is no good working on something that
cannot be tested until something else is finished.
Tasks then need to be allocated to developers or teams of developers.
This could be by people volunteering to do particular tasks, provided
that meets the priorities.
Estimates of the time needed for each task should be identified to
allow for organised allocation of work. If a task is going to take
six months, it needs to start earlier than one which will take one
month.
Regular monitoring of progress is needed, so that if one area is a
bit slow, additional resources can be directed that way.
Milestones will show that progress is being made.
Some major decisions are going to have to be made, particularly in
terms of supporting other platforms. It would be silly to implement
something that does not translate easily to another platform.
I was under the, apparently, wrong impression that there were more control
with the various management stuff. But I'm not scared. I'm sure someone
(matavka? Sorry for butchering your name, I'm on my cell)
No, you were under the right impression. The problem was that people don't see the project plan, so they think there isn't one. Now that I put most of the plan on the blog, and there's an older one on the discussion board, they won't have that excuse.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime, I've created and registered an IRC channel on FREENODE
called #hermesmail. We still need the last couple of steps to make it
official (a confirmation mail from a founder or old-timer), but who would
hijack our channel? A 12-year-old hacker with no friends and no bike?
I was under the, apparently, wrong impression that there were more
control with the various management stuff. But I'm not scared. I'm sure
someone (matavka? Sorry for butchering your name, I'm on my cell)
-
- No, you were under the right impression. The problem was that
people don't see the project plan, so they think there isn't one.
Now that I put most of the plan on the blog, and there's an older one on
the discussion board, they won't have that excuse.
If I didn't write this before I'm doing it again. Please add all files that
are part of the project and is legal to upload, to the repo. If some, for
any reason at all, are missing, we need a list of them.
For instance missing header "imap.h". Hasn't this functionality been built
into windows by now?
Ah, "imap.h" is another file that I rescued from the original code dump. If I remember correctly, it was originally part of the Hermes project but was merged into another header and then removed. The fact that this was done without changing the #include references to it is just another example of how bollixed up this project has become.
And, no, there is no IMAP functionality in Windows per se although there it does exist in .Net.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To all Hermes developers: If a module compiles successfully before you make changes to it, please, please make sure that it still compiles before you push those changes. If a module does not compile in the first place then I suggest that the wisest thing to do is to get it to compile cleanly before making any changes to it for other purposes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the same spirit, if you have files lying around (not talking about
"sect_attribs.h"), but files that really should be in the repository,
please add them. So we wont get (any more) nasty surprises.
To all Hermes developers: If a module compiles successfully before you
make changes to it, please, please make sure that it still compiles before
you push those changes. If a module does not compile in the first place
then I suggest that the wisest thing to do is to get it to compile cleanly
before making any changes to it for other purposes.
(AFK)
Ok. Done. All wise words.
I'd suggest rebuilding the GUI in a multiple platform window system. Like
WxWidgets or similar. The differences between MFC and and, for instance,
the aforementioned WxWidgets are negligible. This would at least make the
GUI portable.
I'm new to this project, and having a non-workable application in the repo,
is giving me the creeps. Although, I appreciate the OP's thoughts about
having a plan before actually going to work.
What's scary is that I've only ever seen the application from a binary
install.
I was under the, apparently, wrong impression that there were more control
with the various management stuff. But I'm not scared. I'm sure someone
(matavka? Sorry for butchering your name, I'm on my cell)
Regards
On Monday, September 10, 2018, David Morrison davidmorr@users.sourceforge.net wrote:
--
Søren Bro Thygesen
(AFK)
Sorry. What I meant was that I'm sure someone will rise to the task.
Regards
On Monday, September 10, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
I was under the, apparently, wrong impression that there were more control
with the various management stuff. But I'm not scared. I'm sure someone
(matavka? Sorry for butchering your name, I'm on my cell)
That sounds reassuring.
In the meantime, I've created and registered an IRC channel on FREENODE
called #hermesmail. We still need the last couple of steps to make it
official (a confirmation mail from a founder or old-timer), but who would
hijack our channel? A 12-year-old hacker with no friends and no bike?
Regards.
On Mon, Sep 10, 2018 at 6:55 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
If I didn't write this before I'm doing it again. Please add all files that
are part of the project and is legal to upload, to the repo. If some, for
any reason at all, are missing, we need a list of them.
For instance missing header "imap.h". Hasn't this functionality been built
into windows by now?
Regards.
Ah, "imap.h" is another file that I rescued from the original code dump. If I remember correctly, it was originally part of the Hermes project but was merged into another header and then removed. The fact that this was done without changing the #include references to it is just another example of how bollixed up this project has become.
And, no, there is no IMAP functionality in Windows per se although there it does exist in .Net.
To all Hermes developers: If a module compiles successfully before you make changes to it, please, please make sure that it still compiles before you push those changes. If a module does not compile in the first place then I suggest that the wisest thing to do is to get it to compile cleanly before making any changes to it for other purposes.
In the same spirit, if you have files lying around (not talking about
"sect_attribs.h"), but files that really should be in the repository,
please add them. So we wont get (any more) nasty surprises.
Regards.
On Monday, September 10, 2018, Pete Maclean petemaclean@users.sourceforge.net wrote:
As you may have noticed, I have already added DebugNewHelpers.h. I believe that is the only missing one that I have.