On Tuesday 17 January 2006 01:52, Chady Kassouf wrote: > Hello, > > Since I see a mention of this everyday in #edevelop, I think it's time to > clear things up.
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. > > I am NOT trying to continue/port/replace etcher. Here's what I'm trying to > do: > I'm trying to make a GUI editor for edje that will try to abstract the > edjes into something that might be easier to work with for designers. > Right now, 'Etcher' is the name of the old ebits editing app. Since ebits are completely deprecated, I think the general concensus is to reuse the name for any edje editor we write. It would have nothing in common with the old one but the name. :-) > I started working on a small app to test some ideas, but now all I have is > some text that describes what I'm trying to do. This text is an RFC and I > wasn't going to send it before it is finished, but since I see a lot of > people talking about it, here's what I have so far: > > http://chady.net/edjeeditor.html > > The text isn't big, because it still doesn't go into any details, and I > haven't started coding anything from this, because there are still a lot of > areas that need to be addressed first. > > Please reply with your thoughts/comments... 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). 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) -- rephorm ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
