On Sun, 12 Nov 2006 14:38:50 -0500 Christopher Michael <[EMAIL PROTECTED]> wrote:
> Brian Mattern wrote: > > On Sun, 12 Nov 2006 03:40:17 -0500 > > Christopher Michael <[EMAIL PROTECTED]> wrote: > > > >> Brian Mattern wrote: > >>> On Sat, 11 Nov 2006 16:09:42 -0500 > >>> Christopher Michael <[EMAIL PROTECTED]> wrote: > >>> > >>>> This presents another issue in that what todo about precompiled > >>>> edj files ala get-e.org? Ship a seperate file with them? > >>>> Decompile/recompile? Etc, etc. > >>> they would just need to be recompiled. in general though, e17's > >>> usability trumps any concerns about supporting old theme > >>> binaries... > >>> > >> Of course, of course. Not saying that...just pointing out that even > >> if a given theme WAS current (ie: ok against current API), how to > >> determine avail. color classes? Decompile/recompile? Extra File? > >> (etc etc) > >> > >> "they would just need to be recompiled. in general though" .....my > >> point pretty much :) Do we decompile/recompile at run-time to > >> determine avail. cc's ? IMHO, no...too much work (read: procs) > >> going on during startup. > >> > >> Which leaves?? > > > > Decompile / recompile at runtime makes no sense. I was suggesting > > adding a directory of color classes to the edj file format that gets > > created by edje_cc when compiling (similar to the font dir, spectra > > dir, etc). If there are OLD edj files that were created before this > > was added to edje they would need to be recompiled (once, then > > released again) or they wouldn't work. Simple as that. > > > > Given that most themes don't even include color classes yet, its > > not an issue. > > > > Or am I misunderstanding the 'issue' you're trying to point out? > > No, I believe that hits the nail on the head...it was I > misunderstanding your approach :) IMHO, this approach seems the way > to go. Not quite. As I mentioned in the earlier email, this approach still has some issues to work out. Currently all themed objects have a category associated with them (e.g. "base/theme/borders"). E first looks for a theme set on the full category, if none exists or the group requested isn't present in that file, it falls back to the 'parent' category (e.g "base/theme"), proceeding up the heirarchy and finally falling back to the default theme. So, the border could come from any of a number of themes set. With the current UI, the choice is limited to two themes, the currently selected and the default. (But at some later date, an advanced theme dialog could expose the rest of the functionality). So, now what if one of the themes implements the color classes and another doesn't. Until we attempt to load an object (cascading down until we find a theme that includes the requested group), we won't know which file we need to actually look in. Add to that the fact that the same color class could be used by different objects (e.g. module themes) and implemented in some but not in others... In other words "Will setting color class X to color Y have the intended effect?" is not an easy question to answer. rephorm ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
