On Tue, Mar 15, 2011 at 2:50 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
> -----Original Message-----
> From: Jon Cruz [mailto:jon@...18...]
> Sent: dinsdag 15 maart 2011 21:26
>
> On Mar 15, 2011, at 12:30 PM, Josh Andler wrote:
>
> > Hey,
> >
> > So, I really think that we should entertain the idea of
> merging the cairo branch into trunk. The plan has been for us to not
> release 0.49 until it is ready, so the couple outstanding bugs in
> cairo shouldn't be a huge deterrent. We could also set up a PPA to
> produce the trunk builds of cairo & pixman so that fixed libs are
> easily installable in the meantime (at least for people using
> debian-based systems). I was talking to John Cliff and he put forth a
> very good point which is that we really need to get as much testing as
> possible on it prior to a release.
>
> > Before it gets asked, yes Jon, color management is broken
> in it atm. The likelihood of it getting fixed in a branch as opposed
> to trunk is next to non-existent though...
>
> To me this is very, very bad.
>
> That is, the requirement and our existing implementation were clearly
> spelled out before the project was started. Since the project had
> completed there has been ample time to get this at least looked at.
> Since it had not been, it is a clear indication of the lack of intent
> and possibly some critical implementation design flaw.
>
> It is also very bad that all attempts to engage in any discussion on
> this point have been flatly ignored.  :-(


> > So, would people be okay with a little breakage of existing
> functionality to get more testing of a cairofied Inkscape?
> bulia, I included you in the to line here to help gauge the
> acceptability of this proposal.
>
> Unfortunately one of the distros we are waiting on is MacPorts. So if
> we bring that into trunk now, I'll be completely blocked from further
> work. (Ubuntu upgrade trashed my main linux dev box, and I have to go
> in low-level and try to recover and repartition the hard drive)
>
> *However* given that in the past we've found ways to get code
> mainlined and at the same time maintain compatibility, I believe there
> is a chance we can do so with the Ciaro branch.
> *If* anyone could look at the code with that in mind, that could
> remove the main hurdle.

I am in favor, and hope this way more people will be engaged in the effort.
I do not like looking at other people's branches, so for me this would be
first exposure to it, and perhaps I can help here and there.
I think it would make life much easier on Krzysztof too, when he no longer
has to tweak other people's stuff from trunk to his branch.

If it stays with breaking part of functionality (is it only color
management, or more?), then I'm ok with it. If it breaks builds and if there
is no easy way to get the required libs, then I am not.
(since Krzysztof updates the windows devlibs, I am sure this will be OK on
my side)

Yes, AFAIK the color management is the only thing that would be broken right away other than a known cairo bug (which is fixed in cairo trunk) that affects rendering of gradients when at high zoom levels. Having more eyes on the code and also having more people stress testing can be a huge win.

I haven't tried building it on win32 yet, but know that KK has a windows install that I imagine he tested against. I will try building it on win32 later today and will report back. The other thing is we could really use someone giving a build a shot on OSX as well (this I can't do).

Cheers,
Josh