Carsten 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. :)
>
>
All the earlier 'well-known' xml or json formats (xul, mxml, ....)
were accompanied by gui designer apps. And there were attempts
here years ago to have the same for edje/edc (edje_editor, editje).
There was even Hisham's edc-like evolve format for etk widgets
and also an early version of a gui builder based on that (shortly before
the whole e community at the time went into a small civil war, partly
due to the lgpl vs bsd issues).
So everyone knows that a gui builder is essential - nothing new
there Carsten, and it's largely orthogonal to the issue of the type
of syntax used for the ui file.
The thing that the xml or json based formats gave is not only
persistence and simple distribution, but the ability to systematically
examine the semantic structure of the files, modify content, etc.
(as well as eliminating the need to write your own new parser and
creating a new base syntax). Beyond that, each one had its own share
of pluses and minuses... and for the xml based ones the issue is even
more varied since several kinds of scripting languages were allowed
by some of them.
> 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.
>>
>> Regards,
>> --
>> Felipe Magno de Almeida
>>
>>
>>
>>
____________________________________________________________
Do THIS before eating carbs (every time)
1 EASY tip to increase fat-burning, lower blood sugar & decrease fat storage
http://thirdpartyoffers.juno.com/TGL3141/52e5edb8a1ecd6db04505st03duc
------------------------------------------------------------------------------
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
