[haiku-development] Re: RFC: find_directory() API extension
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 03 Nov 2013 01:51:03 +0100
On 11/02/2013 09:58 PM, Axel Dörfler wrote:
Am 01/11/2013 16:23, schrieb Ingo Weinhold:
On 11/01/2013 10:35 AM, Axel Dörfler wrote:
Will non-packaged applications only get non-packaged paths this way?
find_paths() is independent of the caller. find_path() should return a
non-packaged path, iff codePointer refers to a non-packaged object.
But isn't it actually is yourself you care about the most? :-)
Absolutely! But what does that have to do with the API? ;-)
I mean, isn't it possible to determine the type of directories you want
to get by the path of the executable of the current team?
Not sure I follow your question. If you pass &main or, even simpler,
NULL as codePointer, it will refer to the executable. The path
find_path() returns will be that of the respective directory identified
by the baseDirectory argument in the same installation location. My
example once more:
char path[B_PATH_NAME_LENGTH];
find_path(NULL, NULL, B_FIND_PATH_DATA_DIRECTORY,
"foo/main-data", 0, path, sizeof(path));
When the program is installed in "/boot/system" (e.g.
"/boot/system/bin/foo"), "/boot/system/data/foo/main-data" will be
returned. When it is installed in "/boot/home/config/non-packaged",
"/boot/home/config/non-packaged/data/foo/main-data" will be returned.
Also, couldn't find_directory() have the same magic, and return always
the correct directory?
The directory_which constants passed to find_directory() identify
specific directories anyway -- e.g B_SYSTEM_DATA_DIRECTORY,
B_SYSTEM_NONPACKAGED_DATA_DIRECTORY, B_USER_DATA_DIRECTORY,
B_USER_NONPACKAGED_DATA_DIRECTORY -- and we can't really change their
semantics depending on where the executable of the application that
calls them lives (often code iterates through all of them). So we'd have
to introduce new neutral constants for that purpose. Since
find_directory() doesn't have a codePointer or similar parameter, it
would work only for the executable, not for library or add-on code, so a
new function is needed anyway.
I'd leave find_directory() as it is. It be there mostly for backward
compatibility. Its use would still make sense with the per-volume
constants or B_USER_SETTINGS_DIRECTORY. For the other cases find_path()
or find_paths() should be used.
Regarding find_paths(), I'm not sure it's worth doing a separate class
for it just for getting the paths. The only optional parameters are
subPath and flags and I think both will be commonly used.
I would just put it into the BPathFinder class as well, to have it all
in one place.
It would be a static method, since it doesn't need the constructor
arguments, but OK.
For convenience I was thinking of a BMergedDirectory initializer or
AddDirectories() method that would add paths found this way. It would be
nice to have a sub or wrapper class that would also add the node
monitoring support often needed.
Sounds lovely :-)
When will it be ready? ;-)
As usual: At the latest when you have finished implementing it. :-)
CU, Ingo
Other related posts:
