On Wed, 13 Jan 2016 10:07:01 +0000 Andrew Williams <a...@andywilliams.me> wrote:
> 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? You had been away for some time, you might have missed Raster and I arguing over this sort of stuff. Raster prefers a "compile everything, just delete the stuff you don't need afterwards" approach. He seems to strongly dislike autodetecting stuff as well. I prefer to autodetect stuff, and disabling stuff I don't need before compile. In particular he always puts down my efforts to sanely squeeze EFL size down to fit into my embedded project, no matter how many times I point out to him that the legislation covering this sort of device requires it. So that's why, coz Raster. > 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 -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
