On Thu, 27 Jul 2017 17:13:40 -0400 "William L. Thomson Jr." <[email protected]> said:
> For the many benefits of EDJE. I think a major downfall is having to > rebuild a theme per every EFL update. Something seems very wrong with > that approach. there is no need to do that. what makes you think you have to rebuild your theme every efl update? if your theme is a direct copy of the default and it has a BUG... (well the default theme has/had a bug)... then your theme also has a bug. if we fix it in the default... you should also copy that. themes don't just define a color or a background. they define interaction and behaviour too. we have tried our best, and i have rejected patches and reverted commits because they were doing in a way that REQUIRED a theme to keep up. i suspect you are missing some key understanding of what edje is and how it works and how we use it for themes. the only case where you MIGHT want to keep up is when we add new theme elements. i.e. a new group. this is often used for a new widget etc. ... and if you do NOT provide it... things still work fine... but elementary will find the group from the default theme instead (it'll fall through to looking there) and it may not look "right". but this is really hard or nigh impossible to avoid. it's like css. you make a page and use classes for divs etc. ... but some new idea/design creates some new div with a class that never existed before. if you define a custom theme and you DON'T provide a css entry for that class that div is probably going to look odd. the "default" css maybe give it a thick top border, with a specific image in the bg with tiling and some specific padding etc. ... so it looks the part. maybe some css transitions specific to its behaviour (some js might initiate the transition on an event). so in this case if you have your html do: <link href=http://original.org/default.css rel=stylesheet> <link href=mytheme.css rel=stylesheet> this is how themes work. your theme is "mytheme.css". the original.org default one is always implicitly fallen through too... yours overrides. if a web page is using mytheme.css BUt it upgrades its content and uses new widgets from original.org - your mytheme.css wont style these well or maybe not at all... and edje works exactly this way, but it's more "all or nothing". the entire element is provided... or its not. so no. there is no need to rebuild. but if you have new features coming in and new widgets being added and so on then your overlayed mytheme.css (your theme edj file) might want to keep up as over time it'll not be styling new elements. but existing stuff will stay. > If one does not have to per se rebuild an EFL app per EFL release. Why > should one have to rebuild a theme? If an app is using say standard > stuff, that is not likely to change. Then rebuilding an app against > newer would provide little if any benefit or difference. > > Design wise I thought themes were separate from code so seems really > bad that themes must be rebuilt per every EFL release. That adds an > entirely new level of complexity to theming. Which IMHO is already > pretty complex. > > Things I can do easily in say gtk, qt, or others, like changing base > colors of things. Takes considerable time using EDJE. This is not meant > as an insult. But more request for consideration to make some things > easier to modify. we have the features. color classes. we just don't use them a lot in the default theme. we haven't standardized color class names api-wise. only group names, signals and specific part names for swallows, text etc. - it's just a massive amount of work to support because you also have to carefully design your images to wokr with colorclasses (as colors multiple pixel values so your images have to basically become all white with alpha and maybe greyscale and you have to break things up into multiple images layered if each needs to be colored differently and this also then costs overhead at runtime for rendering). look at colorclasses.edc in the default theme.... where you get to define the colors of "named color classes" (they do indirect to #defines there). all those color classes are changeable per edje object and globally at runtime. as i said - we just haven't formalized this at this point. the features have been there (along with text classes) for 13+ years or so. recently size classes were added too for being able to control sizing a (for padding). > Example > This gtkrc file is all I need to modify gtk theme colors to match my > eminence theme colors. Inheriting another theme > https://github.com/Obsidian-StudiosInc/eminence/blob/master/src/gtkrc-2.0 > > Doing the same with EDJE is very complex. One must rebuild the default > theme and/or make one of their own. Both I have done and am doing > presently with eminence. > > More importantly, I will vary rarely if ever have to touch that gtkrc > file again. I surely will not have to do anything with any theme for a > gtk update. Also has legacy compliance. That gtkrc-2.0 file works for > 3.0 stuff with no additional modifications. > > -- > William L. Thomson Jr. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
