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 > > 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
