Referring to:
http://git.enlightenment.org/core/efl.git/commit/?id=6291c61556a531da874242830689e37362db1638
and follow on commits that init this and make use of it. Welcome to...
VPATH (:
>From now on all EFL code will be happy.... full of smiles... OR ELSE! :)
This is not final but it works (the core does) and will have to wait a bit for
fuller completion like url's etc. This is in now for "comment" to do
adjustments. No - it's not testedt because it's rather painful to unit test
because it relies on looking up things that are very user/system specific and
not isolatable in a test suite. i'd have to fake a whole user account/homedir
and syscalls that figure this out. it's going to get tested a fair bit anyway
because of where it sits. we'll get to that later.
Anyway what is VPATH?
VPATH = Virtual Path. it allows you to specify a file like you might in a shell
and other places. no longer do we just support:
file/whatever.jpg == ./file/whatever.jpg
./file/whatever.jpg
../file/whatever/jpg
/etc/file/whatever.jpg
we support these and now we ALSO do:
~/whatever/file.jpg
~username/whatever/file.jpg
(:tmp/whatever/file.jpg == /tmp/whatever/file.jpg (or where $TMPDIR etc. point)
(:home/whatever/file.jpg == ~/whatever/file.jpg
for these XDG dirs:
(:data/whatever/file.jpg == ~/.local/share/whatever/file.jpg
(:config/whatever/file.jpg == ~/.config/whatever/file.jpg
(:cache/whatever/file.jpg == ~/.cache/whatever/file.jpg
(:run/whatever/file.jpg == /var/run/1000/whatever/file.jpg
(:desktop/whatever/file.jpg == ~/Desktop/whatever/file.jpg
(:documents/whatever/file.jpg == ~/Documents/whatever/file.jpg
(:downloads/whatever/file.jpg == ~/Downloads/whatever/file.jpg
(:music/whatever/file.jpg == ~/Music/whatever/file.jpg
(:pictures/whatever/file.jpg == ~/Pictures/whatever/file.jpg
(:public/whatever/file.jpg == ~/Public/whatever/file.jpg
(:templates/whatever/file.jpg == ~/.Templates/whatever/file.jpg
(:videos/whatever/file.jpg == ~/Videos/whatever/file.jpg
added this one for future e/efl support for user installed apps:
(:apps/whatever/file.jpg == ~/Applications/whatever/file.jpg
and of course if you set up an app with elm correctly so its relocatable and
can find its own prefix (terminology and rage do this for example - see their
app init stuff):
(:app.dir/whatever/file.jpg == PREFIX/whatever/file.jpg
(:app.bin/whatever/file.jpg == PREFIX/bin/whatever/file.jpg
(:app.lib/whatever/file.jpg == PREFIX/lib/whatever/file.jpg
(:app.data/whatever/file.jpg == PREFIX/share/APPNAME/whatever/file.jpg
(:app.locale/whatever/file.jpg = PREFIX/share/locale/whatever/file.jpg
and runtime useful stuff for an app:
(:app.config/whatever/file.jpg == ~/.config/APPNAME/whatever/file.jpg
(:app.cache/whatever/file.jpg == ~/.cache/APPNAME/whatever/file.jpg
(:app.data/whatever/file.jpg == ~/.local/share/APPNAME/whatever/file.jpg
note that on different os's these may move around - the point of vpath is to
handle this. these special keys are not final and up for comment. in addition
to the good old shell:
~/
~user/
all the special location start with HAPPINESS:
(:something/
so from now on your efl can can .. and WILL be happy... or else. (:
the above key set will expand most likely. i have some notes on some other
system locations to deal wwith. also note that this currently doesnt have any
windows etc. special handling - and no sox special handling. it should though.
eg handle an app dir structure on osx. handle windows paths for the above too.
i have glued this into ecore to do basic init (so you need ecore) and
elementary will init all the app.* ones when elm inits your app. things still
to do:
(:efl.*/
namespace - bin/lib/data/etc. for efl. right now efl data though is fragmented
in evas, edje, elementary etc. dirs and we likely need to fix this in our build
(over time) so all be in PREFIX/share/efl/...
any other namespaces we need to handle? comment. discuss.
right now i have just made evas image objects (legacy and eo) use vpath in a
very simple way. it's blocking. vpath CAN be async but these parts of efl
currently dont do async opens of images and when this is fixed, vpath usage can
be async. why do we care about async? well here is why. in FUTURE we will do:
file:/// ... this requires we handle escaping of the uri with %23 %c7 etc. etc.
stuff and i wanted to get this in for comment before bothering with that....
http://...
https://...
ssh:user@machine:...
etc. - these will require vpath actually fetch/cache the file, downloading it
and then finally waking up giving the resulting local "cached tmp file" path.
this of course requires mainloop object support to be used/glued in ... thus
why vpath is initted when ecore inits. i can get to this when a mainloop object
can be glued in.
i imagine in future it will also handle things like removable storage and
mountpoint mapping so maybe you will have somethnig like:
(:media:sdcard/....
or use the actual name of the mounted volume (if the filesystem had a name) like
(:media:My Photos/...
of course we'd need some way to list available "removable devices" and
events/callbacks to indicate they have come or gone etc. - this require
integration with core system daemons/services of course.
vpath is also not fixed. there is a vpath_manager class. you ask the path
manager to give you a path file given an input file path. vpath manager lets
you register vpath objects with the manager and a given priority (efl's default
vpath core object is at priority 0). this allows any app (or library) to create
more vpath objects that are used first before efl's core handler and thus can
override it. you can implement your own virtual path mapping and even
downloading/protocol handling and caching if you want this way. so it's
extensible by apps and libraries. the vpath manager iterates over vpath objects
registered and asks them to provide a vpath file for the input path string. the
first one to answer with a valid file object "wins" and returns the object to
the caller. you must keep the object around for as long as you use the file
because of the future possibility of downloading/caching. this keeps a
reference open to the file making sure it exists.
i've glued in the evas image object right now to use vpath to show quickly how
it works. this is in a following commit. before i go and do edje and emotion
(at which point i think i've covered what needs to be in efl), i'd like some
comments on it.
VPATH is NOT a VFS. it does not and never intends to sit as a whole fs
abstraction. this is a far far far bigger project with far more implications.
this is a very simple low-level feature that can get you a real normal file to
mess with so it works with libraries and code that dont have a vfs abstraction.
if you use vpath directly from your app to get file paths mapped you can just
use fopen() on them etc.
now why do this? isn't this simpler:
efl_file_set(obj, "~/file.jpg");
vs:
char buf[PATH_MAX];
snprintf(buf, sizeof(buf), "%s/file.jpg", eina_environment_home_get());
efl_file_set(obj, buf);
or:
efl_file_set(obj, "(:app.data/mydata.jpg");
vs.
char buf[PATH_MAX];
snprintf(buf, sizeof(buf), "%s/mydata.jpg", elm_app_data_dir_get());
efl_file_set(obj, buf);
or it's even worse for "~username/file.jpg" or having to handle different env
vars and fallback paths for $TMPDIR vs $TEMPDIR vs $TMP vs $TEMP ... vs a
fallback of /tmp ? that becomes a lot more code like:
efl_file_set(obj, "(:tmp/mydata.jpg");
vs.
char buf[PATH_MAX], *s;
s = getenv("TMPDIR");
if (!s) s = getenv("TMP");
if (!s) s = getenv("TEMPDIR");
if (!s) s = getenv("TEMP");
if (!s) s = "/tmp";
snprintf(buf, sizeof(buf), "%s/mydata.jpg", s);
efl_file_set(obj, buf);
similar for the XDG_* env vars vs fallbacks... this is a huge code simplifier
and a huge help for things like gui builders that can now address application
resources with a virtual path like "(:app.data/resource-name" when
generating app source code and it doesnt need to worry about generating tmp
buffers ... and yes it opens up the door to handling http etc.
right now elm_image handles http:// specially. emotion also does http://
because the media codecs do it. with vpath we have everything work the same in
the same way with a single shared implementation for download/cache/share (of
course emotion special cases http/https:// because it will stream not download
and play and can override it).
anyway... i hope this gives an overview of what vpath is and why its at the
core of efl and why it's useful and how it improves things. :)
p.s.
yes i do know that in c++, js, lua etc. you can concatenate strings really
easily but these cant solve more complex things like file:// parsing/escaping
or url handling and protocol with http/https/ssh etc. but this doesnt help
solve C. it just avoids it. this above now solves it the same way for
everyone regardless of language (:
so go forth... and BE HAPPY!
(:
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
