There are a variety of reasons, dan mentioned one of the big ones a couple more are:
1. EWL pre-dates Evas (at least this version), and thus smart objects. 2. We do some interesting tricks to reduce our overhead for non-visible objects. Both of these don't rule out a port to smart objects necessarily, but given the point that dan mentioned, it doesn't seem like a worthwhile use of already limited time. On Thu, Mar 20, 2008 at 8:17 AM, andres <[EMAIL PROTECTED]> wrote: > El Wednesday 19 March 2008 19:26:18 dan sinclair escribió: > > Currently Ewl positions widgets based on absolute coordinates. This > > works but isn't unnecessarily optional. Thoughts on changing the > > internals of Ewl to use parent relative placement of widgets? > > > I have been giving this a lot of thought since I first read the original > mail. > It couldn't have come in a better time since we could merge this with > the "Object Layout Library" SoC idea. > > But I cannot avoid to think there are some limits and problems I cannot > visualize. For example, why didn't EWL implement the widgets as Smart > Objects? This way Evas or Edje could be used as layout engines. > > For the book I'm writing I have gone throught the common widgets in my head > and couldn't see any unsolvable problem with using Edje for layout and > behaviour of these widgets. Other than list based widgets . So I will need > your help to understand these limitations. > > I began to experiment by splitting widgets in three parts. The widget logic > was implemented as an Smart Object. The widget layout and behavior was > implemented as a single Edje group consisting only of SWALLOW and GROUP > parts. Swallow parts were used to control layout and behaviour of child > widgets, if any. Group parts were used to control layout and behaviour of the > graphical elements that decorate the widget. This made simpler for an artist > to limit itself to aesthetic changes and only dealing with layout and > behaviour if he wanted to. > > I can see why this would seem hackish, thus my SoC idea was to take > the "Object Layout Library" based on Ed to implement something like this in a > more clean way. A method to layout any type of widget without losing > capabilities that Edje provides, like allowing the artist to alter sizes, > visiblity and behaviour of the whole application and each of its widgets > using transitions (by implementing the window as a three-part-widget itself). > > But I think I'm missing some cases to sudy and I would need you guys to send > me examples in which this approach wouldn't work or be unconvenient. I would > like to submit my SoC application this monday so I can keep the application > updated during the week with your feedback and perhaps by friday having a > clear design for the "Object Layout Library". > > Thanks for reading all this =) > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
