49
Enlightenment Developer Day 2015, Samsung Research America, Mountainview Thanks to r Carsten Haitzler <[email protected]> <[email protected]>

[E-Dev-Day-US-2015][1/9] Key Note (Raster)

Embed Size (px)

Citation preview

Enlightenment Developer Day2015, Samsung Research America, Mountainview

Thanks to

r

Carsten Haitzler

<[email protected]>

<[email protected]>

Discussion Starters“I came here for a good argument”

The follow are not intended as solutions, but as

discussion starters to explore and find solutions.

Some Important TopicsThings to discuss

“BOB”

Interfaces

Some Important TopicsThings to discuss

“BOB”… or whatever we will call it

Goals:

“BOB”… or whatever we will call it

Goals:

– Replace Edje

“BOB”… or whatever we will call it

Goals:

– Replace Edje– Replace / Augment Elementary

“BOB”… or whatever we will call it

Goals:

– Replace Edje– Replace / Augment Elementary– Simplify internal logic code by using Lua

“BOB”… or whatever we will call it

Goals:

– Replace Edje– Replace / Augment Elementary– Simplify internal logic code by using Lua– Allow easy / trivial modifications by developers with minimal

effort

“BOB”… or whatever we will call it

Goals:

– Replace Edje– Replace / Augment Elementary– Simplify internal logic code by using Lua– Allow easy / trivial modifications by developers with minimal

effort– Simplify interaction API from code (just properties(+

messages?))

“BOB”… or whatever we will call it

Goals:

– Replace Edje– Replace / Augment Elementary– Simplify internal logic code by using Lua– Allow easy / trivial modifications by developers with minimal

effort– Simplify interaction API from code (just properties(+

messages?))– Simplify switching “BOBjects” by state in Lua tables and

transferring them

“BOB”… or whatever we will call it

Goals:– Replace Edje– Replace / Augment Elementary– Simplify internal logic code by using Lua– Allow easy / trivial modifications by developers with minimal

effort– Simplify interaction API from code (just properties(+

messages?))– Simplify switching “BOBjects” by state in Lua tables and

transferring them– Provide GUI editor by default

“BOB”… or whatever we will call it

Goals:

– Replace Edje– Replace / Augment Elementary– Simplify internal logic code by using Lua– Allow easy / trivial modifications by developers with minimal effort– Simplify interaction API from code (just properties(+ messages?))– Simplify switching “BOBjects” by state in Lua tables and transferring

them– Provide GUI editor by default

● No compiler like edje_cc

“BOB”… or whatever we will call it

Goals:– Replace Edje– Replace / Augment Elementary– Simplify internal logic code by using Lua– Allow easy / trivial modifications by developers with minimal effort– Simplify interaction API from code (just properties(+ messages?))– Simplify switching “BOBjects” by state in Lua tables and transferring them– Provide GUI editor by default

● No compiler like edje_cc● Output files are directly editable again - always

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code● Must be able to GC/free unused code and data

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code● Must be able to GC/free unused code and data● Also C side resources need to be deleted with Lua data

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code● Must be able to GC/free unused code and data● Also C side resources need to be deleted with Lua data

– Need a way to source Lua from multiple “BOB” files (user, app, system)

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code● Must be able to GC/free unused code and data● Also C side resources need to be deleted with Lua data

– Need a way to source Lua from multiple “BOB” files (user, app, system)

– Need to begin to expose EO objects into Lua

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code● Must be able to GC/free unused code and data● Also C side resources need to be deleted with Lua data

– Need a way to source Lua from multiple “BOB” files (user, app, system)

– Need to begin to expose EO objects into Lua● Each “BOB” master container

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code● Must be able to GC/free unused code and data● Also C side resources need to be deleted with Lua data

– Need a way to source Lua from multiple “BOB” files (user, app, system)

– Need to begin to expose EO objects into Lua● Each “BOB” master container● Child / Utility objects too (Evas basic objects)

“BOB”… or whatever we will call it

● Need a name for it (and enough of calling everything Esomething)

● Need a start (LuaJIT executor as a library)

– Needs to be able to load and unload pices of Lua code● Must be able to GC/free unused code and data● Also C side resources need to be deleted with Lua data

– Need a way to source Lua from multiple “BOB” files (user, app, system)– Need to begin to expose EO objects into Lua

● Each “BOB” master container● Child / Utility objects too (Evas basic objects)

● Start writing “BOB”jects to test the above (Buttons, Sliders, Boxes, Tables etc.)

“BOB” Sample structure… or whatever we will call it

