Hi, I agree with all your points and consider the merge a good thing. However I'm not sure why we're avoiding a --disable flag for those who specifically don't want it - is it much work to satisfy a use case?
Cheers, Andy On Tue, 12 Jan 2016 at 23:57, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 12 Jan 2016 20:33:34 +1000 David Seikel <onef...@gmail.com> said: > > > Hmm, no one else commented, so I will. > > > > On Mon, 11 Jan 2016 16:42:45 -0800 Cedric BAIL <cedric.b...@free.fr> > > wrote: > > > > > As we are moving forward with a stable API for binding, one of the > > > main "weirdness" that is still exposed is that you need to actually > > > require two differents library to use efl. > > > > Actually no, EFL is quite useful without Elementary, so you don't NEED > > it to use EFL. Of my two main EFL projects, one does and one does not > > use Elementary. Even the one that does, I'm considering writing my own > > widget set, which I have mentioned before. Since it's a reboot of an > > older project where I made it independent of widget set, likely I could > > do the same and make Elementary optional. > > for the VAST MAJORITY of uses of efl - you need/want widgets and a higher > level > abstraction. elementary is just that. that is the actual case. otherwise > everyone is off building their own widget set that is generally > half-implemented. implementing all the support from focus handling through > to > accessibility, copy & paste, layout, the widgets and more is a pretty huge > undertaking and most alternate widget sets will be half-done at best > without a > massive bit of work. so this offers a standardized implementation. Yes I > can > and have made things where i don't need elementary. it's a minority of > things. > we have to see the big picture, not all the tiny little exceptions. > > all it costs you is a bit more efl build time and then you can rm the > elementary files that are installed if you don't want it. it doesn't cost > extra > dependencies. > > > Mind you, I AM trying to give Elementary a good try in this project. > > I'm not going to be dismissing it out of hand. It will be quite a long > > time before I get around to writing my widget set. > > > > > Also the only reason why we haven't merged elementary so far as been > > > because it still depend on webkit-efl and webkit-efl depend on > > > elementary. > > > > Where would I find this webkit-efl? A quick look through our git > > didn't turn it up for me. I recall trying to compile some older web > > browser EFL thingy some time ago, not sure if it was that. I do > > strongly remember that it was a giant rabbit hole that just kept > > getting deeper and deeper. I eventually gave up trying to get it to > > build. I also recall that very deep down that rabbit hole was a GPL3 > > library, that infected everything else all the way up. > > i seriously doubt that. webkit-efl is shipped on tizen and no gpl3 > libraries in > sight. it would fundamentally break tizen's model if it depended on gpl3 > for > the web view - tghus forcing apps to become gpl3 by derivation. perhaps > there > was a build TOOL you installed - but webkit-efl does not depend on anything > gpl3 (at runtime). > > > I'm planning an alternate approach to web browser support for my big > > Elementary project. Actually, a couple of approaches. The one thing I > > wont be doing is adding a humongous web browser to it. > > > > > I am going to address that during next efl release cycle, by moving > > > the webkit dependency to be a module (like evas_generic_loaders and > > > emotion_generic_loaders). Once that is done it will be technically > > > possible to merge the both of them. > > > > So long as it's optional. > > rm the installed build files/dirs afterwards. :) > > > > This open a question, does anyone see any other reason to not merge > > > elementary ? > > > > So long as it's optional. > > > > I've said before, the non Elementary project of mine really needs to be > > kept down to a minimum size. My Elementary project is essentially a > > reboot of some one else's project, and that other project includes > > webkit, which takes up one third of the resulting package size. > > Considering that web pages is only a tiny part of what that project is > > all about, I find this to be unacceptable. Wont be happening to my > > version. > > rm rm rm :) > > > Personally I find HTML standards to be very, very, very, very bloated, > > especially HTML 5. I don't want to get any of that on me, especially > > since long ago I proved you don't need 99.9% of that bloat. My ancient > > matrix-RAD project fit on a floppy disk, with binaries, source, > > examples, and full documentation. It could do everything HTML 5 > > could, before HTML 5 was invented. My reboot's gonna be a little > > bigger. lol > > > > -- > > A big old stinking pile of genius that no one wants > > coz there are too many silver coated monkeys in the world. > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
