Re: [XaraXtreme-dev] Moving to Cairo (was Ping)

[Alex Bligh <alex@xxxxxxxxxxx>]

--On 21 February 2007 16:28 +0100 Alexander Kellett <lypanov@xxxxxxx> wrote:

> ah. that eases my mind, to be honest i was scared that we already  have a
> kind of fork and that the current source base is not moving all that fast
> because  the windows version is somehow dislocated from the oss version.

There is already a "fork" (if you like) between the closed-source version
Xara use for their commercial software at the moment, and the open-source
version. Both forks are maintained by Xara, and bug-fixes hit both trains.
The fork is there partly because the closed-source one contains third
party code they can't open source, but also because Xara and the other
developers have made huge changes in order to support wxWidgets and gcc.
That fork will always be there, though Xara have said in the past it
is there intend to use the wxWidgets version in their own code if this
proves possible.

When Xara do development, what they are /obliged/ to give back is
covered by the CA. What they actually give back appears as far as
I can tell to be in excess of this.

> maybe i just misunderstood you however. are you talking about  modifying
> the codebase to use more generic drawing primitives that fit with both
> apis as  opposed to making a new library which merely provides the cdraw
> api with a cairo backend?  that was my assumption, but i may have been
> wrong :)

I am proposing to modify the code base so it internally can either
call Cairo to draw, or to call GDraw, with the switch probably being
made at the GDrawContext level, or (possibly) through a derived
class of GRenderRegion though I expect because of the deep class hierarchy
there that the latter is going to be harder. As I understand what
Carl has done, he's produced a hacked up version of GDrawContext
(or XaDrawContext or whatever it is called today) which calls Cairo
not GDraw. This could just as easily be a separate class. And we can
tidy up the class interface to GDrawContext (rather than the CDraw
'C' API) so it makes fewer assumption about the underlying drawing
engine relatively easily, I think.

Alex