On Wed, 12 Jul 2017 19:21:47 -0400 Christopher Michael <cp.mich...@samsung.com> said:
> On 07/12/2017 07:08 PM, Simon Lees wrote: > > > > > > On 13/07/17 01:59, Stephen Houston wrote: > >> Yep. Understand. Just figured I'd throw it out there since it will need to > >> be backported to this release and others anyway... > >> > > > > Why? we only really backport bugfixes not new features. No one will run > > e22 with a older version of efl, > > Umm .. history says otherwise. People will try.... just make it a requirement at compile time. that SHOULD translate to it being also a minimum req at package time if done right... e can also check versions at runtime too - efl does expose its version in the efl_version struct... > so just bump the minimum efl > > requirement for e22 to 1.21, if e22 was going to be released in the next > > month or so there might be a case for including it in efl 1.20 now, > > E fallows it's own release schedule.,... > > but I > > don't think thats likely. > > > > Perhaps not...doesn't stop people from trying to run versions that are > not meant to work together... see above. :) > I believe Stefan's stance is that this could be considered a "new > feature"...one not tested by the majority of people, and therefore > cannot be certain that condensed code would be wiser... > > <quote> > I have nothing against the idea and getting rid of code duplication is a > >>> good goal as well > </qoute> > > My stance: > <quote> > I do not think we should start this now, so late > in the stabilization schedule. > </quote> agreed. leave it for 1.21 to clean up (ie wait for 1.20 to be out then push your cleanup from a branch or do the work then and have it tested for a few weeks/months from git before 1.21). > dh > > >> On Wed, Jul 12, 2017, 11:18 AM Stefan Schmidt <ste...@osg.samsung.com> > >> wrote: > >> > >>> Hello. > >>> > >>> On 07/12/2017 04:17 PM, Stephen Houston wrote: > >>>> Sorry that I have missed bringing this up before: > >>>> https://phab.enlightenment.org/T4996 > >>>> > >>>> This has been around for a while... I have the code and it is simple: > >>>> in elm_image_file_set, if the file extension is .desktop, then create an > >>>> Efreet_Desktop *desktop object and do the following: > >>>> const char *path = NULL, *key = NULL; > >>>> char buf[4096]; > >>>> if (!desktop->icon) > >>>> path = NULL; > >>>> else if (strncmp(desktop->icon, "/", 1) && > >>>> !ecore_file_exists(desktop->icon)) > >>>> { > >>>> clamp = (4 * round((double)ic->inst->size/4)); > >>>> path = efreet_icon_path_find(e_config->icon_theme, > >>>> desktop->icon, clamp); > >>>> if (!path) > >>>> { > >>>> if (e_util_strcmp(e_config->icon_theme, "hicolor")) > >>>> path = efreet_icon_path_find("hicolor", > >>> desktop->icon, > >>>> clamp); > >>>> } > >>>> } > >>>> else if (ecore_file_exists(desktop->icon)) > >>>> { > >>>> path = desktop->icon; > >>>> } > >>>> if (!path && desktop->icon) > >>>> { > >>>> snprintf(buf, sizeof(buf), "e/icons/%s", desktop->icon); > >>>> if > >>>> (eina_list_count(e_theme_collection_items_find("base/theme/icons", buf))) > >>>> { > >>>> path = e_theme_edje_file_get("base/theme/icons", buf); > >>>> k = buf; > >>>> } > >>>> else > >>>> { > >>>> path = e_theme_edje_file_get("base/theme/icons", > >>>> "e/icons/unknown"); > >>>> k = "e/icons/unknown"; > >>>> } > >>>> } > >>>> else if (!path && !desktop->icon) > >>>> { > >>>> path = e_theme_edje_file_get("base/theme/icons", > >>>> "e/icons/unknown"); > >>>> k = "e/icons/unknown"; > >>>> } > >>>> if (path && desktop->icon && !k) > >>>> { > >>>> len = strlen(desktop->icon); > >>>> if ((len > 4) && (!strcasecmp(desktop->icon + len - 4, > >>>> ".edj"))) > >>>> k = "icon"; > >>>> } > >>>> Then just set the path and key. The e_theme_edje* stuff of course would > >>> be > >>>> substituted with elm theme stuff of course. > >>>> No need for anything special in image_file_get as the path and key set in > >>>> file_set would return normally. > >>>> > >>>> This would allow a TON of redundant code throughout E and potentially > >>> other > >>>> places to be removed and elm_icon to fully replace e_icon. I'm also sure > >>>> this would be helpful for other apps that would have a need to load a > >>>> .desktop's image. > >>>> > >>>> This would be very simple to add to elm_image_file_set, with the catch > >>>> being it probably should be backported to other efl releases as well. I > >>>> really think this is a necessary functionality that should exist and is > >>>> warranted. With the simplicity of adding the code, if someone who is > >>> more > >>>> familiar with the current layout of the eo and elm stuff and who is more > >>>> familiar with backporting than I am would apply this, I think it is very > >>>> necessary. > >>>> > >>>> Again, sorry for the late notice. Thoughts? > >>> > >>> Right now we are looking at showstopper bugs that would block a release. > >>> Not at new features suitable for re-factoring parts of the code base. > >>> > >>> I have nothing against the idea and getting rid of code duplication is a > >>> good goal as well, but I do not think we should start this now, so late > >>> in the stabilization schedule. > >>> > >>> regards > >>> Stefan Schmidt > >>> > >>> > > > > ------------------------------------------------------------------------------ > 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 > 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) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
