Page MenuHomePhabricator

Bob
Updated 1,014 Days AgoPublic

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.)

Last Author
evi1m4chine
Last Edited
Jan 7 2017, 5:21 AM
Projects
None
Subscribers
seoz, sachin.dev, bluezery
Tokens
"Love" token, awarded by bluezery.