RE: [XaraXtreme-dev] Ping

["Charles Moir" <CharlesM@xxxxxxxx>]

> > Doesn't this imply that, over time, the "in the wild" binary would 
> > become obsolete and likely eventually fail to function as 
> the OS and 
> > related bits  advance?
> 
> CDraw doesn't talk the OS. I'm not sure it depends on any 
> library at all - I think it's static linked and doesn't 
> depend on any library at all.
> So it's pretty age proof.
> 
> Yes I agree it that *IF* Xara abandoned it (and I currently 
> have no reason to suspect they will/might), it would have 
> better support if the source were available (inevitably) - 
> for instance if Intel processors become obsolete, it could 
> only work under emulation. However, in practical terms it is 
> only a few thousand lines of code (see the presentation I 
> gave in Kent), and it's pretty easy to work out WHAT it's 
> meant to do (if not how it does it) from how it's called, and 
> though the API isn't the cleanest in the world, it is an API. 
> So potential developers have the assurance that if Xara never 
> released the code, Magix got bought by MS or other 
> pointy-horned events occurred, it would be quite possible 
> (not trivial, but possible) to convert it to use code from 
> another drawing engine - it might run slower, but it wouldn't 
> be wasted code. Note that I am not advocating people do this, 
> merely pointing out it's a "security blanket" for developers.

I agree and have even suggested before now that Xtreme should be using
Cairo because come the day it's hardware accelerated, then it will
(should) out-perform CDraw anyway. In fact there's nothing at all to
stop anyone adapting Xara to using Cairo right now (any more than there
is stopping Inkscape using it - they are in the same boat really).  I'm
sure Carl would certainly approve.

And everyone knows we can't take back the GPL code, so there's
everything people need to take Xtreme codebase and develop it, even in
the worst case scenario that Magix/Xara get bought by MS and stop
official support completely.  So the fact that it doesn't get that
support makes me feel that actually there are other reasons. Perhaps
there's simply not the developers out there or the will in the community
to give the project the support.

SVG is a good example. Everyone knows that our lack of SVG support
really hinders the usefulness of the product in Linux world. So why
doesn't someone do something about it - they would *really* be loved by
very large numbers of Linux users for doing this.  And it would
transform the usefulness of the product.  And to someone who knows about
SVG this isn't even that difficult - our filter system makes this as
easy as it can be (and this is fully documented).

Charles