Carsten Haitzler 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.
>>
>
>
>
Perusing edevel lists... thought I'd say something here.
If indeed elem is now the official, one-true, high level widget lib
for e
(a point of much contention in years past), then Monsieur Haitzler is
correct.
Not only is it fairly certain that the overwhelming majority of e
lib users
want high level widgetry, but it's good policy to introduce that to people
even looking at using e's gfx libs - ecore/evas/edje are tough for people
who are not already e developers.
I'd even advice wrapping some of the more commonly used 'evas' api
funcs
that were used in elem apps (like align/hints/etc) into elem funcs (if
this hasn't
been done already, haven't looked at it in yrs), i.e. make more of the
oft used
elem widget funcs be in - elem - rather than in evas or edje or whatnot.
------------------------------------------------------------------------------
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=272487151&iu=/4140
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
