Re: Evince update and release

[Marco Pesenti Gritti <mpgritti gmail com>]

I think linking in the evince backend abstraction rather then poppler
directly would be preferable, since we can provide support for more
types (postcript, ppt...).
I think we can deal with linking only the necessary parts of the code
in one way or another...

Marco

On 5/22/05, Pat Suwalski <pat suwalski net> wrote:
> Jonathan Blandford wrote:
> ...
> > Once the release is done, I'd like to try to get the properties dialog
> > into CVS.  I'm also planning on looking at permissions, if no one else
> ...
> > Is anyone else doing anything interesting?
> 
> Last week I spent a good many hours toying with the nautilus properties
> page. I got to the point where I have a "PDF" tab that responds to the
> PDF mime type and I can put anything in it.
> 
> However...
> 
> When I refactored the pdf properties patch to placeable into a tab (in
> addition to the window used in file->properties menu in evince), I sort
> of hit a wall.
> 
> The problem is that to use the document properties from evince, you need
> to include all of the evdocument dependencies (all of the base code),
> etc. To make it work, the .so nautilus extension would essentially need
> to have 75% of evince embedded in it. That would make it excessively
> large and inefficient.
> 
> There are two solutions to this problem:
> 
> 1. Make all document properties code in evince atomic.
> 2. Make the nautilus extension access the information via poppler itself.
> 
> Number 2 has the most potential. While it would require some code
> duplication, the resulting nautilus .so would be small, as it would be
> linked against poppler. The glade UI could be reused without any issues.
> The biggest maintenance chore would be that any bugfixes and updates
> would have to happen in two places.
> 
> Of course, Option 1 is also possible, and in the long run it might be a
> cleaner solution. The idea is that linking a .o into the nautilus
> library is "okay", linking several (especially across directory
> boundaries) becomes insanely difficult. Keeping track of the symbols
> becomes a big chore. Totem, gstreamer, and nautilus-burn don't have this
> problem because they access things from shared libraries almost exclusively.
> 
> As you can see, I've given this some thought and tried applying it. I
> believe that the nautilus properties page would be a fantastic thing to
> have, and I think it might be worth some small amount of code
> duplication to achieve this.
> 
> I am not terribly familiar with the evince code; it is possible that I
> have completely overlooked something.
> 
> Any easy-fixes?
> 
> --Pat
> _______________________________________________
> Evince-list mailing list
> Evince-list gnome org
> http://mail.gnome.org/mailman/listinfo/evince-list
>