1. dont use a livethumb resolution OF THE SCREEN! per pager desktop
that means u alloc width*height*4 bytes... u have 6 desktops,
1920x1080 screen... thats 48mb for the backing images at full res. no!
bad bad! so i cut it down to 1/16th of the screen res. ie 1920/16 x
1080/16 for the full rest "livethumb". at least its much more
managable (i woke up to find after an update my e was using an EXTRA
100mb of ram! (2560x1440*4desk + 1920x1200*4desk).
2. dont create the livethumbs at all unless you have the bg preview
on! (i had it off and i still paid the price of the mem usage).
3. make the live preview inverted in the cfg gui - ie enable the live
preview, not disable it.
4. fix theme to preview bg fills the pager base box correctly within
the border bounds.
5. dont enforce aspect handling in livethumb as pager is "master" of
aspect (taken from desktop anyway).
SVN revision: 75154
people's crappy screens. something i noticed.
my screen displays gresy all the way down to about 0 where they
finally get black. light greys stay grey auntil almost 255. BUT...
here is the clincher. on the "crappy screens" i sawy.. black starts at
16 and white starts at 240. they literally lose 12.5% of the color
range at the extremes and thus a lot seems to just blend into black to
white and ultimately look bad especially if you are playing down in
the subtlle ends of the spectrum. so let's just assume people all have
crap screens and lighten dark things. :( how sad. also this assumes
people are incapable of or do not know how to adjust/fix the screen
color gammut. it may also be the screen does a crappy job of fixing
this itself (eg uses limtied 8bit mapping inside the screen where it
should be color correcting with a much higher fidelity using its
built-in temporal/spatial dithering logic it already has! crappy
screens!)
SVN revision: 74034
NOTE: This is a terrible mess. It trigger massive bug in Evas_Map.
Will try to fix the Evas part, but maybe we should use a custom code
and Evas_Object_Image with a custom pixels filling code.
SVN revision: 73928
This is used to open a file manager window from another process. It
will use DBus interface:
org.enlightenment.FileManager.OpenDirectory(path)
It returns immediately, but we could enhance the DBus interface and
make it act like a real file manager process if that is needed.
SVN revision: 73084