On Mon, 31 Oct 2011 03:31:29 +1000 David Seikel <onef...@gmail.com>
wrote:

> On Mon, 31 Oct 2011 02:14:11 +1000 David Seikel <onef...@gmail.com>
> wrote:
> 
> > On Sun, 30 Oct 2011 23:22:48 +1000 David Seikel <onef...@gmail.com>
> > wrote:
> > 
> > > This is my first crack at adding more lua stuff to edje.  This
> > > implements getting and setting color_classes.
> > > 
> > > It's not working though, I'm missing something.  The function
> > > reads the existing color_classes fine.  The actual values in the
> > > colour_class actually change, but the on screen colour never does.
> > > I copied how embryo does it. Perhaps the color_class in the lua
> > > script only group is not a pointer to the one in the edje, but a
> > > clone of it?
> > > 
> > > Maybe someone can enlighten me about what is wrong?
> 
> Think I've figured it out.
> 
> Like embryo, I'm using edje_color_class_find() and
> edje_object_color_class_set().  The former searches through object
> scope, global scope, then file scope.  The later searches object scope
> only, then creates a color_class if not found.
> 
> So what's happening in my tests is that I'm finding the file scope
> color_class in the first test to see if I can read the existing
> color_class.  In the second test, I set a NEW color_class in the
> object scope, then read it coz it's first in the _find() scope search.
> 
> However, the other group, the one with the part affected by the
> color_class I thought I was changing, is in a different object scope.
> It's likely using the color_class from the file scope, which is NOT
> the one I'm changing.
> 
> So the problem is that I'm changing the wrong color_class.  It worked
> in embryo, coz the embryo script is in the same group as the coloured
> part, so it gets the same object scope.
> 

Further thoughts...

edje_color_class_find() searches in object, global, then file scope.

edje_color_class_set() searches in global scope, but creates one in
that scope if not found.

edje_color_class_get() searches in global scope.

edje_object_color_class_set(), as used by embryo, searches in object
scope, but creates one in that scope if not found.

edje_object_color_class_get() uses edje_color_class_find(), and thus
searches in all three scopes.

For my project, I have three color_classes in the file scope, I want to
change them from the lua script in the lua script only group, so that
the parts in the group full of edje parts will change colour.

So far there is no such concept as lua only parts with color_class
support (I already said above that I plan to add that).  So for now,
object scope color_class is completely useless in lua. That's what my
patch does. No wonder it does nothing. lol

Now in embryo, it's doing the same as my patch, setting object scope
color_class.  It completely ignores any other scope, so it can't affect
file level or global level color_class usage in other groups.  This may
or may not be a good thing, depends on how it SHOULD work.

Note the oddness of the two _get() functions though.

edje_color_class_set() & edje_color_class_get() both search global.

The _object_ versions DON'T both search the same.

With three scopes, we should have three pairs of get/set functions,
one pair for each scope.  And we should have a function that searches
all three before setting the one it finds, to match
edje_color_class_find().

Should lua have a color_class() function that affects object scope (the
one I wrote already), a color_class_global() and a color_class_file()
functions that do the same in their respective scopes?  And should
embryo have similar additions?

I'm gonna write a lua color_class_file() anyway, since THAT'S the one I
need in my current project.

No doubt text_class will have a similar set of issues.  I plan on doing
that one to, coz I need it to.  Both color_class and text_class support
are on the lua TODO.  That's why I started there.  Plus, I thought it
would be easy.  lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Attachment: signature.asc
Description: PGP signature

------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World&#153; now supports Android&#153; Apps 
for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to