On Tue, 9 Dec 2008 10:57:23 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
> On Tue, Dec 9, 2008 at 9:51 AM, Hanspeter Portner <[EMAIL PROTECTED]>
> wrote:
> > Gustavo Sverzut Barbieri wrote:
> >> On Fri, Dec 5, 2008 at 1:50 PM, Hendrik Siedelmann
> >> <[EMAIL PROTECTED]> wrote:
> >>> 2008/12/5 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
> >>>> On Thu, Dec 4, 2008 at 10:59 PM, The Rasterman Carsten Haitzler
> >>>> <[EMAIL PROTECTED]> wrote:
> >>>>> On Fri, 5 Dec 2008 00:03:18 +0100 "Hendrik Siedelmann"
> >>>>> <[EMAIL PROTECTED]> babbled:
> >>>>>> 2008/12/3 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>:
> >>>>>>> On Tue, 2 Dec 2008 21:02:54 +0100 "Hendrik Siedelmann"
> >>>>>>> <[EMAIL PROTECTED]> babbled:
> >>>>>>>> 2008/11/30 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>:
> >>>>>>>>> On Sun, 30 Nov 2008 19:27:35 +0100 "Hendrik Siedelmann"
> >>>>>>>>> <[EMAIL PROTECTED]> babbled:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> while fooling around with elementary trying to write some widgets I
> >>>>>>>>>> found a pretty huge limitation in edje.
> >>>>>>>>>> I was writing a page flip widget to be used for example for
> >>>>>>>>>> slideshow, document viewer but also for page switching using
> >>>>>>>>>> cursor/finger on touchscreen. But there seems to be no way to
> >>>>>>>>>> interaktiv set the transition between two states in edje. For
> >>>>>>>>>> example I want to blend between two parts depending on how far the
> >>>>>>>>>> cursor moved while pressed down. This way mouse gestures would get
> >>>>>>>>>> visualised by a preview of what would happen. But there I found no
> >>>>>>>>>> way to do this in edje one can only do the full transition...
> >>>>>>>>>>
> >>>>>>>>> for this - you need to use embryo script {}... it is possible -
> >>>>>>>>> with a bit of thought and complexity and custom states :)
> >>>>>>>>>
> >>>>>>>> Do you mean set_tween_state? Is there a reason this is not available
> >>>>>>>> over the c interface?
> >>>>>>>>
> >>>>>>> beacuse this is meant to be abstracted - c shouldnt be playing with
> >>>>>>> stats of parts directly. you can talk to the edje via messages -
> >>>>>>> these are used in many places in e and efl to abstract apis between
> >>>>>>> edje and c code.
> >>>>>>>
> >>>>>> But whenever edje is used inside a program the program code and the
> >>>>>> edje code depend on each other anyway. Most programmers (me included)
> >>>>>> choose a programming language for reasons. Forcing them to learn and
> >>>>>> use embryo for some parts is propably not the best approach.
> >>>>>>
> >>>>> edje is meant to abstract this so it can be replaced with some other
> >>>>> design and setup that does something different - and the designer
> >>>>> chooses this in the edje :)
> >>>>>
> >>>> yep, Hendrik, you're abusing edje and then complaining it doesn't
> >>>> behave. As you said, you choose your language and you can keep using
> >>>> it, just design your animation using it (hint: create your smart
> >>>> object, swallow it in your edje, possible using edje for your smart
> >>>> children... that is: edjes as parent and children of your smart).
> >>>>
> >>>> depending on what you want, this can be a bit easier... if you can fit
> >>>> into the "box" (sequence of items) model, then you can just implement
> >>>> one function and register that function with edje, then you feed it
> >>>> parameters using layout data (void*).
> >>>>
> >>> Well I trust you if you say I'm abusing edje (poor thing).
> >>> It's difficult to get documentation about well everything surrounding
> >>> the efl, so excuse me if I don't know what you mean.
> >>> Do you mean I should use evas directly from c together with a timer to
> >>> do the animations interactiv? Because I still want to use edje to do
> >>> complex transitions and keep it themable.
> >>> I now do it (already working) with embryo functions which react on
> >>> mouse events and then just use set_tween_state and programs to do a
> >>> whole transition (on signals from outside) or that finish the
> >>> transition (on mouse up).
> >>> I'd like to do it with c so the edc file only contains the
> >>> transitions, but not if that requires much more code than with embryo.
> >>>
> >>
> >> I see and understand your point, I tried to did things like that in
> >> the past, but Edje is a layer that makes some things easier, while
> >> others more difficult as you noticed, often these that are more
> >> difficult are not the intended use, thus why I say "abuse".
> >>
> >> I guess using embryo with tween state is the best so far. You can also
> >> jump in and help with lua scripting (or general scripting if you wish)
> >> to make script-only edje objects, they would be more powerful and
> >> things like this would remain in the theme, but be real programmable.
> >> So far we lack human power to write such thing, so we're stuck with
> >> Embryo :-P
>
> > As I love Lua and know it very well (both the scripting language itself
> > and its C-api) and your in search for man power to help integrating Lua
> > into Edje (and I love it, too), I'd like to contribute to the efl.
>
> Yeah \o/
woot!
> > I already have functioning Lua bindings for Evas from a case study I'm
> > working on at the moment. http://repo.or.cz/w/ego.git (highly
> > experimental stuff, though ;-)
>
> > Before I start to become familiar with Edje internals and find ways of
> > incorporating Lua, there are some questions:
> > - Has anybody already started on integrating Lua?
>
> Not as far as I know.
no. no one has as best i know. i have played with liblua (5.1) and noted that
it is now much more work to "sandbox" lua (manually load only specific libs
like math and string etc. and disallow loading/importing of any other
bindings), and i was playing with it to just get a feel - but this was just in
test dir.
> > - What should the scripting in Edje provide, and what not? Is there an
> > existing list on the web, in svn, describing the intended scope of the
> > scripting facility? If not, we may create it in the first place:
> > + Should the scripting only provide the logic to conditionally
> > tackle with Edje programs and states, such as querying/setting states,
> > transitions, emitting signals? That would just be an alternative
> > implementation of what Embryo does at the moment, right?
>
> It should be a replacement for embryo, yes. It should be safe. Only
> manipulate Edje object and Evas object created by edje (They could be
> dynamically created by the lua).
correct. it needs to be sandboxed. it cannot do network or file IO - it can't
lock up the app calling it with infinite for(;;); loops etc. etc. and even
should have limits on how much it can allocate as part of the lua vm.
> > + Should it also allow for dynamically creating, manipulating,
> > swallowing, read/write access of Evas and Edje Part objects directly? By
> > providing those features, you could fully program the user interface,
> > but that's not the main purpose of Edje, right?
>
> It should allow dynamic script. In fact the plan was to first use lua
> for dynamic script and replace edje/src/lib/edje_script_only.c embryo
> support with lua (as nobody use this capability from edje right now,
> breaking it would not be a problem). This part of edje could be used
> as a testbed for the lua binding seeing what kind of API we want to
> expose and how to expose it.
yup. first work on script_only objects. these are objects that are defined
PURELY by script. they have a create and resize function (and shutdown) as well
as a message/signal function to handle input from the app - and part text
setting etc.. basically these edje objects are implemented entirely as script
and interpret edje api interaction. the idea is they could USE other edje
objects in the same file (eg load N buttons or whatever) and via this mechanism
re-use edje's layout stuff already in C. they can also create and destroy on
the fly contents within the object. once this at least in principle works and
is reasonably well tested and debugged - replace the existing embryo script
with lua and make sure all the bindings embryo had have equivalents in lua
(some may not be needed as lua has dynamic allocation in the vm - embryo does
not ans thus needs bindings to call to store/retrieve data).
> > + Where to draw the line between Edje as a layout DESCRIPTION
> > library vs. Edje as a layout PROGRAMING library?
> > + By searching the list, discussions on this issue show up, but have
> > decisions already been taken?
>
> Decision as been taken that we want to move to lua. More than that,
> only raster know :-) But as always, the one who does, has a great
> influence on the result, so you can start working on it, and dump
> sample of code/edje file here and have some review.
as such edje is not meant to be a programming language or environment. it is a
ui description and interactivity library - it is meant to make it easier to
separate the final ui look and feel and small tweaks from the code. so you no
longer run to the programmer with "please move this button to the right, and
put that image there, make the background a little lighter" requests. these go
to the ui designer using edje - and the programmer doesn't need to know nor
care. edje is a TOOL to be used when doing a display/ui - but should be driven
from code. now if that code is lua (as you already have a bit of a study in
doing lua bindings for efl - that's excellent) or be it in python, or C - is a
separate matter, but edje would be used as a tool the same way regardless what
language is used for the "app". the "app" is what has privileges to read/write
files and do network IO etc.
> Good to see someone taking this huge task :-)
> --
> Cedric BAIL
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
