Am 26.01.2014 um 12:05 schrieb Thomas Strobel <[email protected]>: > On Sun, 2014-01-26 at 18:05 +0900, Carsten Haitzler wrote: >> On Wed, 15 Jan 2014 15:42:16 -0200 Felipe Magno de Almeida >> <[email protected]> said: >> >> sounds like they are talking about a glade like thing with a json/edc style >> syntax... and a few other doobies. >> >> some thing we have learned: >> >> 1. programmers hate designing gui's... in text - because they have to >> guess/imagine the results. it doesn't work. we need to design a gui in a gui. >> it may, in its internals have text or somethig else - but that is not >> relevant... as long as its EASY to bind to code that talks to the gui. >> 2. edc was way too verbose and was nothing more than really an exposure of >> edje >> structures. if you write such things you design it for writing in text - not >> as >> a simple exposing of internals >> 3. what we ended up with is that a declarative ui is mostly just the display >> of >> properties, and the declaration is simply a way of expressng that. edc/edje >> were too basic and elm is too much of a traditional set of widgets. we need >> to >> marry both - and that is what the adam/eve thing is seemingly doing at the >> glade/widget level. >> 4. we need a faster way to implement logic of ui elements and trivially >> inherit >> them and PATCH them. not just inherit then override - too coarse. what people >> need 90% of the time is an xisting ui element/widget with a few lines of >> extra >> logic here and there. >> >> i don't want to focus on any kind of json/c-like or xml file at all - it's >> wrong. been there. done that. not useful. you need a gui to design a gui. :) >> well ok - some of us can live without but MOST can't. :) >> >> lua (luajit) should solve the "quickly build ui element logic" problem and >> still >> keep thing pretty fast and lean. bob is waiting for eo2/eolian so we can >> expose >> efl bindings without manually doing them all ourselves. beyond that is pretty >> much building the layout elements we want in lua and a gui editor for it. >> >>> Hello all, >>> >>> I would like to share some ideas for Bob, which I see as an evolution >>> of edje. Please correct me if I'm wrong. >>> >>> Since I've started developing, back in 2008, a C++ Gui Library, which >>> has been already removed from assembla a long time ago, I've already >>> been eyeing the project Adam&Eve from Adobe Software Library (ASL). >>> Documentation can be found here: >>> http://stlab.adobe.com/group__asl__overview.html >>> >>> I think it is obvious the advantage of writing in a declarative way a >>> UI. But, writing UIs in EFL/Elementary are still a bit awkward and >>> requires more code than is necessary, because edje doesn't offer a >>> more dynamic layout setting. This generally requires box widgets to be >>> instantiated and edje layouts to be placed as small fixed dialogs >>> inside a multiple boxed layout. >>> >>> If bob/edje would incorporate ASL's Adam&Eve idea, we could develop >>> more fluid and easily portable layouts that would could ease >>> developing applications based in EFL. The layout "language" could be >>> written in Lua and a C engine could do the automatic layout placement. >>> It would require that the language gives room for manual placement so >>> the layout can be finely-tuned too, but I think this idea can vastly >>> ease development of UI for applications. >>> >>> BTW, there was a question about constraint solver on the ML recently. >>> I think it might've been related to this topic. >>> > > It was me how asked about constraint solvers recently. Yes, I was > looking for a way do describe more complex UI layouts in a declarative, > constraint based way. > > On a first look, I often came across the "cassowary" constraint solver > which seems to be used/mentioned a lot the last years. E.g. MacOS seems > to be using it as well. A recent, free and apparently fast > implementation in C++ (could be easily converted to C) could be found > here: https://github.com/nucleic/kiwi/ > > Kiwi is being developed to layout UI elements in Python in a declarative > way, and looking at how simple it looks, I don't think that you would > need a GUI to build up a GUI with enaml. > > I'm not sure yet whether the cassowary algorithm is actually the current > state of art, or if there are faster or more suitable constraint solver > out there by now. But so far I'm thinking that there might not be one > solution/solver to fit all. If I were to integrate a constraint solver > into EFL, I would probably keep edje, and it's capabilities, like it is. > It seems to have a small and fast solver for linear equality > constraints, and so I would keep edje to describe building blocks for > the UI. I mean, I would emphasise on speed rather then expressiveness on > this stage, and so I would be fine with having to describe layouts in > boxes or so. It doesn't seem like edje is designed to build complex UI > directly, but looking at the possibility of having pre-rendered images > with different resolutions that are being picked automatically, it seems > very well designed to construct building blocks of a UI. > > But I would then integrate a more capable constraint solver operating on > evas objects, which is then e.g. laying out edje objects. Any > hierarchical constraint solver dealing with equality an inequality > constraints and allowing them to be added and removed incrementally > would be fine. > On a C level it would require an API to declare the constraints, > similarly to what ephysics provides, a interface where you can plug your > constraint solver into, and some logic to synchronize updates between > evas/ecore and the constraint solver. If one could expose an API to set > the constraints instead of hiding this all within a GUI-builder, be it > edc or a special GUI, it would allow to wrap this API within other > higher level programming functions as well, some of them which are > pretty well suited to use as DSL. And defining a clear interface for the > actual solver would allow to use different solvers, and so maybe to port > edje onto the same API. But so far these are just a few thoughts... ;) > > If you want to get a constraint solver into EFL quickly, maybe you want > to have a look at Kiwi and give it a try :) > > Thomas Having a dedicated constraint solver sounds like a good idea to me. As you said, it should be plugable, so we can go with state-of-the-art, without changing too much of the infrastructure. I would really love to see that integrated with efl. I’ve seen a lot of cases where edje just isn’t mighty/expressive enough.
Looking forward to comments by raster/cedric/anyone who’s hacked on the layout algorithm internals. -- Leif > >>> Regards, >>> -- >>> Felipe Magno de Almeida >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> enlightenment-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >> >> > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
