Re: Evince update and release
- From: Pat Suwalski <pat suwalski net>
- To: Marco Pesenti Gritti <mpgritti gmail com>
- Cc: evince-list gnome org, Jonathan Blandford <jrb redhat com>
- Subject: Re: Evince update and release
- Date: Tue, 24 May 2005 11:23:25 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]