Hi Don,
Sorry for the delay to respond. I read the questions in your blog. Indeed, you are correct in your conclusion that "LPub3D search strategy makes use of the LDrawIni codebase, but takes some shortcuts on the LDrawIni approach."
In fact, I've incorporated the LDrawini class and I also make use of LDView's codebase to instantiate the search directories. Keep in mind that the LDrawini class' purpose is to process the ldraw.ini configuration settings - it passes the "hard coded" defaults if unable to process the .ini file. One must still write something to initialize and process the search directories passed by LDrawini - this is what the ldsearchdirs class does.The ldsearchdirs class also supports other functionality in LPub3D like resetting the search dirs in preferences.
The LDSEARCHDIRS environment variable is unique to LPub3D in that its purpose is to pass to ldglite a processed set of search directories. The LDSEARCHDIRS list is a '|' delimited list of directories that does not include Unofficial P and Parts because those directories are already searched by ldglite. In the event LDrawini is not used, i.e. no LDraw.ini configuraiton file found, LPub3D will populate LDSEARCHDIRS with all Unofficial sub-directories except P and Parts. You can see more details on this behavior in the LPub3D README file.
For LPub3D's use case, I did not implement LDrawini in ldglite because I did not want to engage un-necessary cycles searching arbitrary directories on each image submission. Instead, I just passed the explicit directories I wanted searched to preserve ldglite's performance advantage.
So to conclude, I would keep the LDSearchdirs code for two reasons: 1. Performance advantage, 2. If LDrawini is not used (no ldraw.ini file) ldglite will still be able to process multiple search directories prepared by LPub3D.
Regards,
Sorry for the delay to respond. I read the questions in your blog. Indeed, you are correct in your conclusion that "LPub3D search strategy makes use of the LDrawIni codebase, but takes some shortcuts on the LDrawIni approach."
In fact, I've incorporated the LDrawini class and I also make use of LDView's codebase to instantiate the search directories. Keep in mind that the LDrawini class' purpose is to process the ldraw.ini configuration settings - it passes the "hard coded" defaults if unable to process the .ini file. One must still write something to initialize and process the search directories passed by LDrawini - this is what the ldsearchdirs class does.The ldsearchdirs class also supports other functionality in LPub3D like resetting the search dirs in preferences.
The LDSEARCHDIRS environment variable is unique to LPub3D in that its purpose is to pass to ldglite a processed set of search directories. The LDSEARCHDIRS list is a '|' delimited list of directories that does not include Unofficial P and Parts because those directories are already searched by ldglite. In the event LDrawini is not used, i.e. no LDraw.ini configuraiton file found, LPub3D will populate LDSEARCHDIRS with all Unofficial sub-directories except P and Parts. You can see more details on this behavior in the LPub3D README file.
For LPub3D's use case, I did not implement LDrawini in ldglite because I did not want to engage un-necessary cycles searching arbitrary directories on each image submission. Instead, I just passed the explicit directories I wanted searched to preserve ldglite's performance advantage.
So to conclude, I would keep the LDSearchdirs code for two reasons: 1. Performance advantage, 2. If LDrawini is not used (no ldraw.ini file) ldglite will still be able to process multiple search directories prepared by LPub3D.
Regards,