class button { inherit sys.widget; func init () { self.text = "" self.obj.bg = Rectangle:new() self.obj.bg.color = { 64, 64, 64, 255 } self.obj.bg.visible = true self.obj.label = Text:new() self.obj.label.color = { 255, 255, 255, 255 } self.obj.label.text = "Button" self.obj.label.visible = true self:update() } func text_set (text) { self.text = text self:update() } func color_set @slot1 { r = r / 2 g = g / 2 b = b / 2 a = a / 2 } func layout () { -- @slot1 self.obj.bg:resize(self.w, self.h) -- @slot1 end self.obj.icon:move(5, 5) self.obj.label.text = self.text self.obj.label:move(self.obj.icon.x + 5, 5) -- @slot2 x = self.x y = self.y –- @slot3 –- @slot4 –- @slot5 self.obj:move(x, y) }}

obj { class sys.box; name "base"; prop orient = vert; func override init { self.padding = { 5, 5, 5, 5 } } func new shimmer (time) { self.shimmer_anim = anim(time, function (obj, pos) obj.shimmer_x = (1 - pos) * (sin(pos * 20) * 30) obj.shimmer_y = (1 - pos) * (cos(pos * 30) * 5) obj:update() end) } func insert layout @slot3 { x = x + self.shimmer_x y = y + self.shimmer_y } func replace layout @slot5 { y = y / 2 } func delete layout @slot7; obj { class sys.button; name "hello"; prop label = "Hello"; pack end; } obj { extend_class sys.button; prop label = "Button at start"; pack start; } obj { local_class button; prop label = "Button at end"; pack end; obj { class sys.icon; prop file = "close-button"; } } obj { parent_class button; prop label = "Button at end"; pack end; }}

Not actual text – BOB file structure + metadata

Actual Lua cript held as verbatim text in BOB file

“BOB”… or whatever we will call it

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like– Will improve our API and learning curve

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like– Will improve our API and learning curve– Will make bindings seamless and clean

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like– Will improve our API and learning curve– Will make bindings seamless and clean– Is our opportunity to fix API mistakes

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like– Will improve our API and learning curve– Will make bindings seamless and clean– Is our opportunity to fix API mistakes

● Decisions to make

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like– Will improve our API and learning curve– Will make bindings seamless and clean– Is our opportunity to fix API mistakes

● Decisions to make

– Lots of fine grained classes that cover a specific feature

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like– Will improve our API and learning curve– Will make bindings seamless and clean– Is our opportunity to fix API mistakes

● Decisions to make

– Lots of fine grained classes that cover a specific feature

or

InterfacesFixing our APIs and march to EFL 2.0

● Insanely important

– Will define what EFL 2.0 will look like– Will improve our API and learning curve– Will make bindings seamless and clean– Is our opportunity to fix API mistakes

● Decisions to make

– Lots of fine grained classes that cover a specific feature

or– Larger classes which may be partially implemented

InterfacesFixing our APIs and march to EFL 2.0

● Color class

+

● Geometry Class

+

● Stacking Class

+

● Layer Class

...

InterfacesFixing our APIs and march to EFL 2.0

● Color class

+

● Geometry Class

+

● Stacking Class

+

● Layer Class

...

Vs.

InterfacesFixing our APIs and march to EFL 2.0

● Color class

+

● Geometry Class

+

● Stacking Class

+

● Layer Class

...

● Color class

+

● General Graphical Object Class

– Geometry may be implemented

– Stacking may be implemented

– Layering may be implemented

...

Vs.

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

– Makes C API match C++/Lua/JS/Python

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

– Makes C API match C++/Lua/JS/Python– Forces methods of the same name (in non-C langs) to have

the same signature

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

– Makes C API match C++/Lua/JS/Python– Forces methods of the same name (in non-C langs) to have

the same signature● Better API design IMHO

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

– Makes C API match C++/Lua/JS/Python– Forces methods of the same name (in non-C langs) to have

the same signature● Better API design IMHO

– Makes EFL easier to use/learn in C

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

– Makes C API match C++/Lua/JS/Python– Forces methods of the same name (in non-C langs) to have

the same signature● Better API design IMHO

– Makes EFL easier to use/learn in C– Brings out name conflicts that happen in C++/Lua/JS/Python

into C

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

– Makes C API match C++/Lua/JS/Python– Forces methods of the same name (in non-C langs) to have

the same signature● Better API design IMHO

– Makes EFL easier to use/learn in C– Brings out name conflicts that happen in C++/Lua/JS/Python

into C● We find these issues early, not late

InterfacesFixing our APIs and march to EFL 2.0

● Supporting shortnames for C

– Makes C API match C++/Lua/JS/Python– Forces methods of the same name (in non-C langs) to have

the same signature● Better API design IMHO

– Makes EFL easier to use/learn in C– Brings out name conflicts that happen in C++/Lua/JS/Python

into C● We find these issues early, not late

– Just need a pass across all efl .eo files to generate a shortnames set of .c/h files

InterfacesFixing our APIs and march to EFL 2.0

efl_gfx_shape_color_set() → efl_color_set()

efl_colorclass_color_set() → efl_color_set()

efl_gfx_shape_outline_color_set() → efl_color_set()

DISCUSSSlap eachother with trouts

DISCUSSSlap eachother with trouts