Re: evince-gtk, please comment

["Jani Monoses" <jani monoses gmail com>]

Hi Nickolay
 

Jani, we are happy to see evince as gtk-only application. But in current
state it's not optimal to check such kind of patch. Probably someone
will object to that but it will create additional problems without much
win. We do need to have gnome-based features and do need to use gnome
for that.

 

of course the gnome-based features are still there when not using --disable-gnome.

What are the additional problems you are thinking of? If it is maintenance because of the few
ifdefs I will maintain the patch more easily if merged than if it's out of tree like it is
now. I  have been updating and packaging it since September and 90% of the updating
efforts are spent on syncing up configure stuff and package building. The code merges are
most of the time trivial.

Can you at least consider the configure.ac and Makefile.am patches for now?
They cause the most headaches as when making an evince-gtk package I needlessly
generate a huge configure/Makefile diff against the original which is just noise.
The config option does not affect the code itself but would make my life a lot easier
and I could spend time on actually working on evince than keeping up with autoconf changes.

Let's make this process incremental, for example, we already have patch
for popt, let's review and apply it. Then let's migrate to gtk-only
recent-files (I suspect this code is already merged into gtk, we just
need to use it).

 AFAIK there are two goption patches actually, one I used as part of evince-gtk and
a new one sent about a week ago. I was thinking about the recent file code as well,
but did not check it out yet.

If you think that just dropping that in would be ok I'll have a look. I don't know if it
handles importing or other way of transitioning .recently-used, but losing that may not
be a problem.

Either way applying the gtk-only stuff to recent files code as it is now will not cause
maintenance problems, as that code is not supposed to be touched before switching
to the new bookmark code.

I hope after that problem will disappear automatically. Until that
please update your patch, it's really interesting and useful.
I'm adding the same comment to the bug.

 The problem is that updating my patch as it is now consumes all the time I can allocate
to evince, which I could spend more productively (still on evince) if it was merged.

I also have a deadline of sorts, I'd like to have this package in ubuntu by dapper, if possible
before code freeze. So while I can work on incremental patches to evince I am not sure how
long it would take to see the incremental patches in an evince release.
 
thank you

Jani