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.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. 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
