Hi,

On 29 April 2016 at 12:19, David Seikel <onef...@gmail.com> wrote:

> On Fri, 29 Apr 2016 11:32:39 +0900 Jean-Philippe André
> <j...@videolan.org> wrote:
>
> > As for bindings, they need to be able to dynamically know which
> > functions an object support based on its class (here the object is an
> > instance of a class implementing Efl.Pack). Otherwise I don't see how
> > any binding would work at all. (In C++ I would cast to the efl_pack
> > class, but that doesn't work for Lua/JS).
>
> That's what I've been saying for a while now, EO run time introspection,
> for Lua bindings specifically.  Also need to introspect the classes
> available.
>

A bit unrelated :)
Full introspection might not be *required* for bindings to work, they only
need to be able to match an EO object with its class and from there know
which APIs are supported.


Though now I'm thinking of going in a different direction anyway.
> Going back to my original NAWS (Not A Widget Set) plans, but using that
> as a wrapper around a variety of GUI front ends, including Elm, HTML,
> wasm, and maybe something like curses.  In which case, the Elm part
> would be based on hand coding around Elm widgets to fit into the NAWS
> wrapper.
>
> Oddly enough, the main test code for this might be a Conky Lua script I
> wrote this week.  It uses Conky's access to system info, but Lua
> driving Cairo direct instead of using Conky's rendering wrapper.  At
> this point I essentially have a generic widget that renders graphs as
> well as labels and frames.  Making this generic widget clickable turns
> it into a button, and that's the beginning of NAWS already written.  I
> already got plans to port this script to EFL, using Conky in text
> console mode to feed the values until I get around to writing all the
> EFL replacements.  Then maybe port the graphics bits from Lua driven
> lines and rectangles to something like eGraph, or port that bit to C.
>

Have you looked at Evas VG?



> I'm sure I can get an EFL version of Conky out of this, that works
> faster, and is more flexible.  Then I can use it as an internal
> monitoring widget for my super complex 3D virtual world project, as
> well as the beginning of the long planned for NAWS.  B-)
>
> Introspection might still be useful, it's just not as critical to me as
> it was before.  Coz this new EFL design is based on the ancient one
> that originally heavily used Java introspection.
>
> Making EO things more generic and more generally useful is always a
> good thing, so keep it up.  B-)
> <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel>
>
>


-- 
Jean-Philippe André
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to