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 <[EMAIL PROTECTED]> 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/evince-list > _______________________________________________ Evince-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evince-list
