On Friday 10 February 2006 02:18, Jan Rychter wrote:
> Rasterman wrote:
> > On Wed, 08 Feb 2006 01:43:03 -0600 Ed Presutti <[EMAIL PROTECTED]>
babbled:
> > > On Wed, 2006-02-08 at 15:34 +0900, Carsten Haitzler wrote:
> > > > On Wed, 08 Feb 2006 01:05:49 -0600 Ed Presutti
> > > > <[EMAIL PROTECTED]>
> > > >
> > > > babbled:
> > > > > Is there a way to set the state of an Edje part using C?
> > > > >
> > > > > I'm currently using a program inside of the Edje file to set state.
> > > > > I would like to do it via the C API if possible.
> > > >
> > > > no. u need to use programs to handle signals to set the state.
> > >
> > > Would it be worth my time to create a patch to add the C API to Edje?
> > > I'm just wondering if this was a "nice to have" that hasn't been
> > > implemented yet. If so, I can do a little work on a patch. If it's a
> > > "not going to happen" then i'll leave it be and continue to use
> > > signals.
> >
> > whats wrong with using signals? signals are a subset of the edje message
> > queue api - this is basicalyl an ipc system for process <-> edje to talk
> > back and forth. settign the state explicitly kind of bypasses the channel
> > by setting something directly - it kind of is a bit evil imho. if it's a
> > nmatter of just gettign tired of writign signal handler programs... write
> > a macro so it becoems a 1 liner :)
>
> I'll pitch in here, as I've been thinking about the same issue. If you
> use C, you probably appreciate the existence of a scriptable language in
> Edje. But if you use Edje from a high-level language, you would often
> much rather set the state directly, rather than use a second language to
> write little programs that set the state based on signals. It adds
> another level of indirection and duplicates code in many cases.
>
Using signals and programs instead of setting the state directly is more of an
encapsulation than a redirection. As is, a 'theme spec' for most edje apps
would include
A) a list of signals that are emitted by the app.
B) a list of signals expected by the app from the edje.
C) A list of part names that are required for swallowing objects in, and
possibly that events are expected from.
If we allow apps to set state directly we would add (D) A list of expected
STATE names.
So now, instead of telling the object "go_active", which could update several
parts, possibly through several state transitions, you would say "set the
'title' part to the 'active' state". Now one part changes to a _defined_
state. Severe loss of flexibility from the theme side. I much prefer having
the choice of states used be completely flexible.
> It was my impression that I'd eventually end up writing code that will
> generate the little programs for me, and that feels kind of wrong.
these 'little programs' are as simple as
program { name: "foo"; signal: "do_this"; action: SET_STATE "this" 0.0;
target: "partA"; target: "partB"; transition: LINEAR 0.5 }
does that really require "generating code"?
if you really hate typing it out, write a macro for the generic case (single
target, no/common transition).
>
> Wouldn't it be better to be able to set the state, and if one wants to,
> "hook" into the state changes with Edje programs? That way the designer
> would still be able to do fancy transitions if he wanted to, but overall
> code size would be minimized?
Think of the states as "internal implementation" in the edje object, and the
signals as the interface. I find the encapsulation much more flexible.
--
rephorm
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
