Re: [E-devel] E SVN: raster trunk/evas_generic_loaders

[Vincent T. <vt...@un...>]

On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote:

> On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri <vt...@un...>
> said:
>
>> On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
>>
>>> On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri
>>> <vt...@un...> said:
>>>
>>>>
>>>>
>>>> On Tue, 26 Apr 2011, Enlightenment SVN wrote:
>>>>
>>>>> Log:
>>>>> some readme fun
>>>>>
>>>>>
>>>>>
>>>>> Author:       raster
>>>>> Date:         2011-04-26 00:46:01 -0700 (Tue, 26 Apr 2011)
>>>>> New Revision: 58922
>>>>> Trac:         http://trac.enlightenment.org/e/changeset/58922
>>>>>
>>>>> Modified:
>>>>>  trunk/evas_generic_loaders/README
>>>>>
>>>>> Modified: trunk/evas_generic_loaders/README
>>>>> ===================================================================
>>>>> --- trunk/evas_generic_loaders/README	2011-04-26 07:29:30 UTC (rev
>>>>> 58921) +++ trunk/evas_generic_loaders/README	2011-04-26 07:46:01
>>>>> UTC (rev 58922) @@ -1,2 +1,27 @@
>>>>> Additional "generic" loaders for Evas that are stand-alone executables
>>>>> -evas may run from its generic loader module
>>>>> +evas may run from its generic loader module.
>>>>> +
>>>>> +Generic loaders currently provided:
>>>>> +
>>>>> +  XCF (.xcf .xcf.gz)
>>>>> +
>>>>> +Wanted:
>>>>> +
>>>>> +  RAW
>>>>> +    (libopenraw1 ??)
>>>>> +  PDF
>>>>> +    (use -key option to specific what page to get and load options for
>>>>> size
>>>>> +     and use poppler and/or mupdf - look at epdf)
>>>>> +  PS
>>>>> +    (use -key option to specific what page to get and load options for
>>>>> size
>>>>> +     and use ghostscript (libgs) to render etc.)
>>>>
>>>> what is the interest compared to eyesight/epdf/eps ?
>>>
>>> trivial thumbnailing. not intended for full ps/pdf control. also to avoid
>>> the gpl issue in epdf. you could have a loader use evas itself and epdf
>>> etc. if u wanted. it'd work. use buffer engine and render to memory. i'm
>>> not that fussed really.
>>
>> I've looked a bit at the xcf code. Why are you doing a binary and not a
>> lib ? (having an init, shutdown, head and data functions)
>
> 1. its the old xcf loader code from imlib2_loaders, so its inheriting fluff
> 2. GPL. making it a lib makes it a GPL lib and anything linking to it becomes
> GPL. making an executable avoids the GPL problem. thats WHY i mentioned PDF and
> PS - epdf has a GPL problem.

i thought that with shm_open, we could avoid that problem, even with a 
lib. But it seems it's not the case.

>> Also, maybe you could add a library that implment common code. I think
>> about shm_alloc and shm_free, that are (almost) not related to the loader.
>> (shm_alloc needs the name of the loader, and one would have to apss a
>> pointer for the stored values like shm_fd, etc...)
>
> when/if time permits. right now there is just 1 binary there. when there are 2
> i might make the code common and compiled into both. there is little point for
> a shared lib at this stage as the shared code is infinitesimal and any savings
> in not duplicating it are lost in multiple separate pages for the code and
> symbols and so on. :)

not a shared lib. a static lib (a .la, which is not installed, and we link 
against it, like we do with sub parts of evas for example).

Vincent