this is the correct way to write a build system. one toplevel Makefile.am with the rest of the directories having include Makefile.mk files.
additional authors:
Iván Briano <ivan.briano@intel.com>
I'm sure some of you have seen the warnings generated by libpng 1.6:
"known incorrect sRGB profile". Now, this is no big deal, it's just a
warning, but I still wanted to look into it further. By my count,
there are 800 png files in Enlightenment, of which only 6 have
embedded iCC profiles, all from HP. The rest are sRGB colorspace, but
do not include a profile. There are some good arguments for this
(http://imageoptim.com/color-profiles.htmlhttp://www.gballard.net/psd/save_for_web_embed_ICC_profile.html)
and since this seems to be the default, I've attached the 6 files with
the profiles stripped out. As you can see, it doesn't change the image
or the colorspace, it just leaves the calibration up to the end user's
system.
I haven't been able to find just what's wrong with the HP iCC profile
being used that the authors of libpng don't like, but it makes sense
to standardize the way profiles are handled anyway. And it has the
nice side effect of silencing warnings, even if the Debian/Ubuntu
users aren't likely to see them for a couple of years.
I can just change the iCC profile instead if you would prefer. I've
seen multiple people recommend the Argyll sRGB profile, which is still
"sRGB IEC61966-2.1" and is public domain.
falls back to default of course if theme doesnt provide them) and this
works for EAP icons too - if you give your EAP icons an icon class
like "web_browser" and if the theme provides a theme override for icons of
class "web_browser" then the theme icon is used instead of the .eap internal
image. not surethis is perfect as u want more "specific" and "more general"
levels - maybe i should make the eapp icon class a list of classes the icon
is part of...
SVN revision: 15951
config / settings). Menu is built based on .edj themes
present in ~/.e/e/themes for now. Themes in
$PREFIX/share/enlightenment/data/themes are not taken into consideration at
this stage.
SVN revision: 14520
its just mime types exactly splatted out into a dir struct with .db at the
end (falling back to default.db and unknonw/unknown/db in the end if it cant
fall backto default.db)
now what i need is to talk to cK and get the file magic/mime type stuff to
beocme smarter even that it is.. so currently it sees a tar.gz file - it
looks at the magic and boom.. it thinks is a gzip file.. thats correct.. but
theres mroe to it.. now it woudl be good if the magic stuff coudl now also
inspect the inside of the gzip (ie use zlib in this case) and start lookign
ro a tar header to see if tis a tar.gz.... now if it si a tar.gz.. try
getting the file list and seeing if there are telltale signs of it being a
theme tarball or such (though this lats step may be going too far)
efsd definitely needs ot cache mime type though. that much i'm certain of :)
its not fast at all actually doing file magic on every file... every time
the directory is "loaded" :)
but excellent work! another pat on the back for ck :)
SVN revision: 4451