Nah Ephoto doesn't use it. Only e_icon widget in enlightenment that Im aware of, maybe EDI. For all of the .desktop handling in launchers, everything, ibar, luncher, efm, etc..., etc... been tested quite awhile in those places. So it shouldn't have much trouble being stable for 1.21
On Wed, Jul 12, 2017, 7:35 PM Christopher Michael <cp.mich...@samsung.com> wrote: > On 07/12/2017 08:15 PM, Stephen Houston wrote: > > No worries. It's been tested for a very long time as it resides in e_icon > > and has for a long time. It can go in Next release. > > > > Sounds great ! I'm sure it's been tested in Ephoto... ;) > > dh > > > On Wed, Jul 12, 2017, 7:11 PM Carsten Haitzler <ras...@rasterman.com> > wrote: > > > >> 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 > ------------------------------------------------------------------------------ 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
