Marco Pesenti Gritti wrote: > what is the rationale behind this? Dont we actually want to support > nautilus properties for all the mime types we support (or at least > those that provides metadata). > > Marco > >>I was actually going to propose the alternative, and suggest that you >>just link it with poppler. >> >>Thanks, >>-Jonathan
Marco, may I suggest that if the other types use libraries like poppler then it would be just as practical to link to each of them individually. Of course, a common EvDocument method would be nice, but at what expense? It is not simple to make this work with importing half of the backend. To put things in perspective (on x86_64 binary format): Manually including .o's from all over the place (some from shell/ and some from backend/) to resolve dependencies by hand, my extension is rather big: -rwxr-xr-x 1 root root 314449 May 12 23:02 libevince-properties-page.so This does not even have all of the dependencies in yet, and as such, it does not work. I gave up on this approach after three iterations of manually linking in compiler objects. I'm sure there's a better way to do this. Is there? Even if there is, how big do we allow the library to get? I don't know much about how nautilus does its dlopen(), but I can see RAM usage skyrocketing with libraries that are hundreds of kilobytes in size. All of totem's properties page is ~94K with an additional ~10K for gstreamer on this same machine. And that handles a multitude of mime types. I should probably just get on IRC and "talk." :) --Pat _______________________________________________ Evince-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evince-list
