Re: More threading updates

[Jonathan Blandford <jrb redhat com>]

Marco Pesenti Gritti <mpgritti gmail com> writes:

> > So I fixed a lot of the missing/broken features in the threading branch.
> > Rendering, page changing, saving, printing and indexing all work now.
> > Indexing is on the slow side[1], but we know how to speed that up by a
> > lot in poppler.  That leaves four major features left to be done:
> > 
> >  * links in the page.  I have links half working on my machine.  It
> >    needs a few poppler changes, so I'm holding off on committing them,
> >    but once that change is made, we should be fine.
> 
> I'm looking forward to see this in cvs, it would probably help
> clarifying how we will go ahead with the other missing features...

Okay.  I'll make the needed changes to poppler, then.

> > I really don't want to move over to poppler-glib until the threading
> > branch is merged to head, and I feel like I've been holding up new
> > feature work to have such a large change on a branch.  Things like
> > smooth-scrolling and continuous views shouldn't be done until we merge
> > back.
> > 
> > When should I think about merging back the branch so that we can start
> > doing new feature work again?  Would people find it acceptable to do the
> > merge even with all the above broken?  Or should I keep moving forward
> > with fixing the features?
> 
> What is exactly the advantage to get this work on head? Testing?
> If so I think we should create a stable branch and then merge back to
> head. It may take a while to get back to feature/stability parity.
> People and distributions may need something more mature (even if
> slower) in the mean time...

The advantage is to limit the size of the diff.  As it is, any fixes or
features added to ev-view.c have to be added in multiple places.  The
threading change is one big change.  Moving to the poppler glib API is
another.  I just wanted to avoid drifting too far.

Additional testing would also be a plus.

Thanks,
-Jonathan