Toma wrote: > 2008/7/28 Peter Wehrfritz <[EMAIL PROTECTED]>: > >> Toma schrieb: >> >>> It would be nice to have a bit more unity when it comes to Icons in E >>> and in particular, EFM. Im not entirely sure what to file a bug on >>> here since its kind of splatter over a few files. Basically, the icons >>> for EFM need to be set in 3 different places to work as a single icon >>> theme. There is some initial support for using the FDO standard icons >>> in 'e_fm_hal' around line 254 then in 'e_fm_mime' is starts doing >>> things differently again by looking in .e/e/icons (i dont think thats >>> a FDO standard icon dir). >>> So is there a way to unify all these icons so theyre taken directly >>> from the 'Icon Theme' selector? >>> >>> >> If you are talking about mime-icons, then the fdo icons aren't unfortunately >> a good choice atm. Most mime icons don't even exist for the tango theme, or >> they exist but under a different name. Before this isn't fixed it isn't >> possible to use fdo icons for mime icons. >> >> Peter >> >> > > It wouldnt be that hard actually. The filenames themselves are > basically all similar in some way. > eg. > > pdf.png > mime-application-x-pdf.png > gnome-mime-application-x-pdf.png <--- stupid tango names > > A lot of icon creators do the stupid thing of making links to cover > all the 'missing' icons. Ultimately, its a problem with the > application for not following the spec, rather than the icon theme but > the people that make the icons dont have the balls to say "FIX YOUR > DAMN PROGRAM". > > The spec for icon names has been around for 2 years and I do suspect > some applications dont follow the guidelines. If someone adds FDO > specific compatibility, i'd be more than pleased to put together a > script that swaps out all the badly names files with proper ones. Id > also be happy to send an email to every single icon theme maker > telling them to fix their themes. But really, all that needs to happen > is support for 1 icon filename per mime. if it isnt there, then dump > the unknown.png on the user and move along. If the icon theme doesnt > follow the standard, then it is broken. Simple as that. > > On that note, tango team made an 'icon-naming-utils' package that does > all that, but renames them to 'Tango' specific icons, that are stuffed > full of 'gnome' in the filenames. Quite daft really. > Peter is actually quite right in noting the problem with most icon themes. The authors of these icon themes don't usually read the specifications (at least it doesn't appear that way) and just create icons with names that work. Most icon themes I've run across don't have a lot of nicely named mime icons and thus finding icons becomes pretty nasty. To follow the spec you must actually look for these badly named icons which causes a lot of slow down. Would you like it to take more then a second or two to open a directory? Now this isn't to say that a good icon theme can't be done, but it's something that is hard to do when the specification mandates that you look for these crazily named icons anyway regardless of how good the icon theme is. You must search from most specific to least specific, which is fine when the icons are application-x-pdf.png and pdf.png, but when they start making you look for the word gnome and mime, it gets ugly. It would be great if the specification forced people to use icon names that were simple, but they don't and that's why it's not really worth the effort.
With all that said, I would still like to see a system where EFM looks for the icon in the e17 theme and uses the icon theme as a fallback. I have already coded the support for finding mimetype icons into efreet_mime. The issue stands though that most icon themes lack standard mimetype icons. For a quick benchmark I ran a test program on e17/apps/e/src/bin/ that finds the mimetypes for each file and the icon for that file. It took just under 2 seconds to find all the icons for this directory and it's only 441 files (.h, .c, .o, binaries). There was the argument that there should be caching and I agree there should be better caching. The caching mechanism in efreet_icon was changed at one point and it pretty much made it useless. Seb can comment more on that. Regardless, even in an uncached state, 2 seconds is quite a while to be looking for icons, and this is when 67% of the icons were found. If it couldn't find an icon for any of the files (which should never happen since all files have mimetypes, i.e. bad icon theme) it would take even longer. So at the moment I wouldn't put a lot of time into this. Hopefully icon themes will improve and this will be more of an option, but right now it's too slow and too flaky to be depended on. Most icon themes don't even supply good looking mime icons which just leads to blurry icons all over E's interface. > @Luca > Its interesting researching these icon themes and eye opening to how > much a lot of icon themes suck. :) If all that scripting is for > nothing, I dont care, as long as it bought to light the fact that we > need a script and to set the icon theme in 3 places for unification, > then im happy. > > Toma. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
