On Mon, 2 Mar 2009 10:29:28 +0900 Toma <[email protected]> wrote: > How do we set our theme and where is it to be installed? Is it going > to be a full Fd.o themeset or just enough to cover efm mime types? E > icons have always been a tricky mess. However, fd.o icons have been a > bit of a mess too.
Setting an icon theme has been possible for a long time. It's Appearance->Icon Theme. Right now the changes is just for efm icons, but could be used for more. In general though we can do all our icons as part of an FDO theme and any other themes could easily list our icon theme as a fallback so that no icons are missing. This is what KDE/Gnome do and any icon themes will usually inherit their respective default icon themes. Like Gustavo was saying, Tango seems less complete then Oxygen. This is probably due to KDE4 actually following some of the FDO specs more so then Gnome does. So themes made for KDE4 might be a bit better with this regard, but we would have to make our own anyway so it doesn't really matter. We make sure our icon theme follows the spec and any extra icons we need will just have to be enlightenment-*.png or whatever. But this should only be used if we absolutely cannot find a common icon that will work. > > On 3/2/09, Gustavo Sverzut Barbieri <[email protected]> wrote: > > Hello All, > > > > I just committed a major change to Enlightenment File Manager so it > > will use Efreet to load FreeDesktop.Org (FDO) mime types and > > associated icons. These icons will come from icon theme set at > > Settings -> Look -> Icon Theme and existence of icons will thus > > depend on it. For instance Tango does not provide "folder" icon, > > but Oxygen (KDE4) is very complete and looks really good. If icons > > are not found, then it will fallback to E17 theme default, so if > > you're using Tango you'll keep seeing E17 folder icon and not > > Tango's. > > > > With that change we can now remove most icons from E17 theme and we > > should create a freedesktop-compliant set. This is good because we > > can have KDE and Gnome to use or icons (or at least most of them!) > > and make look & feel similar, improving usability. So we need > > artists (Toma? ManoWarrior?) to take care to provide such set. > > > > I'd like to ask themers/artists to look at E17 icon usage and try to > > see if icons could use the standard naming scheme, so we share more. > > Please see > > http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html > > > > Worth noting that at least on e17 code we still alow .edj icons, not > > sure about Efreet but we could fix it to allow that as well. With > > that we can still have nice animated icons using our technology and > > not restrict to boring PNGs. > > > > Last but not least, it's not all happiness. Efreet is potentially > > not as fast as we hope it could be. The cache needs to be > > fixed/improved, we need to really speedup mimetype caching and icon > > finding. So if you find out slow cases, report. If you have coding > > skills, try to improve. Ask me (k-s) or Nicholas Hughart (mekius) > > at IRC. Well there was a pretty good improvement caching wise, but there is probably more that can be done. It's mostly a matter of doing it wisely as to not soak up a ton of RAM. Eventually you'll cache most of the highly used icons, but those are not saved for future runs. Could save this cache to disk and reload it during init the next time. This way the only time we get any tiny slowdown will be during lookups of brand new icons and only the very first time that icon loads. This cache of course would essentially become invalid if the icon theme is changed or something though, but a small bit of slowness shouldn't be a big deal for long term usage. Also how many times would a person be changing their icon theme outside of testing new ones? Once you find one you'll usually stick with it for awhile. Another option is to cache all images in all themes, but that would probably have to go into a file as it could easily consume a lot of RAM. Looking up an icon would be a lot faster this way then searching through directories everytime we need a new icon. Plus we could set it up so it's grouped/ordered/indexed which would make searching even faster. This cache would have to be updated for any changes in the directory structure, but it could be smart by using file monitors and doing it in idle time. Might also want to do a check during init to make sure all paths are still valid and add any new ones, but again could be done in idle time to help avoid any large slowdowns with the application. If there is need to request an icon not in the ram or disk caches then it could do the slow check and stored in the ram cache right away (eventually will end up in disk cache in idle time). I think we still need the ram cache for heavily used icons or we'll end up killing the disk with icon requests. I could just be talking out of my ass here, just throwing out ideas, not sure of all the details. I don't claim to be an expert in this :) > > > > Regards, > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -------------------------------------- > > MSN: [email protected] > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > > ------------------------------------------------------------------------------ > > Open Source Business Conference (OSBC), March 24-25, 2009, San > > Francisco, CA -OSBC tackles the biggest issue in open source: Open > > Sourcing the Enterprise -Strategies to boost innovation and cut > > costs with open source participation -Receive a $600 discount off > > the registration fee with the source code: SFAD > > http://p.sf.net/sfu/XcvMzF8H > > _______________________________________________ enlightenment-devel > > mailing list [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA -OSBC tackles the biggest issue in open source: Open > Sourcing the Enterprise -Strategies to boost innovation and cut costs > with open source participation -Receive a $600 discount off the > registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ enlightenment-devel > mailing list [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
