On 07/29/2016 11:44 AM, Carsten Haitzler (The Rasterman) wrote: > On Fri, 29 Jul 2016 10:47:26 +0930 Simon Lees <[email protected]> said: > >> >> >> On 07/29/2016 10:11 AM, Cedric BAIL wrote: >>> On Thu, Jul 28, 2016 at 4:22 PM, Carsten Haitzler <[email protected]> >>> wrote: >>>> On Thu, 28 Jul 2016 14:55:46 -0700 Cedric BAIL <[email protected]> said: >>>>> I came to realize that splitting this 3 components don't really make >>>>> any more sense. If you want to build anything on top of efl, you are >>>> >>>> i totally agree. in fact if we are going to merge... we should do a lot >>>> more merging. we need to decide on a future much smaller set of libraries >>>> >>>> e.g. (lib* assumed) >>>> >>>> efl: >>>> eina, eo, ecore, efl, eio >>> >>> I am not to found of merging eina in efl as eina in itself is useful >>> for a command line application that doesn't need a main loop and may >>> not even need eo. I am putting eet in that same category. >>> >>>> eflgui: >>>> evas, edje, emotion, elementary, ector, ecore_audio, ecore_imf, >>>> ecore_imf_evas, ecore_input >>>> >>>> eflnet: >>>> ecore_con, ecore_ipc, eldbus, ecore_avahi >>> >>> I would argue that dbus is mostly used for UI and not network which is >>> why i see it in efl-gui. >>> >>>> eflsys: >>>> ecore_file, efreet, efreet_mime, efreet_trash, elocation >>> >>> ecore_file should be a legacy only library and the missing feature of >>> eina and eio correctly extended to cover all use case. Obviously I >>> would see eio in this library. >>> >>>> others left over to figure out... >>>> ephysics, eet, elua, embryo, eolian, ethumb, ethumb_client >>> >>> embryo should be in efl-gui as it is only used by edje really. Not to >>> sure of the future of ethumb and if we do want to maintain our own >>> thumbnailer. ephysics could get merged in efl-gui I guess. >>> >>> eolian should be merged in efl actually as otherwise it kind of make >>> eo less useful especially if we want to compile the .eo file of efl >>> :-) >>> >>>> and definitely unportable or dubiously universal lib api's: >>>> eeze, ecore_drm, ecore_drm2, ecore_buffer, ecore_cocoa, ecore_fb, >>>> ecore_psl1ght, ecore_sdl, ecore_wayland, ecore_wl2, ecore_win32, >>>> ecore_x, elput, escape, evil >>> >>> Do we even need to merge those ? They are not user facing normally >>> (well ok, some are used by enlightenment). This won't simplify much of >>> the API usage and won't really save that much memory. 40kb total if >>> merged, maybe ? >>> >>>> let's have a decent plan anyway first so we have a good idea where we are >>>> going. >>>> >>>>> now always going to link against those 3 libraries. Also as we push >>>>> for some more on efl interface, it become more obvious that efl and eo >>>>> are actually completely linked with ecore. As we were planning to >>>>> merge efl and eo anyway in 1.19, I am thinking we should actually go >>>>> one step further and directly merge with ecore. >>>> >>>> i think eina should merge in too to "libefl" and likely even eio and >>>> possibly even a chunk of ecore_file utility should be there either in eio >>>> or in eina - core file system interfaces. >>> >>> Well, if you are to merge eio in efl, there is no need for efl-sys I >>> think. I still believe eio should be in efl-sys and efl-sys exist. I >>> also think eina shouldn't be merged and same for eet, they have use in >>> standalone binary that need no main loop nor objects. >>> >>> Btw if we get agreement on this, I would like to do the merge right >>> away during efl 1.19 release cycle. Not just for efl, eo, ecore, >>> eolian merge, but for all of the above library merge. >>> >> >> Probably the best time to do the merge would be to call it efl 2.0, >> given that all the SO's are changing worrying about abi/api is much less >> of a issue, this would also be much less confusing. Even if that means >> its delayed to what would have been efl 1.21 or 1.22 I think that’s ok, >> I'm presuming at that point the eo based api would become the official >> api and the legacy api would remain but be depreciated (maybe i'm wrong >> there). > > we're at least planning on HAVING legacy until 2.0 but eo api will become the > "supported stable and developed with new features" api. as you can mix and > match eo and legacy this works as you can access new features via eo. but for > efl 2 i think i'd like to see legacy gone as it necessitates also lots of > horrible internals and exposing to maintain that compatibility. > > we can merge easily now as long as we install symlinks, OR we use "dummy > empty .so's that just have .so deps on others" . :) it would be abi and api > compatible. :) > I'm not saying it can't be done now, just that the time of efl 2.0 would be a slightly more sane less confusing time to do it potentially. Are there many real benefits to doing it now rather then when the time for 2.0 comes around?
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
