[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:13:09 -0600 Brian Mattern <brian.mattern@gmail.com>
babbled:

> 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.

aye... fine jar of pickles we have. as with many things - i am thinking about
this - but have nothing elegant yet. in the end you will likely end up with a
"try and see if the color changes" and if it doesn't - well theme doesn't honor
that colorclass spec.

> 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
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)