On Wed, 13 Jan 2016 10:07:01 +0000 Andrew Williams <[email protected]> said:
> 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? it ENCOURAGES people then to make efl builds without widgets (elm). this is not something we'd want to encourage. > Cheers, > Andy > > On Tue, 12 Jan 2016 at 23:57, Carsten Haitzler <[email protected]> wrote: > > > On Tue, 12 Jan 2016 20:33:34 +1000 David Seikel <[email protected]> said: > > > > > Hmm, no one else commented, so I will. > > > > > > On Mon, 11 Jan 2016 16:42:45 -0800 Cedric BAIL <[email protected]> > > > 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) [email protected] > > > > > > > > ------------------------------------------------------------------------------ > > 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 > > [email protected] > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
