Hi raster, On Sat, Nov 24, 2012 at 6:28 AM, Carsten Haitzler <ras...@rasterman.com>wrote:
> this is important to all testers, users and packagers... > > DONT PACKAGE AND USE ESVG! DO NOT DO THIS. USE EVAS_GENERIC_LOADERS AND > LIBRSVG > SUPPORT! > > This is bad publicity for the project :-/ > there. i hope that is clear. :) if you want things to be stable, render > correctly - dont rely in ESVG. at this stage it is experimental. there are > still too many reports relating to svg issues and esvg. the generic loaders > Would be interesting to have those tickets or reports known. Crashes have been fixed for those who have complained about it and that we very long ago. Would be nice to have more information on that. Is there some ticket? or maybe some ticket forwarding or something? > rsvg one may not be as fast, but it will not crash any process trying to > use it > - at worse the loader binary will crash. esvg needs work - one day it'll be > ready, but as of today, it is not. > > also esvg creates a circular dependency as of efl 1.8. esvg needs enesim > which > needs eina... which as of efl 1.8 will be in the same build tree as evas > (the > efl tree), so you can't possibly cleanly build esvg support for evas > without > doing a multi-stage bootstrap and install of efl over several package > iterations. > Yes, this is indeed a limitation. But it was not my call, I could not even vote for that decision, maybe I missed the poll, dunno ... IMHO the decision of making a single EFL tree, even if good from a marketing POV, has forced a situation which does not make much sense, at least for the EFL itself. Basically now, not only enesim/egueb/whatever lib that depends on part of the EFL has to be moved *inside* the EFL tree in order to make every other EFL project use it (as with the esvg evas loader), but also now, the possibility of "outside innovation" has been cut off. I would have preferred to have a EFL tree in a way that you can split in efl-core, efl-gfx or stuff like that so one can reuse different components. But that's not the case. Is like having glib, gtk and cairo on the same tree and now gtk-clutter is out of the playing field unless it and clutter itself is moved into the same tree because of the circular dependency. This is not exactly a "valid" example, but you get the idea. I think recently the same has happened with ephysics, IIRC ... > > ALSO... i HIGHLY RECOMMEND that you build evas_gneric_loaders with spectre, > poppler, libraw and gstreamer support for best experience with efm - then > video, document etc. files will get thumbnails. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
