On Mon, 22 Aug 2016 23:49:05 +0200 thomasg <tho...@gstaedtner.net> said:
> On Mon, Aug 22, 2016 at 10:41 PM, Stephen okra Houston < > smhousto...@gmail.com> wrote: > > > okra pushed a commit to branch master. > > > > http://git.enlightenment.org/apps/ephoto.git/commit/?id= > > 813471f9bd6048026b372b4b55b303a311d4335e > > > > commit 813471f9bd6048026b372b4b55b303a311d4335e > > Author: Stephen okra Houston <smhousto...@gmail.com> > > Date: Mon Aug 22 15:41:28 2016 -0500 > > > > Ephoto: Save thumbnails in $HOME/.thumbnails > > --- > > src/bin/ephoto_thumbnailer.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/bin/ephoto_thumbnailer.c b/src/bin/ephoto_thumbnailer.c > > index 0fe190e..3ea8709 100644 > > --- a/src/bin/ephoto_thumbnailer.c > > +++ b/src/bin/ephoto_thumbnailer.c > > @@ -88,7 +88,7 @@ main(int argc, > > ecore_file_init(); > > ecore_ipc_init(); > > > > - snprintf(_thumbdir, PATH_MAX, "%s/.config/ephoto/thumbnails", > > getenv("HOME")); > > + snprintf(_thumbdir, PATH_MAX, "%s/.thumbnails", getenv("HOME")); > > ecore_file_mkpath(_thumbdir); > > > > if (_e_ipc_init()) ecore_main_loop_begin(); > > > > -- > > > > > > > Hi okra, > > I think it would be best here to comply to the existing XDG standard > regarding to thumbnail caching. > https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#DIRECTORY > Basically just check if XDG_CACHE_HOME exists, if so put it there, else > keep it like you have it now. 1. i agree with netstar - it should likely be ~/.cache/ephoto/thumbnails 2. these ar not xdg thumbnails. xdg thumbs require files be png or jpg. the thumbs written are eet files. they do not conform to xdg thus cant be re-used. they stor not just a thumbnail but ALSO other metadata used for doing things like sorting images visually etc. (they have an image description that can more easily give you a hash id that lets you linearly sort images by similarity like you sort strings alphabetically). xdg may have standards, but many of them are very limiting or exceedingly inefficient (yes for example the image id above could be written to a file alongside the image like xxx.id next to xxx.jpg ... BUt then we'd consume a WHOLE file for maybe 80-300 or so bytes of data which given how filesystems work often consumes between 512 bytes and 4, 8 or 32k, so it is FAR MORE efficient to put it into the same archive file - the eet file, that we store the thumbnail in... and eet can lossy compress like jpeg so other than a header will consume the same amount of data as a jpg file of the same quality). just because a standard exists does not meant it has to be followed. it's a case by case basis on value vs limitation vs performance. standards generally involve conforming to the lowest common denominator. that's sometimes ok. sometiems it's necessary because the VALUE gained by doing so is so great, but sometimes it's just not worth it. let me take a sideline into efreet. efreet is exceedingly complex. it was improved with its caching system, but i'm currently bsy cutting more memory usage from efl by fixing efreet... and i can tell you that by totally supporting xdg standards here directly in efl - we shot ourselves in the foot. before we did xdg, e would use .eap files. one per app. the contained metadata with the title/label, app execute line, an icon image etc. - all in a single file. drop it into a dir and e will pick it up. this was far simpler on our code. but then we dumped that all and moved to efreet and xdg. this has been a pain ever since. for xdg we have to recursively scan directories across multiple filesystem locations to load and parse text files to then hunt through more directory trees to find icons. scanning all of this at startup time is a huge cost. especially on a real HDD (not a luxury SSD). reality is we STILL have to scan all these dirs now to update our cache files we mmap() to get data from because the files on disk may have changed since we last looked. the xdg standards are horribly inefficient. the gnome/gtk peolpe even have pushed distros to run database updaters to udpate SYSTEM db files that shadow these xdg directory locations to avoid the inefficiency o the standard. we can't really push this much on disrtros so we have todo it every time you start e (or well efreetd). we run a whole daemon just to add directory and file monitors to see if these files change so it can spawn a "rescan everything" process that rebuilds the database then everyone opens the new db file (closes the old) and mmaps that in. it's complex. it's fragile. it's got lots of little buglets here and there. what we SHOULD have done is simply standardize ourselves a single big mmapable database file for ALL such metadata (icons, applications that can be run, mimetypes, mime magic and globs etc.) so we can just dumbly mmap this single file and monitor it, and if it changes... close it and re-open and re-mmap it. we should have a simple "importer" process that can scan a specific standard (xdg, one for windows, another for macos etc.) that can then import this data and create a single system-neutral format file to mmap and rummage through at runtime. at most a simple file monitoring process that just monitors any given set of files or dirs and runs a specific process when they change (the importer). yes it's similar to efreet now, but without a whole bunch of special casing and with efreet being portable - it's api should not Be xdg but something neutral that can work on different OS's. it's closer to e's original .eap files... if we had kept xdg standards at arm's length to begin with and kept things standard-neutral and simply where needed have a bridge between xdg and our data to import data... things would be far more efficient and far simpler. i am just fixing the efreet mime code and last night i was surprised.. i saved another 300k per process of real HEAP usage ... because efreet has to load all the "stabdards" and their files and deal with them. i'm moving it to a shared mmaped db file ... it's not pretty but it sure saves a chunk of memory ... in this case the standard does have value, but if we'd kept it at arms length and just used our own compact/efficient shared mmapable files for everything from day 1... i wouldn't have to be fixing things now... -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
