Bob
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