On Mon, 3 Dec 2007 10:41:03 -0600 "Nathan Ingersoll" <[EMAIL PROTECTED]>
babbled:

> This is a little off-topic for the thread, but there are some long
> term changes I would like to see for epsilon eventually.
> 
> 1. Split thumbnail generation into pluggable processes. If we can
> specify external commands for generating thumbnails, we reduce the
> amount of code necessary to support new formats. This also gives us
> robustness when a dependency mis-behaves and crashes the thumbnailing
> process.

agreed. a nice way to do really "quick and dirty" thumbnailers via external
processes either executed once per file to load, scale save and forget or to
load and then save a whole series of files (and provide some form of
progress/feedback as it does it - eg via stdout or something). agree on all
points here.

> 2. Switch to dbus for client to server IPC. Many of the issues
> currently with the epsilon daemon stem from some initial problems with
> ecore_ipc, and the hacky conversion to ecore_con. Dbus is also
> targeted at remote method invocation, which is essentially the goal of
> the epsilon daemon communications.

nothing against this.

> 3. Develop a dbus standard communication protocol with FDO. Ideally,
> we could get a protocol adopted by the major desktops which would
> allow for a single thumbnailing process to be present regardless of
> your application mix. For instance, if you are running nautilus under
> E and it handles thumbnailing requests, then we don't need to start a
> background epsilon process.

i think this is probably the real driver for dbus and i think its a good idea.
mind u this can be a huge time sink. imho we should first just do it
internally. develop something that works with a view to it being very generic
and clean - yet easily able to be modified if needed - at least in small
details, or extended. then when its settled - formalise the spec docs and
propose?

> These don't really help the release schedule for iNDT, but I think
> they would create a better long term result.
> 
> On 12/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> >         I wrote (regarding raster's thumb),
> >
> > >       It seems to have an evas-object interface that abstracts away
> > > the 'thumb file' concept and just concentrates on giving you the
> > > display-object you want for a given input 'uri' and desired size
> > > (probably could give more info as well). ....
> >
> >         It's.. kinda nice. :)  I wonder if the "fdo standards" could
> > be somehow geared more towards providing something like 'interfaces'
> > of some sort for things like this.. rather than specifying that one
> > should to give large and small image files somewhere.
> >
> > _____________________________________________________________
> > Dog supplies that give joy to man's best friend.  Click Here.
> > http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3naZ3vo7pnPMWDZKbC65edgry6H9JU4KlnEAklozN3Ee5KkA/
> >
> >
> >
> > -------------------------------------------------------------------------
> > SF.Net email is sponsored by: The Future of Linux Business White Paper
> > from Novell.  From the desktop to the data center, Linux is going
> > mainstream.  Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [EMAIL PROTECTED]


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to