On Mon, 31 Oct 2011 04:05:23 +1000 David Seikel <onef...@gmail.com> wrote:
> 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 One more thought before I go to bed. Shouldn't the entire scope thing work the same as scope rules in other languages? Isn't that what this is all about? You define classes at various scope levels, but when you access those classes, you should start from the inner scope, work your way slowly through the higher scopes, until you find the first DEFINITION. Then work with that definition, whatever scope it is? Reading and writing the one you found at THAT scope. So, at the very least, it should be object scope, file scope, then global scope. Don't have the access functions silently creating stuff at the current scope and surprising you. No need for functions at each scope. One function to get the class from the nearest scope, one function to set the class at the nearest scope, and one function to define a class at the current scope. -- 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
