john at brandxcomputers.com
Wed Apr 6 08:52:22 EDT 2005
I have been giving some thought to what direction Aphrodite should take,
and I'd like to get some input from other project owners on the subject.
Frist of all, Aphrodite's problems.
When it was originally in development the darn thing was broke more
often than it worked. This was largely due to it relying on Mozilla
being installed. The rapid changes in Mozilla constantly broke
Aphrodite, and more time was spent trying to fix things that suddenly
broke than was spent actually developing the browser. This problem is
largely a thing of the past.
The second problem was strange things could happen if someone installed
it with a non-standard build of Mozilla. Even something as simple as
switching the theme in Mozilla would carry elements into Aphrodite that
screwed up it's look, and the move from the original Modern theme at
Mozilla insured that any theme would cause problems. This problem would
remain in the form of trying to ensure that Aphrodite would work with
the most popular Moz-dev projects, but wouldn't have major problems if
they weren't present.
Releasing Aphrodite as a stand alone browser would solve the problem of
strange reactions to a non-standard Mozilla setup, but all that would
accomplish is reinventing the Firefox wheel, and it would lose all the
advantages of reacting with a suite.
Because of this I think the best way to handle Aphrodite would be as a
set of patches that can be applied to the Mozilla code to create an
Aphrodite Branded Suite that targets the power user. This would include
the items currently in the suite along with an Aphrodite enhanced
browser rather than the Navigator that is currently in the Suite. It
would also include the Calendar by default, along with selected Moz-dev
projects. One comprehensive bundle.
In addition to this it would serve as a testbed for code and concepts
that could be passed to the regular suite if they wish to include them.
One example of a concept that I'm thinking of is a change in how themes
are handled. Right now they are in one jar such as classic.jar. I'd like
to try splitting it into two files, one would be called platform.jar and
would contain much of the code that now is in the global directory of
the classic theme, the parts that set it up to look like Windows, Mac,
or Unix. Each platform would then have it's own native look file set
that would work with the remainder of the code in a theme. The advantage
to this approach would a single theme would look correct on all three
platforms instead of either having it look correct on just one of them ,
or having to develop three versions of the theme.
More information about the Project_owners