On Tue, Sep 7, 2010 at 12:06 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Tue, Sep 7, 2010 at 4:55 PM, Vincent Torri <vto...@univ-evry.fr> wrote:
>> On Tue, 7 Sep 2010, Gustavo Sverzut Barbieri 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.
>>
>> actually, there is something to check in epdf : is the API sufficient for
>> having a responsive gui like evince (a part with the rendered page and on
>> the left, a list of thumbnails of the pdf document which can scroll). The
>> rendering can take a lot of time, even if it is possible to zoom)
>
> If epdf, edvi and other don't use thread. As they are heavily relying
> on external library, it should be possible to move that part of the
> code in another thread and make that API completly asynchronous. Maybe
> doing so in the common framework would be a good place. If you are
> looking for sample code, look at eio it use ecore_thread a lot.
yeah, this would be amazing. :-) But needs to be done right,
fortunately this is much closer to a JPEG image than a HTML/WebKit
page, because the later sucks as it is bi-directional due JavaScript
and user interactions... anyway, take care to leak the memory buffers
you'll use in the thread to render the image.
BR,
--
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
