Bob

Updated 1,180 Days AgoPublic

Actions

Project BÖB

This project is about writing a replacement for Edje for EFL 2.0. Some things we got right with Edje, some others we got wrong. We have learned a lot since Edje was created, so here is it.

What Edje got right

• Separation between logic and UI
• Declarative UI
• Use EFL infrastructure
• Themability

What Edje Got wrong

• Too many interfaces: signals, message, text_set, drag, swallow.
• Not (easily) parallelizable.
• Too many "if's" in the code depending on the type of the part and its properties, executed in each calculation cycle.
• Difficult to switch to a new theme/object without recreating the object from outside of Edje (as you need to transfer state which is not kept separately to the object logic - thus a desire to use properties).
• Limited layout capability (if it looks like it, it's a bi-product of over-engineering, not a desing).
• No (nice) UI to edit it from the beginning.
• Very limited sharing across processes.

Solution proposal

• One interface to set/get properties and watch when they change.
• Use LuaJIT internally for everything (so we are basically building object trees/graphs out of lots of snippets of Lua put together from a library of such snippets).
• Properties would be Eina_Value mapped to Lua tables.
• UI will expose various snippets of code as a preview of the object.
• Resulting project is an assembly of snippets of Lua code that would be compiled together, and separated into computation units that we can run in parallel, if desired.
• Snippets could be shared across objects, projects and on-line.
• It would be possible to do asynchronous MVC where the Lua handles the creation and rotation of an infinite list of objects and exposes a set of tables to get new content when needed.
• A daemon could be in charge of generating the JIT and thus sharing information across processes (Does LuaJIT allow for this?).
• There will be no compiler, only a GUI builder from the start.

Action items

• Find a proper name
  • Proposal: Bolt
• Design the GUI builder
• Check on LuaJIT for this task
• Start an initial code-dump to play with

Brainstorming Ideas for Design Concepts

Plain-text-only is not so efficient for design interfaces (which is very important), and simple gui's are boring and uncreative, the best is to have a set of unique features, like:

• mouse-wheel to zoom in the interface in order to have maximum-detail of the elements
• visual grid which shows the different values in their different modes in a bar when mouse-over on it (realtime)
• text-mode (similar to edc?) always being able to edit with an external editor (user-desired for avoid editor-wars) which automatically updates the gui when saving (inotify?)
• "magnet-friction" when moving an element while pressing a key (shift? "m"?)

Brainstorm Ideas for hotkeys system

In a perfect world, the gui should be only used for visual information and positioning elements, everything else (options) should be triggered with keys as much possible, for example:

• m = enable/disable magnet friction/resistance mode, for position elements with more accuracy
• shift = bigger mode of options, for example "m + shift" enable magnet with bigger resistance
• a = align: for fully magnetice the element with the horizontal/vertical position of other elements (cannot be positioned freely with this option)
• c = opens a color editor palette picker where the mouse-position is, which efficient features like pasting an hex value or a color-selector tool like elicit (elicit works back, we may use it with dbus or similar)
• l = enable/disable a window which shows the list of all the element info
• h = hotkeys summary menu, of course
• r = run interface
• g/G = change group
• e/E = change element ("part") to edit
• i = insert a new element
• y/p = yank/paste ?
• r = opens rotate settings options for configure in the element
• t = transitions
• v = visual, opens a window with misc preview feautres in realtime
• o/s/^z/^Z = open / save / undo / redo

All the options can be visualized in a bottom bar in elements as red/green colors, but cannot be clicked (force user to use keyboard keys, which is faster), instead it shows which key it is. (Key hidden if the user has a touch screen and we support GUI building with touch screen interfaces.)