[Project_owners] Aphrodite

John Dobbins 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.

John Dobbins

More information about the Project_owners mailing list