[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Fw: Text color-classes in e17



On Sun, 12 Nov 2006 14:38:50 -0500
Christopher Michael <cpmichael1@comcast.net> wrote:

> Brian Mattern wrote:
> > On Sun, 12 Nov 2006 03:40:17 -0500
> > Christopher Michael <cpmichael1@comcast.net> wrote:
> > 
> >> Brian Mattern wrote:
> >>> On Sat, 11 Nov 2006 16:09:42 -0500
> >>> Christopher Michael <cpmichael1@comcast.net> 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