On Tue, Sep 7, 2010 at 12:22 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > 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, in an ideal world Vincent did it all right, so it would be a matter of writing using epdf api, then you'd: find -name '*.c' | xargs sed -i 's/epdf_/edoc_/g' and it would just work (given the framework is called edoc). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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