RE: [XaraXtreme-dev] source?

["Paul F. Johnson" <paul@xxxxxxxxxxxxxxxxxxxxxx>]

Hi,

> We hope to start opening the source within a few weeks. Weʼre still
> very busy with aspects of the Xara Xtreme launch and we need to sort
> out quite a few things before we can start, such as license headers in
> the source files, build guide, basic documentation, etc. 

Licence headers into the source files is a straight forward enough task
which can be done with a simple bash script. Shouldn't take more than 10
minutes to trial. The build guide is more interesting (for me as a
developer).

I would presume that the rendering engine is so fast due to it being
heavily optimised, hand coded x86 assembler and that it is this which
will set the difference between the GPL and commercial version (the GPL
version getting a nice, but slower C or C++ implementation - it gives
the value added required for the Win32 people to want to fork out).
Given the history of Xara (and before that, CC) I wouldn't be surprised
in the least about the x86 assembler.

Now, to add some fun to this we have the problem of targeting. From my
development work on ARM, Linux x86 and x64 plus what I've picked up on
OS X, there are quite a few differences in what is required for x86 and
x64 as well as little and large endian systems. Is it safe to assume
that initially, x86 and OS X's current processor will be the target with
x64 coming later? Or is the code structured in such a way that it is
going to be independent of both endian and processor type?

The following is just some advice which can be safely ignored, shot at
or taken to bed, loved, cherished and given sexy nightwear for that
something special!

1. Aim to use the current version of wxWidgets. Support for 2.4 is
vanishing at a rapid rate.
2. Split the code into chunk types. For example, my special area is
optimisation and code re-use. I have very little knowledge of user
interfaces. This idea has been very well used by the OpenOffice team
which has sub-groups working on specific aspects. There is a problem
with this approach - getting it all together and making it work!
3. Create a users mailing list. It cuts down on the noise/sound ratio on
a developer list.
4. Decide on the code committing regime and stick to it. By that I mean
assign people who are trusted by Xara to oversea checkins etc.
5. To save on bandwidth, adopt cvs or svn for code control.
6. As with all volunteer projects, there will be those with no
programming experience, but are eager. Let them document. They feel
included and part of the process.

As I say, these have probably all been thought of, decided on and wotnot
- it's just from my experience in open source development, the
commercial world tends to break things when they move over. The paradigm
used in commercial existence doesn't fit, or work, in the land of the
GPL.

> To start with it will just be the source for the current viewer demo
> that weʼve made available on the xaraxtreme.org site. That will
> quickly be followed by other parts of the source being made available
> piece by piece so that it can be ported and incorporated into the main
> program.

What would be useful then would be notes in the code saying how and
where this tags in to the main code base and work to be done on it.

> Weʼll keep you updated with our progress and weʼll get you involved as
> soon as we can. 

I can't wait! 

> Thanks for your interest.

Can I just ask that people not post using HTML - it plays hell with my
spam filters (and the ones at work)

TTFN

Paul
-- 
"Duirt me leat go raibh me breoite." - T.M.