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