On 07/12/2017 08:45 PM, Stephen Houston wrote:
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,

.desktop handling was something done years ago...how did it get lost ?

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


Cool


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



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

Reply via email to