On Tue, Sep 7, 2010 at 5:08 PM, Fabiano Fidêncio
<fiden...@profusion.mobi> wrote:
> On Tue, Sep 7, 2010 at 11:51 AM, Gustavo Sverzut Barbieri
> <barbi...@profusion.mobi> wrote:
>> On Tue, Sep 7, 2010 at 11:47 AM, Fabiano Fidêncio
>> <fiden...@profusion.mobi> wrote:
>>> On Tue, Sep 7, 2010 at 5:16 AM, Vincent Torri <vto...@univ-evry.fr> wrote:
>>>> On Mon, 6 Sep 2010, Fabiano Fidêncio wrote:
>>>>> Howdy!
>>>>>
>>>>> I, as Enlightenment's user, feel lacking of some programs, that
>>>>> consider essential for a normal user.
>>>>> In the top of the list, I can say that we need of a{pdf,image} viewer.
>>>>> I don't know if the most active devs prefer one program to see pdf and
>>>>> one program to see image, like evince[0] and gthumb[1] (I think that
>>>>> ephoto can be compared with gthumb).
>>>>> Or a more generic program like Okular[3].
>>>>>
>>>>> I'll wait for the answers and start the development (in my free time,
>>>>> of course) of this software (or, at least, of the skeleton).
>>>>
>>>> I answer after having read all the thread about that.
>>>>
>>>> I have written epdf, eps and edvi having in mind writing a framework (a
>>>> lib)
>>>> that would open a document with the corresponding library.
>>>>
>>>> So exposing a module system (with eina_module) which would open a .so based
>>>> on the extension of the file, for example (if not succedding, trying all
>>>> the
>>>> available modules). That is, exactly what evas does with its modules.
>>>>
>>>> That is why the API of the 3 libs above are quite close (almost the same).
>>>> There is now 2 possibilities : we use them, or we write the modules based
>>>> on
>>>> their code.
>>>>
>>>> So before writing a document viewer, I would like such framework being
>>>> written.
>>>
>>> Ok, Vincent. I'll do it and with advances or problems I'll ping you in
>>> #edevelop.
>>
>> I'd say do the app now, otherwise we'll end with yet another library
>> with an associated application to use... :-/
>>
>> As Vincent said, the API is quite similar, so pick one like epdf and
>> do the app. Once it's okay, you can write the abstraction with similar
>> api and sed the code.
>>
>> During the process you may find some API being "wrong" or "unhelpful",
>> maybe require more API and you have to change a single place. The
>> other approach you'd have to change 3 + 1 places. Then if you notice
>> it is wrong, you go and change that amount again, etc.
>
> Nham!
> I really prefer write an app, for now. And, after this, build the
> framework that Vincent said.
>
> I don't know what is better for the project and I'll wait for a
> decision of the most active commiters.
Let me give you my opinion then, I would go the middle way, do the app
and the framework at the same time. But only with one backend, let say
epdf. Focus to make application work and responsive. When that is
done, we can fix edvi, eps, edjvu and other to match the module api of
that framework. It's a little bit more complex than just having a
src/bin and a src/lib, but that for you to split function logically
from the beginning not sharing any internal data of the app with the
framework.
--
Cedric BAIL
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
