On 1/17/06, Brian Mattern <[EMAIL PROTECTED]> wrote:
not blaming anyone here :)
This is something that I'm thinking about a lot actually, there should be an easy way to do this, and it will probably be a tough one because there is a huge flexibility in the relative/offset concept and it will be a challenge to create an interface for them without it being cumbersome to use.
What I'm thinking about is probably some tool called "bind" or something, you bind two objects together, and a dialog pops up where you can specify various settings. It should mirror the "I want part A's top left
corner to be 10 px up and left from the center (0.5, 0.5) of part B...." in a simple way.
Lots of options here for how the GUI might do it, and I think they have to be explored to find what's best to use.
I did some prototypes using engrave to load edcs and then doing my own layout calculations.
What I was thinking about is something like how the Flash editor works; you edit on a stage, and you Export to test the movie.
The layouting in the editor is done by a stripped down version of _edje_calc() and when you export it compiles the .edc and lets you preview the final .edj
I'll take the blame for the latest mention. I brought it up, because 1) people
have been asking, 2) CodeWarrior kept saying you were working on something
and 3) over a year ago, I myself started playing around with ideas for a new
GUI Edje Editor.
not blaming anyone here :)
It's a good start. Having handles with modifiers to switch between absolute,
relative, and 'relative to' modes are what I had originally done in my
attempt. I think one of the more flexible aspects of Edje is the ability to
combine relative and offset positioning. E.g. 'I want part A's top left
corner to be 10 px up and left from the center (0.5, 0.5) of part B....'.
This functionality seems to be missing from the RFC (you lock 'relative' to
be either 0 or 1).
This is something that I'm thinking about a lot actually, there should be an easy way to do this, and it will probably be a tough one because there is a huge flexibility in the relative/offset concept and it will be a challenge to create an interface for them without it being cumbersome to use.
What I'm thinking about is probably some tool called "bind" or something, you bind two objects together, and a dialog pops up where you can specify various settings. It should mirror the "I want part A's top left
corner to be 10 px up and left from the center (0.5, 0.5) of part B...." in a simple way.
Lots of options here for how the GUI might do it, and I think they have to be explored to find what's best to use.
On of the largest issues that needs to be discussed first though is the actual
implementation of any edje editing utility. In my original attempt, I had
hooked directly into edje, allowing one to change the values of the part
descriptions 'behind the scenes', then simply let edje recalc on the next
render. This worked to some extent, but had a few issues.
In order to continue, we needed a library that mimicked edje, providing an API
for creating parts, groups, programs, etc, and modifying their values. Hence
Engrave was written. Engrave reads and writes .edc (it can read the .edc
embedded in an .edj file, and write .edj files by outputting edc and
compiling, so effectively it can read/write .edj files also).
Engrave, however, is a bit out of date, and doesn't handle everything that has
been added to edje since (textblocks, color classes, etc). So, its a bit
tough to maintain, as it has its own parser, and needs to be constantly kept
up to date with edje.
So, to cut short for now, the major issues that need discussion before even
worrying about exact gui details:
Should edje loading / saving / editing be in a separate library as currently,
or should this be added to the edje tree? (It would be nice to only have a
single edc parser to maintain).
Do we need to duplicate _edje_calc() [which does all the layout calculation
for edje] to work with our chosen representation of parts / states / etc. Or
can we somehow make the current function usable in both an editing
environment, and a display environment? (most likely we'll need our own
stripped down version of it)
I did some prototypes using engrave to load edcs and then doing my own layout calculations.
What I was thinking about is something like how the Flash editor works; you edit on a stage, and you Export to test the movie.
The layouting in the editor is done by a stripped down version of _edje_calc() and when you export it compiles the .edc and lets you preview the final .edj
The problem I encountered though was that engrave is only loading the very simple edcs, add a few macros and it fails. I didn't know it was out of date.
I think it's best to update engrave to the current edje, and use it in the editor because it already handles a lot of the stuff that is needed, and don't forget we need to create .edcs and not only edit them, so engrave is really the best choice I can see here.
--
Chady 'Leviathan' Kassouf
http://chady.net/
