| |
Several users have asked for an option to L3P for specifying additional search paths for parts.
LDView already has implemented "Extra Search Dirs" to search after the usual ones.
I think it would be of common interest and for the benefit of the community if we could agree on
THE way to do it, so I'll make the following proposal (as a starting point):
Two environment variables LDRAWPREDIRS and LDRAWPOSTDIRS
can be used to specify additional search directories.
Each variable can contain multiple directories separated by a |.
The search path will then be:
1. Inside the document if it is an MPD
2. The document's directory (the directory of the main model)
3. Any directories in %LDRAWPREDIRS%
4. %LDRAWDIR%\P
5. %LDRAWDIR%\PARTS
6. %LDRAWDIR%\MODELS
7. Any directories in %LDRAWPOSTDIRS%
Environment variables are preferred, because they work on all platforms.
However, on Windows, if they are not set, ldraw.ini is then checked.
A sample ldraw.ini may look like this:
[LDraw]
BaseDirectory=C:\LDraw
LgeoDirectory=C:\L2P
PreDirectories=C:\LDrawXtra\MyParts\In Work
PostDirectories=C:\LDrawXtra\MyParts\Done|C:\LDrawXtra\UnOff
Other namings: LDRAWDIRPRE, LDRAWDIRSPRE, - you name it!
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Several users have asked for an option to L3P for specifying additional search paths for parts.
> LDView already has implemented "Extra Search Dirs" to search after the usual ones.
>
> I think it would be of common interest and for the benefit of the community if we could agree on
> THE way to do it, so I'll make the following proposal (as a starting point):
>
> Two environment variables LDRAWPREDIRS and LDRAWPOSTDIRS
> can be used to specify additional search directories.
> Each variable can contain multiple directories separated by a |.
> The search path will then be:
> 1. Inside the document if it is an MPD
> 2. The document's directory (the directory of the main model)
> 3. Any directories in %LDRAWPREDIRS%
> 4. %LDRAWDIR%\P
> 5. %LDRAWDIR%\PARTS
> 6. %LDRAWDIR%\MODELS
> 7. Any directories in %LDRAWPOSTDIRS%
>
> Environment variables are preferred, because they work on all platforms.
> However, on Windows, if they are not set, ldraw.ini is then checked.
> A sample ldraw.ini may look like this:
> [LDraw]
> BaseDirectory=C:\LDraw
> LgeoDirectory=C:\L2P
> PreDirectories=C:\LDrawXtra\MyParts\In Work
> PostDirectories=C:\LDrawXtra\MyParts\Done|C:\LDrawXtra\UnOff
>
> Other namings: LDRAWDIRPRE, LDRAWDIRSPRE, - you name it!
> /Lars
I like this idea. Can you support delimiting paths by ';' instead of '|'? ';'
is more in line with the delimitation in the PATH environment varible.
-Orion
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> I like this idea. Can you support delimiting paths by ';' instead of '|'? ';'
> is more in line with the delimitation in the PATH environment varible.
Sure, I just chose | because ; is allowed in filenames.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Orion Pobursky wrote:
> > I like this idea. Can you support delimiting paths by ';' instead of '|'? ';'
> > is more in line with the delimitation in the PATH environment varible.
>
> Sure, I just chose | because ; is allowed in filenames.
Hey, you're right. I wonder how the Windows PATH variable handles
that. Probably it just doesn't work...
Anyhow, the unix PATH variable uses ':' as the delimiter (at least
with the bash shell). So maybe '|' is better, even though you need
to use quotes when setting the environment variable to avoid it being
interpreted as a pipe. Is there any other character that's illegal
in a directory name, but doesn't require quotes to get it into an
environment variable?
By the way, I like the idea of the two variables. Were you thinking
of searching all subdirs in these directories, or just the subdirs
explicitly mentioned in the parts files like 48 and S? Or were you
expecting the additional directories to contain the P, PARTS, and
MODELS directories, or some subset of them?
Don
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Several users have asked for an option to L3P for specifying additional search paths for parts.
> LDView already has implemented "Extra Search Dirs" to search after the usual ones.
just for the record. first time I came across custom folder support was in mid
november 2003 doing betatesting for mlcad's new release. for me one of the most
significant improvements in 3.01 'cos for the first time I could separate
unofficial parts from the official release or set up folders for
work-in-progress. at the same time doing also testing for LDView I asked Travis
if he could take over this feature and add support for custom folders to LDView.
> I think it would be of common interest and for the benefit of the community if we could agree on
agree
> THE way to do it, so I'll make the following proposal (as a starting point):
> Two environment variables LDRAWPREDIRS and LDRAWPOSTDIRS
> can be used to specify additional search directories.
> Each variable can contain multiple directories separated by a |.
> The search path will then be:
> 1. Inside the document if it is an MPD
> 2. The document's directory (the directory of the main model)
> 3. Any directories in %LDRAWPREDIRS%
> 4. %LDRAWDIR%\P
> 5. %LDRAWDIR%\PARTS
> 6. %LDRAWDIR%\MODELS
> 7. Any directories in %LDRAWPOSTDIRS%
MLCad handles the relative path and the scan order by new entries in its
MLCad.ini. it scans the folders at start-up and adds the findings to an internal
list(?). no new parts.lst gets written :-). having two parts of the same name it
ignores the second one: using Tore's boxed parts, the \Parts folder has to be
set above the \Parts\B folder. the custom parts show up or not (depending on the
flag) in the tree parts library as well as the parts preview window and behave
like official once located in the \parts folder. the search path supports
extended ASCII as well as blanks. this is just a short description how it works.
for technical details please ask Mike - I'm just the tester not the guru.
> Environment variables are preferred, because they work on all platforms.
> However, on Windows, if they are not set, ldraw.ini is then checked.
> A sample ldraw.ini may look like this:
> [LDraw]
> BaseDirectory=C:\LDraw
> LgeoDirectory=C:\L2P
> PreDirectories=C:\LDrawXtra\MyParts\In Work
> PostDirectories=C:\LDrawXtra\MyParts\Done|C:\LDrawXtra\UnOff
>
> Other namings: LDRAWDIRPRE, LDRAWDIRSPRE, - you name it!
> /Lars
again, I do not have the technical background and it would be absolutely
hazardous to make suggestions in that direction but wouldn't the ldconfig.ldr
file be the ideal place for such setting. the color meta discussion shows that
the ldconfig.ldr will inevitably become a container for general settings. why
having two distinct files for general system settings?
[thinking aloud mode ON]
Well, may be it's just me, but the limitations backward compatibility to ldraw
inflicts slowly becomes annoying. I really can't see the reason why I have to
separate dithered colors into subparts, because of a prog I never worked with.
[thinking aloud mode OFF]
my 0.02 euro,
w.
|
|
| |
In lugnet.cad.dev, Willy Tschager wrote:
> again, I do not have the technical background and it would be absolutely
> hazardous to make suggestions in that direction but wouldn't the ldconfig.ldr
> file be the ideal place for such setting.
No, because you already need the LDRAWDIR environment variable, or
ldraw.ini, or some other OS specific method to find the LDRAW directory.
And since directory paths have filesystem dependent quirks, it's probably
best to keep them out of ldconfig.ldr.
> the color meta discussion shows that the ldconfig.ldr will inevitably
> become a container for general settings. why
> having two distinct files for general system settings?
That's a good question. The best reason I can think of is that ldraw.ini
is specific to Windows, whereas ldconfig.ldr is specific to LDRAW programs.
Don
|
|
| |
Hi,
Just to give my two cents ...
"Lars C. Hassing" <sp.lars@am.hassings.dk> schrieb im Newsbeitrag
news:Hsw4I7.MxC@lugnet.com...
> Several users have asked for an option to L3P for specifying additional • search paths for parts.
> LDView already has implemented "Extra Search Dirs" to search after the
usual ones.
LDView got its implementation after a preview release of MLCAD 3.01, which
includes this feature already.
<SNIP>
The idea with environment variables is not bad, though there are two major
disadvantages against the methode implemented in MLCad (which uses some ini
file entries to define the search path, including an option for the user
wether the entry shell be visible for selection or not):
1) It doesn't allow to define paths inbetween the standard search paths,
which is a disadvantage sometime.
2) You do not have any chance to hide subparts and primitives from the users
view.
The implementation in MLCad uses ini file entries (currently MLCad.ini but
can be in any other file as well here I'm totaly open) and starts with a
section
[SCAN_ORDER]
followed by one or more path definitions, each beginning with either HIDE or
SHOW followed by the path. The path can contain spaces.
HIDE would make parts found in this path invisible to the user, but include
it when searching for parts, while SHOW would make the parts in this
directory visible to the user.
Example:
HIDE BFC\P
HIDE BFC\Parts
HIDE P
SHOW Parts
SHOW MODELS
SHOW MODELS\TEST
When looking for a part, MLCad will take the part first found going through
the directory list from top to bottom, other parts with same name in later
directories will be ignored. This mechanism allows the definition of
unofficial parts in a path following the official paths. Once the part
becomes official, the user would get the correct image without event have to
take care.
However and whatever comes out, I must say I would be rather disappointed if
the solution is totaly different from that what I invented and would have
less outcome for the user than my solution.
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> The idea with environment variables is not bad, though there are two major
> disadvantages against the methode implemented in MLCad (which uses some ini
> file entries to define the search path, including an option for the user
> wether the entry shell be visible for selection or not):
>
> 1) It doesn't allow to define paths inbetween the standard search paths,
> which is a disadvantage sometime.
> 2) You do not have any chance to hide subparts and primitives from the users
> view.
>
> The implementation in MLCad uses ini file entries (currently MLCad.ini but
> can be in any other file as well here I'm totaly open) and starts with a
> section
> [SCAN_ORDER]
>
> followed by one or more path definitions, each beginning with either HIDE or
> SHOW followed by the path. The path can contain spaces.
> HIDE would make parts found in this path invisible to the user, but include
> it when searching for parts, while SHOW would make the parts in this
> directory visible to the user.
>
> Example:
> HIDE BFC\P
> HIDE BFC\Parts
> HIDE P
> SHOW Parts
> SHOW MODELS
> SHOW MODELS\TEST
>
> When looking for a part, MLCad will take the part first found going through
> the directory list from top to bottom, other parts with same name in later
> directories will be ignored. This mechanism allows the definition of
> unofficial parts in a path following the official paths. Once the part
> becomes official, the user would get the correct image without event have to
> take care.
>
> However and whatever comes out, I must say I would be rather disappointed if
> the solution is totaly different from that what I invented and would have
> less outcome for the user than my solution.
I agree, however I'd like to point out that you could have started a
discussion here, before inventing your own personal solution. That's
what this forum is for.
Getting back to your example, I have some questions. Are all of those
paths relative to the LDRAWDIR? Do you allow absolute paths? Is the
directory containing the model file allowed to be moved around in the
SCAN order? How would you specify that?
Don
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hsxs1M.rIC@lugnet.com...
<SNIP>
> I agree, however I'd like to point out that you could have started a
> discussion here, before inventing your own personal solution. That's
> what this forum is for.
Ok right, but when I start discussing new features I'm going to implement
there will be a much bigger delay in new
MLCad version than we have now. The problem is that my time for MLCad is
rather small, and I would like to
spend my spare time for MLCad instead of doing discussions about what to
implement and how to implement.
Bad sign is, that since we started discussions about new features to be a
standard, we got definitly less output
of new features than befor. In the early days someone started a new feature,
used it, made its function public
and others hopped on. This worked great. Beside that I don't feel we are a
huge company which need a lot of
overhead on discussing hows things are working instead of doing - from that
I have enough in my daily job.
(Sorry but I get frustated slowly because the same thing is happening in the
company I employed at the moment)
>
> Getting back to your example, I have some questions. Are all of those
> paths relative to the LDRAWDIR? Do you allow absolute paths? Is the
> directory containing the model file allowed to be moved around in the
> SCAN order? How would you specify that?
Yes the paths are relative, absolute paths are not forseen at the moment,
but it wouldn't be a big deal to make them absolute or to even mix them.
You can move any of the directories arround however you like, and I must
ommit I didn't think about the current model directory. It would be possible
to add this feature in as e.g. SHOW [PROJECT-DIR] where the thing would be a
keyword. The problem is just that this path is known only after the
model has been saved once, if you save it under another name in a different
location it would change, and not find anything there anymore.
My approach here was to say that sub-models of a project shouldn't have any
official names anyway, but if there is one than I would assume that it would
be
an unofficial part, to be replaced by a official part once available. The
project path itself is currently the last one in the search.
Michael
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Willy Tschager wrote:
> > again, I do not have the technical background and it would be absolutely
> > hazardous to make suggestions in that direction but wouldn't the ldconfig.ldr
> > file be the ideal place for such setting.
>
> No, because you already need the LDRAWDIR environment variable, or
> ldraw.ini, or some other OS specific method to find the LDRAW directory.
> And since directory paths have filesystem dependent quirks, it's probably
> best to keep them out of ldconfig.ldr.
>
> > the color meta discussion shows that the ldconfig.ldr will inevitably
> > become a container for general settings. why
> > having two distinct files for general system settings?
>
> That's a good question. The best reason I can think of is that ldraw.ini
> is specific to Windows, whereas ldconfig.ldr is specific to LDRAW programs.
I think that in general it would be a bad idea to put anything like this in
ldconfig.ldr. The reason is that this file is distributed with parts updates,
so shouldn't contain anything specific to your particular system. Otherwise you
have to re-add your changes every time you get a parts update.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Anyhow, the unix PATH variable uses ':' as the delimiter (at least
> with the bash shell). So maybe '|' is better, even though you need
> to use quotes when setting the environment variable to avoid it being
> interpreted as a pipe. Is there any other character that's illegal
> in a directory name, but doesn't require quotes to get it into an
> environment variable?
I think old Mac's (before MacOSX) use : as directory delimiter.
> By the way, I like the idea of the two variables. Were you thinking
> of searching all subdirs in these directories, or just the subdirs
> explicitly mentioned in the parts files like 48 and S? Or were you
> expecting the additional directories to contain the P, PARTS, and
> MODELS directories, or some subset of them?
Only the specified directories. It's up to you to specify e.g.
LDRAWPOSTDIRS=C:\SomeDir\P|C:\SomeDir\PARTS
/Lars
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> "Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
> news:Hsxs1M.rIC@lugnet.com...
> <SNIP>
> > I agree, however I'd like to point out that you could have started a
> > discussion here, before inventing your own personal solution. That's
> > what this forum is for.
>
> Ok right, but when I start discussing new features I'm going to implement
> there will be a much bigger delay in new
> MLCad version than we have now. The problem is that my time for MLCad is
> rather small, and I would like to
> spend my spare time for MLCad instead of doing discussions about what to
> implement and how to implement.
>
> Bad sign is, that since we started discussions about new features to be a
> standard, we got definitly less output
> of new features than befor. In the early days someone started a new feature,
> used it, made its function public
> and others hopped on. This worked great. Beside that I don't feel we are a
> huge company which need a lot of
> overhead on discussing hows things are working instead of doing - from that
> I have enough in my daily job.
> (Sorry but I get frustated slowly because the same thing is happening in the
> company I employed at the moment)
Since MLCAD is for fun, you should work on it in whatever way makes you
happy. I guess you'll have to weigh the enjoyment you get from freely
implementing your own standards against any disappointment you may feel
if everyone doesn't agree with you later.
My personal preference is a quick discussion to get the ideas out, then
if a consensus is not reached, do what I like. Or in the case of the
colors in ldconfig.ldr, give up and wait forever. I admit, that's pretty
frustrating sometimes...
> > Getting back to your example, I have some questions. Are all of those
> > paths relative to the LDRAWDIR? Do you allow absolute paths? Is the
> > directory containing the model file allowed to be moved around in the
> > SCAN order? How would you specify that?
>
> Yes the paths are relative, absolute paths are not forseen at the moment,
> but it wouldn't be a big deal to make them absolute or to even mix them.
Yes, I think an absolute path would have to start with a slash or a drive
name so you should be able to tell them apart. You might want to consider
allowing absolute paths. Even on Windows an administrator could use the
CACLS command to make the LDRAWDIR read only for ordinary users. In that
case the only way to add directories to the SCAN_ORDER would be with
absolute paths.
> You can move any of the directories arround however you like, and I must
> ommit I didn't think about the current model directory. It would be possible
> to add this feature in as e.g. SHOW [PROJECT-DIR] where the thing would be a
> keyword. The problem is just that this path is known only after the
> model has been saved once,
OK, that means it's empty until then. I don't see a problem with that.
> if you save it under another name in a different
> location it would change, and not find anything there anymore.
That's true, but would it be any more of a problem than someone moving
the file to a different directory using Explorer? I suppose you could
have a preference setting, or pop up a dialog asking about the subfiles
when someone does a Save_As operation.
> My approach here was to say that sub-models of a project shouldn't have any
> official names anyway, but if there is one than I would assume that it would
> be an unofficial part, to be replaced by a official part once available.
> The project path itself is currently the last one in the search.
That's interesting. Lars had that listed first in the search list used
by L3P.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Michael Lachmann wrote: • [snip]
> > The project path itself is currently the last one in the search.
>
> That's interesting. Lars had that listed first in the search list used
> by L3P.
Yes, I thought we agreed on that long ago
http://news.lugnet.com/cad/dev/?n=5504&t=i&v=a
/Lars
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> The idea with environment variables is not bad, though there are two major
> disadvantages against the methode implemented in MLCad (which uses some ini
> file entries to define the search path, including an option for the user
> wether the entry shell be visible for selection or not):
>
> 1) It doesn't allow to define paths inbetween the standard search paths,
> which is a disadvantage sometime.
> 2) You do not have any chance to hide subparts and primitives from the users
> view.
So, it seems like the search candidates are:
<MODELDIR> (of the currently loaded model (PROJECTDIR))
<LDRAWDIR>\P
<LDRAWDIR>\PARTS
<LDRAWDIR>\MODELS
<LDRAWDIR>\AnotherDir
<LDRAWDIR>\AnotherDir\SubDir
C:\LDrawXtra\MyParts\In Work
C:\LDrawXtra\MyParts\Done
C:\LDrawXtra\UnOff
all with an option to hide them in certain programs.
How about
LDRAWSEARCH=<MODELDIR>|-<LDRAWDIR>\P|<LDRAWDIR>\PARTS|<LDRAWDIR>\MODELS
as the default (if LDRAWSEARCH is not set)
A full-blown example:
LDRAWSEARCH=-C:\LDrawXtra\MyPrims\In Work|C:\LDrawXtra\MyParts\In Work|
<MODELDIR>|-<LDRAWDIR>\BFC\P|-<LDRAWDIR>\BFC\PARTS|
-<LDRAWDIR>\P|<LDRAWDIR>\PARTS|<LDRAWDIR>\MODELS|
<LDRAWDIR>\MODELS\TEST|C:\LDrawXtra\MyParts\Done
Note that <MODELDIR> changes each time you load a new model.
/Lars
|
|
| |
As has already been stated, Willy asked if I could add a feature to LDView to
allow it to view models that are created in MLCad using the new feature of the
MLCad beta version. It seemed like a reasonable request, so I added the
feature, which made it into the latest LDView release.
Note that my implementation has some restrictions, which may or may not remain
in future versions. First of all, I only take absolute paths (selected
graphically). Second, all the extra directories get searched after the standard
directories.
Additionally, while LDView pays attention to the LDRAWDIR environment variable
and the ldraw.ini file, it doesn't modify either when the user graphically
chooses their ldraw directory. The same is true for my extra search
directories. If the community comes up with a standard way of specifying them,
I will likely add detection of this standard way to LDView, but I don't have any
particularly strong preferences about the form that "standard" specification
takes. I will also retain my LDView-specific way (accessed via my graphical
dialog box).
The thing is, while standard ways are good, it can be problematic to give the
user a graphical user interface to nicely configure things. I'm not sure how to
set permanent environment variables in Windows (or if it's even possible from a
user app). And while I could easily update the ldraw.ini file, I would feel
uncomfortable doing so, since LDView isn't the "owner" of that file.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > In lugnet.cad.dev, Orion Pobursky wrote:
> > > I like this idea. Can you support delimiting paths by ';' instead of '|'? ';'
> > > is more in line with the delimitation in the PATH environment varible.
> >
> > Sure, I just chose | because ; is allowed in filenames.
>
> Hey, you're right. I wonder how the Windows PATH variable handles
> that. Probably it just doesn't work...
>
> Anyhow, the unix PATH variable uses ':' as the delimiter (at least
> with the bash shell). So maybe '|' is better, even though you need
> to use quotes when setting the environment variable to avoid it being
> interpreted as a pipe. Is there any other character that's illegal
> in a directory name, but doesn't require quotes to get it into an
> environment variable?
Perhaps the delimiter character needs to be platform dependent? I realize that's not
an ideal solution for programs. But I don't think people will be shipping LDraw
search path settings between OS's, so it would be alright for users.
I don't think using the pipe character would be a good choice, for Windows or for
Linux (and Mac I guess). For Windows (and DOS), the semi-colon has a *strong*
precedent for use in path lists / search paths. Colon would not work at all for
Windows, but seems to be the character of choice for path lists in Linux/Mac.
Steve
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Michael Lachmann wrote: [snip]
> > > The project path itself is currently the last one in the search.
> >
> > That's interesting. Lars had that listed first in the search list used
> > by L3P.
>
> Yes, I thought we agreed on that long ago
> http://news.lugnet.com/cad/dev/?n=5504&t=i&v=a
> /Lars
Ok, I didn't get that. But it's not a problem to change that.
Finding things we or some agreed on is a hard job, when you do not know what you
are looking for, and follow the discussions regulary.
Michael
|
|
| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Anyhow, the unix PATH variable uses ':' as the delimiter (at least
> > with the bash shell). So maybe '|' is better, even though you need
> > to use quotes when setting the environment variable to avoid it being
> > interpreted as a pipe. Is there any other character that's illegal
> > in a directory name, but doesn't require quotes to get it into an
> > environment variable?
>
> Perhaps the delimiter character needs to be platform dependent? I
> realize that's not an ideal solution for programs. But I don't
> think people will be shipping LDraw search path settings between
> OS's, so it would be alright for users.
>
> I don't think using the pipe character would be a good choice, for
> Windows or for Linux (and Mac I guess). For Windows (and DOS), the
> semi-colon has a *strong* precedent for use in path lists / search
> paths. Colon would not work at all for Windows, but seems to be the
> character of choice for path lists in Linux/Mac.
I disagree with the idea of platform specific solutions, especially
since we're now thinking about including extra information in the list
(such as directives to hide certain paths) to make it more compatible
with the list used by MLCAD. If it's not exactly a list of paths,
perhaps we shouldn't make it look like one. In fact, maybe we should
use a completely different, yet familiar format like XML to describe
this list. I just don't want it to be too wordy and bloat the
environment.
I was initially squeamish about the pipe symbol because it requires
quotes to avoid being interpreted as a pipe directive. However, times
change. Filenames with spaces require quotes already so it's not such
a big deal anymore. Plus the semicolon approach is now broken, since
you can create filenames containing semicolons in Windows. I think
the benefits of writing one parser and one set of instructions
outweigh any perceived drawbacks. Besides, unsophisticated users will
probably use a GUI to set this path anyways.
Don
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > In lugnet.cad.dev, Don Heyse wrote:
> > > In lugnet.cad.dev, Michael Lachmann wrote: [snip]
> > > > The project path itself is currently the last one in the search.
> > >
> > > That's interesting. Lars had that listed first in the search list used
> > > by L3P.
> >
> > Yes, I thought we agreed on that long ago
> > http://news.lugnet.com/cad/dev/?n=5504&t=i&v=a
> > /Lars
>
> Ok, I didn't get that. But it's not a problem to change that.
>
> Finding things we or some agreed on is a hard job, when you do not know
> what you are looking for, and follow the discussions regulary.
Very true. Perhaps you should arrange for someone to email you
whenever we actually agree on something here. Since that seems to
be a rare occurance, it shouldn't be much of a burden on your
inbox. ;^)
Hmm, that'd be a nice addition to lugnet, eh? An automated mailer
bot that senses a certain level of agreement in the cad.dev group,
and then forwards matching posts to a mailing list.
Don
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Ht1H5p.1G0v@lugnet.com...
<SNIP>
> > Finding things we or some agreed on is a hard job, when you do not know
> > what you are looking for, and follow the discussions regulary.
>
> Very true. Perhaps you should arrange for someone to email you
> whenever we actually agree on something here. Since that seems to
> be a rare occurance, it shouldn't be much of a burden on your
> inbox. ;^)
>
> Hmm, that'd be a nice addition to lugnet, eh? An automated mailer
> bot that senses a certain level of agreement in the cad.dev group,
> and then forwards matching posts to a mailing list.
>
> Don
;-))))))
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Michael Lachmann wrote:
> > The idea with environment variables is not bad, though there are two major
> > disadvantages against the methode implemented in MLCad (which uses some ini
> > file entries to define the search path, including an option for the user
> > wether the entry shell be visible for selection or not):
> >
> > 1) It doesn't allow to define paths inbetween the standard search paths,
> > which is a disadvantage sometime.
> > 2) You do not have any chance to hide subparts and primitives from the users
> > view.
>
> So, it seems like the search candidates are:
> <MODELDIR> (of the currently loaded model (PROJECTDIR))
> <LDRAWDIR>\P
> <LDRAWDIR>\PARTS
> <LDRAWDIR>\MODELS
> <LDRAWDIR>\AnotherDir
> <LDRAWDIR>\AnotherDir\SubDir
> C:\LDrawXtra\MyParts\In Work
> C:\LDrawXtra\MyParts\Done
> C:\LDrawXtra\UnOff
> all with an option to hide them in certain programs.
>
> How about
> LDRAWSEARCH=<MODELDIR>|-<LDRAWDIR>\P|<LDRAWDIR>\PARTS|<LDRAWDIR>\MODELS
> as the default (if LDRAWSEARCH is not set)
>
> A full-blown example:
> LDRAWSEARCH=-C:\LDrawXtra\MyPrims\In Work|C:\LDrawXtra\MyParts\In Work|
> <MODELDIR>|-<LDRAWDIR>\BFC\P|-<LDRAWDIR>\BFC\PARTS|
> -<LDRAWDIR>\P|<LDRAWDIR>\PARTS|<LDRAWDIR>\MODELS|
> <LDRAWDIR>\MODELS\TEST|C:\LDrawXtra\MyParts\Done
>
> Note that <MODELDIR> changes each time you load a new model.
A bit wordy, but not bad. How about a few more predefined tags
for the standard directories to save environment space? Like using
<P> instead of <LDRAWDIR>\P, <PARTS> instead of <LDRAWDIR>\parts,
and <MODELS> instead of <LDDRAWDIR>\models?
What do you think of using / instead of \, or just allow either?
I assume you use the - for hidden directories. Since - is allowed
in paths, I think I'd prefer something a bit more obvious like <->
or even <HIDE> since that word is already used by MLCAD.
I'd also suggest putting the whole thing in quotes for the example
since that takes care of embedding any spaces and the | characters.
How about something like this?
SET LDRAWSEARCH="<HIDE>C:\LDrawXtra\MyPrims\In Work|
C:\LDrawXtra\MyParts\In Work|
<MODELDIR>|<HIDE><LDRAWDIR>\BFC\P|<HIDE><LDRAWDIR>\BFC\PARTS|
<HIDE><P>|<PARTS>|<MODELS>|<MODELS>\TEST|C:\LDrawXtra\MyParts\Done"
Don
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Ht6s7G.1792@lugnet.com...
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > In lugnet.cad.dev, Michael Lachmann wrote:
> > > The idea with environment variables is not bad, though there are two • major
> > > disadvantages against the methode implemented in MLCad (which uses some • ini
> > > file entries to define the search path, including an option for the • user
> > > wether the entry shell be visible for selection or not):
There is another disadvantage of this methode. Environment variables are
very system dependend and usualy are limited in there length. Personaly I
would prefere a methode in a .ini file in the MLCad form. Having the ini
file on a users home directory could be a good idea since users will have
write access to there home directory independend from the operating system.
The reason for using the MLCad.ini until now was to keep MLCad specific
settings there - but since its more public now I open to the location.
Michael
<Reset of message snipped>
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
>
> "Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
> news:Ht6s7G.1792@lugnet.com...
> > In lugnet.cad.dev, Lars C. Hassing wrote:
> > > In lugnet.cad.dev, Michael Lachmann wrote:
> > > > The idea with environment variables is not bad, though there are two major
> > > > disadvantages against the methode implemented in MLCad (which uses some ini
> > > > file entries to define the search path, including an option for the user
> > > > wether the entry shell be visible for selection or not):
>
> There is another disadvantage of this methode. Environment variables are
> very system dependend and usualy are limited in there length. Personaly I
> would prefere a methode in a .ini file in the MLCad form. Having the ini
> file on a users home directory could be a good idea since users will have
> write access to there home directory independend from the operating system.
> The reason for using the MLCad.ini until now was to keep MLCad specific
> settings there - but since its more public now I open to the location.
Yes, as Lars said earlier:
> > Environment variables are preferred, because they work on all platforms.
> > However, on Windows, if they are not set, ldraw.ini is then checked.
> > A sample ldraw.ini may look like this:
[LDraw]
BaseDirectory=C:\LDraw
LgeoDirectory=C:\L2P
LdrawSearch="<HIDE>C:\LDrawXtra\MyPrims\In Work|
C:\LDrawXtra\MyParts\In Work|
<MODELDIR>|<HIDE><LDRAWDIR>\BFC\P|<HIDE><LDRAWDIR>\BFC\PARTS|
<HIDE><P>|<PARTS>|<MODELS>|<MODELS>\TEST|C:\LDrawXtra\MyParts\Done"
I like the single LdrawSearch variable because it's easier for me to
pull out of the ldraw.ini file, but I'm willing to go with your format
for the ldraw.ini file if you allow absolute paths. Maybe something
like this?
[LDRAW_SEARCH]
HIDE "C:\LDrawXtra\MyPrims\In Work"
SHOW "C:\LDrawXtra\MyParts\In Work"
SHOW <MODELDIR>
HIDE <LDRAWDIR>\BFC\P
HIDE <LDRAWDIR>\BFC\PARTS
HIDE <P>
SHOW <PARTS>
SHOW <MODELS>
SHOW <MODELS>\TEST
SHOW C:\LDrawXtra\MyParts\Done
What's the equivalent of the home directory for a Windows user?
Possibly "C:\Documents and Settings\username\ldraw.ini"? How do you
find that. I checked the environment on Win2K and it looks like I
can use %USERPROFILE%\ldraw.ini but I'm not sure about other versions
of Windows.
Don
|
|
| |
Hi Don,
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Ht8vwM.ps2@lugnet.com...
> In lugnet.cad.dev, Michael Lachmann wrote: • <SNIP> >
>
> [LDraw]
> BaseDirectory=C:\LDraw
> LgeoDirectory=C:\L2P
> LdrawSearch="<HIDE>C:\LDrawXtra\MyPrims\In Work|
> C:\LDrawXtra\MyParts\In Work|
> <MODELDIR>|<HIDE><LDRAWDIR>\BFC\P|<HIDE><LDRAWDIR>\BFC\PARTS|
> <HIDE><P>|<PARTS>|<MODELS>|<MODELS>\TEST|C:\LDrawXtra\MyParts\Done"
>
> I like the single LdrawSearch variable because it's easier for me to
> pull out of the ldraw.ini file, but I'm willing to go with your format
> for the ldraw.ini file if you allow absolute paths. Maybe something
> like this?
Have you ever tried to pull out a variable under MS-Windows with a length of
500 characters? Or what would happen if the definition goes past 10 lines?
Using seperators like '|' I see potential for making errors. But you are
right its a possible solution.
Against that is that the ini file already contains sections, and we try to
mix logic and paths ... this is not a very clean solution.
However ....
>
> [LDRAW_SEARCH]
> HIDE "C:\LDrawXtra\MyPrims\In Work"
> SHOW "C:\LDrawXtra\MyParts\In Work"
> SHOW <MODELDIR>
> HIDE <LDRAWDIR>\BFC\P
> HIDE <LDRAWDIR>\BFC\PARTS
> HIDE <P>
> SHOW <PARTS>
> SHOW <MODELS>
> SHOW <MODELS>\TEST
> SHOW C:\LDrawXtra\MyParts\Done
I would suggest: Default is that the paths are based on the ldraw directory.
E.g.: MODELS\TEST or PARTS
If you want to have another folder different from the ldraw directory I
would use an absolute specification of the path. That means there are no
'<', '>' brackets in the path specification.
An absolute path can start with one of "\\", "/" or "C:".
E.g. C:\TEMP or /usr/home/mike or even \\server\share\directory\parts
The quotation marks are optional because you wouldn't need them, since the
first word is a keyword, every thing following is a path - but stop on some
operating systems they make sence because of blanks in path names - but
still let them optional.
Following my suggestions we would get:
[LDRAW_SEARCH]
HIDE "C:\LDrawXtra\MyPrims\In Work"
SHOW "C:\LDrawXtra\MyParts\In Work"
SHOW MODELDIR
HIDE BFC\P
HIDE BFC\PARTS
HIDE P
SHOW PARTS
SHOW MODELS
SHOW MODELS\TEST
SHOW C:\LDrawXtra\MyParts\Done
SHOW \\127.0.0.1\freedrive\public\ldraw\parts
HIDE /tmp/ldraw-temp-parts/
>
> What's the equivalent of the home directory for a Windows user?
> Possibly "C:\Documents and Settings\username\ldraw.ini"? How do you
> find that. I checked the environment on Win2K and it looks like I
> can use %USERPROFILE%\ldraw.ini but I'm not sure about other versions
> of Windows.
If you use an internet explorer function to get this directory it depends on
the version of internet explorer installed on the system.
The environment variables have been introduced with Windows NT and been
taken over to 98 and ME. I'm not sure about 95.
The variables are different in some versions, at least that is what I can
remember. But I'll check that.
>
> Don
Michael
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> I like the single LdrawSearch variable because it's easier for me to
> pull out of the ldraw.ini file, but I'm willing to go with your format
> for the ldraw.ini file if you allow absolute paths. Maybe something
> like this?
>
> [LDRAW_SEARCH]
> HIDE "C:\LDrawXtra\MyPrims\In Work"
> SHOW "C:\LDrawXtra\MyParts\In Work"
> SHOW <MODELDIR>
> HIDE <LDRAWDIR>\BFC\P
> HIDE <LDRAWDIR>\BFC\PARTS
> HIDE <P>
> SHOW <PARTS>
> SHOW <MODELS>
> SHOW <MODELS>\TEST
> SHOW C:\LDrawXtra\MyParts\Done
>
> What's the equivalent of the home directory for a Windows user?
> Possibly "C:\Documents and Settings\username\ldraw.ini"? How do you
> find that. I checked the environment on Win2K and it looks like I
> can use %USERPROFILE%\ldraw.ini but I'm not sure about other versions
> of Windows.
Something similar (but probably not identical to) the above would have my vote
(I'll explain below). I would clarify that if ldraw.ini can't be found in the
user's home directory (aka the user profile directory), then the Windows
directory should be checked. The %USERPROFILE% environment variable tells you
where the directory is, and if that variable doesn't exist, then skip that step
and fall back to the Windows directory. If the environment variable doesn't
exist in Windows 95, it doesn't really matter, because you know the Windows
directory will be writable.
I don't think the above can be used as-is, because I'm not sure it's kosher to
have lines like that in an ini file. Normally all the lines in an ini file have
an equals sign in them somewhere. For sections being parsed as sections,
instead of individual items, is it ok to forego the equals sign? As long as the
data is in an ini file, I want it to be a valid ini file.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> > [LDraw]
> > BaseDirectory=C:\LDraw
> > LgeoDirectory=C:\L2P
> > LdrawSearch="<HIDE>C:\LDrawXtra\MyPrims\In Work|
> > C:\LDrawXtra\MyParts\In Work|
> > <MODELDIR>|<HIDE><LDRAWDIR>\BFC\P|<HIDE><LDRAWDIR>\BFC\PARTS|
> > <HIDE><P>|<PARTS>|<MODELS>|<MODELS>\TEST|C:\LDrawXtra\MyParts\Done"
> >
> > I like the single LdrawSearch variable because it's easier for me to
> > pull out of the ldraw.ini file, but I'm willing to go with your format
> > for the ldraw.ini file if you allow absolute paths. Maybe something
> > like this?
>
> Have you ever tried to pull out a variable under MS-Windows with a length of
> 500 characters? Or what would happen if the definition goes past 10 lines?
> Using seperators like '|' I see potential for making errors. But you are
> right its a possible solution.
> Against that is that the ini file already contains sections, and we try to
> mix logic and paths ... this is not a very clean solution.
Right. In case the variable gets too long we can resort to multiple variables:
[LDraw]
BaseDirectory=C:\LDraw
LgeoDirectory=C:\L2P
LdrawSearch01=<HIDE>C:\LDrawXtra\MyPrims\In Work
LdrawSearch02=C:\LDrawXtra\MyParts\In Work
LdrawSearch03=<MODELDIR>
LdrawSearch04=<HIDE><LDRAWDIR>\BFC\P
LdrawSearch05=<HIDE><LDRAWDIR>\BFC\PARTS
LdrawSearch06=<HIDE><LDRAWDIR>\P
LdrawSearch07=<LDRAWDIR>\PARTS
LdrawSearch08=<LDRAWDIR>\MODELS
LdrawSearch09=<LDRAWDIR>\MODELS\TEST
LdrawSearch10=C:\LDrawXtra\MyParts\Done
LdrawSearch11=\\127.0.0.1\freedrive\public\ldraw\parts
LdrawSearch12=<HIDE>/tmp/ldraw-temp-parts/
and this goes for environment variables too: LDRAWSEARCH01, LDRAWSEARCH02, ...
> I would suggest: Default is that the paths are based on the ldraw directory.
> E.g.: MODELS\TEST or PARTS
>
> If you want to have another folder different from the ldraw directory I
> would use an absolute specification of the path. That means there are no
> '<', '>' brackets in the path specification.
> An absolute path can start with one of "\\", "/" or "C:".
> E.g. C:\TEMP or /usr/home/mike or even \\server\share\directory\parts
But then you would have to make a (platform dependent) path analyzer.
Also <LDRAWDIR>\MODELS\TEST is more readable to the user.
About the shortcuts <P>, <PARTS> and <MODELS> I guess they can be allowed
but they are not that necessary anymore - unless you want a single LDRAWSEARCH.
<MODELS> and <MODELDIR> might also lead to confusion.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Right. In case the variable gets too long we can resort to multiple variables:
> [LDraw]
> BaseDirectory=C:\LDraw
> LgeoDirectory=C:\L2P
> LdrawSearch01=<HIDE>C:\LDrawXtra\MyPrims\In Work
> LdrawSearch02=C:\LDrawXtra\MyParts\In Work
> LdrawSearch03=<MODELDIR>
> LdrawSearch04=<HIDE><LDRAWDIR>\BFC\P
> LdrawSearch05=<HIDE><LDRAWDIR>\BFC\PARTS
> LdrawSearch06=<HIDE><LDRAWDIR>\P
> LdrawSearch07=<LDRAWDIR>\PARTS
> LdrawSearch08=<LDRAWDIR>\MODELS
> LdrawSearch09=<LDRAWDIR>\MODELS\TEST
> LdrawSearch10=C:\LDrawXtra\MyParts\Done
> LdrawSearch11=\\127.0.0.1\freedrive\public\ldraw\parts
> LdrawSearch12=<HIDE>/tmp/ldraw-temp-parts/
>
> and this goes for environment variables too: LDRAWSEARCH01, LDRAWSEARCH02, ...
In DOS/Windows the problem with environment space is (I believe) more a problem
of limited total environment space. I don't think there's additional
limitations on individual variables. So using multiple environment variables
might conceivably make things worse.
Also, while I like the above (and it's very similar to the data I store in the
registry for LDView), I think we need to keep in mind here that Michael already
has the parsing working for the format he created. Consequently, unless we have
some pressing reason, I don't think it would be right to come up with a
different format that produces the same results as his format.
Unless we have some reason to find his format unacceptable, I think we should
only modify it by allowing absolute paths, moving the data into ldraw.ini
instead of MLCad.ini, and checking the user's home directory, then the windows
directory, for ldraw.ini. His comments so far seem to indicate that that would
be his preference.
Just my two cents.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > Right. In case the variable gets too long we can resort to multiple variables:
> > [LDraw]
> > BaseDirectory=C:\LDraw
> > LgeoDirectory=C:\L2P
> > LdrawSearch01=<HIDE>C:\LDrawXtra\MyPrims\In Work
> > LdrawSearch02=C:\LDrawXtra\MyParts\In Work
> > LdrawSearch03=<MODELDIR>
> > LdrawSearch04=<HIDE><LDRAWDIR>\BFC\P
> > LdrawSearch05=<HIDE><LDRAWDIR>\BFC\PARTS
> > LdrawSearch06=<HIDE><LDRAWDIR>\P
> > LdrawSearch07=<LDRAWDIR>\PARTS
> > LdrawSearch08=<LDRAWDIR>\MODELS
> > LdrawSearch09=<LDRAWDIR>\MODELS\TEST
> > LdrawSearch10=C:\LDrawXtra\MyParts\Done
> > LdrawSearch11=\\127.0.0.1\freedrive\public\ldraw\parts
> > LdrawSearch12=<HIDE>/tmp/ldraw-temp-parts/
> >
> > and this goes for environment variables too: LDRAWSEARCH01, LDRAWSEARCH02, ...
> In DOS/Windows the problem with environment space is (I believe)
> more a problem of limited total environment space. I don't think
> there's additional limitations on individual variables. So using
> multiple environment variables might conceivably make things worse.
ME and the NT variants store the environment in the registry so
this would only make things worse for 95 and 98. That said, I'd
still prefer to keep things short for the environment version of
this. One variable, with as many shortcuts as possible to limit
the size. If you need more, you should be using the ini file or
some other platform specific solution. The example above uses
less than 500 chars, even with all the LdrawSearchNN text, and
with only one variable, it uses less than 300 chars:
LdrawSearch="<HIDE>file://C:\LDrawXtra\MyPrims\In Work|
file://C:\LDrawXtra\MyParts\In Work|
<MODELDIR>|<HIDE>BFC\P|<HIDE>BFC\PARTS|
<HIDE>P|PARTS|MODELS|MODELS\TEST|file://C:\LDrawXtra\MyParts\Done|
file://127.0.0.1/freedrive/public/ldraw/parts|
<HIDE>file:///tmp/ldraw-temp-parts"
> Also, while I like the above (and it's very similar to the data I
> store in the registry for LDView), I think we need to keep in mind
> here that Michael already has the parsing working for the format he
> created. Consequently, unless we have some pressing reason, I don't
> think it would be right to come up with a different format that
> produces the same results as his format.
> Unless we have some reason to find his format unacceptable, I think
> we should only modify it by allowing absolute paths, moving the data
> into ldraw.ini instead of MLCad.ini, and checking the user's home
> directory, then the windows directory, for ldraw.ini. His comments
> so far seem to indicate that that would be his preference.
Whatever we end up with in the ini file, I'm still going to check
the environment first.
Ok, so let's look at Michael's .ini file format.
[LDRAW_SEARCH]
HIDE "C:\LDrawXtra\MyPrims\In Work"
SHOW "C:\LDrawXtra\MyParts\In Work"
SHOW MODELDIR
HIDE BFC\P
HIDE BFC\PARTS
HIDE P
SHOW PARTS
SHOW MODELS
SHOW MODELS\TEST
SHOW C:\LDrawXtra\MyParts\Done
SHOW \\127.0.0.1\freedrive\public\ldraw\parts
HIDE /tmp/ldraw-temp-parts/
I like the idea of defaulting to relative paths off of <LDRAWDIR>, but
Lars has a point. I'd like an easy, platform independent way of
quickly identifying an absolute path. What about using a URL for
absolute paths? eg. "file://wherever/the/path/is". This might come
in handy later for files available via http or ftp.
I think I still like <MODELDIR> over MODELDIR since it's not relative
to <LDRAWDIR>. However, I might even go for "." instead of <MODELDIR>
because it's so concise.
The only other problem I have with Michael's format is that it's not
in "key=value" format. Maybe that's just because I don't do enough
Windows programming. I know GetPrivateProfileString() works with
[section]
key=value
formatted entries. Can someone point out the windows function to
parse the MLCAD style entries?
Don
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:HtAD4n.BCJ@lugnet.com...
<SNIP>
> Ok, so let's look at Michael's .ini file format. • <SNIP>
> I like the idea of defaulting to relative paths off of <LDRAWDIR>, but
> Lars has a point. I'd like an easy, platform independent way of
> quickly identifying an absolute path. What about using a URL for
> absolute paths? eg. "file://wherever/the/path/is". This might come
> in handy later for files available via http or ftp.
FILE:// style is fully machine dependend as well, so there is no need to put
file in front, but I'm open to additionaly allow ftp and http urls for
future versions. For now I would make things far to complex and complicated
...
>
> I think I still like <MODELDIR> over MODELDIR since it's not relative
> to <LDRAWDIR>. However, I might even go for "." instead of <MODELDIR>
> because it's so concise.
I can agree with that as well, if it speeds up things.
>
> The only other problem I have with Michael's format is that it's not
> in "key=value" format. Maybe that's just because I don't do enough
> Windows programming. I know GetPrivateProfileString() works with
>
> [section]
> key=value
>
> formatted entries. Can someone point out the windows function to
> parse the MLCAD style entries?
I finaly got the point now. There is no such function :-| but however the
use of ini files on windows is just to have the settings in a file for
plattform independency, windows only programs should use the registry not
files - at least this is a microsoft guideline. I used the ini file for
things which do not fit within the key - value thing to be more flexible.
But you got me on thinking about multi line registry entries, how do they
look like when written into a file? I'll go and check that if I have time. -
Just for completeness multiline entries have one key but the value can be
saved in multiple lines each separated by a 0 at the end of the line. The
value is complete if you got two 0s. Theoretically I would guess in a file
you should get something like
KEY=VALUE-LINE1
VALUE-LINE2
VALUE-LINE3
NextKey = Value.
But its just a guess.
>
> Don
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> > The only other problem I have with Michael's format is that it's not
> > in "key=value" format. Maybe that's just because I don't do enough
> > Windows programming. I know GetPrivateProfileString() works with
[snip]
> I finaly got the point now. There is no such function :-|
This could be addressed by prepending each value/line with 1=, 2=, 3=, etc.
Steve
|
|
| |
"Steve Bliss" <steve.bliss@earthlink.net> schrieb im Newsbeitrag
news:mna930t5n6agvkljvucqbbu55pkpadj1sm@4ax.com...
> In lugnet.cad.dev, Michael Lachmann wrote:
>
> > > The only other problem I have with Michael's format is that it's not
> > > in "key=value" format. Maybe that's just because I don't do enough
> > > Windows programming. I know GetPrivateProfileString() works with
> [snip]
>
> > I finaly got the point now. There is no such function :-|
>
> This could be addressed by prepending each value/line with 1=, 2=, 3=, • etc.
>
> Steve
Good idea, so how about
[LDRAW_SEARCH]
1=SHOW <MODELDIR>
2=HIDE <LDRAWDIR>P
3=SHOW <LDRAWDIR>Parts
4=SHOW <LDRAWDIR>Models
.
.
.
20=SHOW "C:\A special path with blanks"
Keywords <MODELDIR> ... actual directory where the project/file is located
<LDRAWDIR> ... what it tells us
and finaly paths starting with anything different from "<" as beeing
absolute paths as beeing designed for the operating system
I think two keywords for predefined paths should be enough.
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> Good idea, so how about
>
> [LDRAW_SEARCH]
> 1=SHOW <MODELDIR>
> 2=HIDE <LDRAWDIR>P
> 3=SHOW <LDRAWDIR>Parts
> 4=SHOW <LDRAWDIR>Models
> .
> .
> .
> 20=SHOW "C:\A special path with blanks"
>
> Keywords <MODELDIR> ... actual directory where the project/file is located
> <LDRAWDIR> ... what it tells us
> and finaly paths starting with anything different from "<" as beeing
> absolute paths as beeing designed for the operating system
>
> I think two keywords for predefined paths should be enough.
It looks good to me.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Michael Lachmann wrote:
> > Good idea, so how about
> >
> > [LDRAW_SEARCH]
> > 1=SHOW <MODELDIR>
> > 2=HIDE <LDRAWDIR>P
> > 3=SHOW <LDRAWDIR>Parts
> > 4=SHOW <LDRAWDIR>Models
> > .
> > .
> > .
> > 20=SHOW "C:\A special path with blanks"
> >
> > Keywords <MODELDIR> ... actual directory where the project/file is located
> > <LDRAWDIR> ... what it tells us
> > and finaly paths starting with anything different from "<" as beeing
> > absolute paths as beeing designed for the operating system
> >
> > I think two keywords for predefined paths should be enough.
>
> It looks good to me.
It works for me too. So we should check the user's home directory
for an ldraw.ini file containing an [LDRAW_SEARCH] section, then if not
found look in the ldraw.ini file in Windows directory.
For myself, because of platform portability considerations, I'll still
check the environment variable LDRAW_SEARCH before looking for an
ldraw.ini file. I'll separate the entries in the environment variable
with the "|" character. However, I'm undecided whether to require
a HIDE or SHOW tag, or use only <HIDE> and make SHOW the default. Will
anyone else be using the environment variable, and if so do you have
a preference?
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > In lugnet.cad.dev, Michael Lachmann wrote:
> > > Good idea, so how about
> > >
> > > [LDRAW_SEARCH]
> > > 1=SHOW <MODELDIR>
> > > 2=HIDE <LDRAWDIR>P
> > > 3=SHOW <LDRAWDIR>Parts
> > > 4=SHOW <LDRAWDIR>Models
> > > .
> > > .
> > > .
> > > 20=SHOW "C:\A special path with blanks"
> > >
> > > Keywords <MODELDIR> ... actual directory where the project/file is located
> > > <LDRAWDIR> ... what it tells us
> > > and finaly paths starting with anything different from "<" as beeing
> > > absolute paths as beeing designed for the operating system
> > >
> > > I think two keywords for predefined paths should be enough.
> >
> > It looks good to me.
Me too. I think it is a good idea with a separate section for the search directories,
it allows shorter keys than suggested in http://news.lugnet.com/cad/dev/?n=9510
However, I suggest section name [LDrawSearch] which is more in line with [LDraw].
> It works for me too. So we should check the user's home directory
> for an ldraw.ini file containing an [LDRAW_SEARCH] section, then if not
> found look in the ldraw.ini file in Windows directory.
Yes, first %USERPROFILE%\LDraw.ini, then %WINDIR%\LDraw.ini.
Perhaps we should add the possibility of an LDRAWINI env variable,
this could prove useful, both for temporarily using another setting,
and also on non-windows platforms.
In e.g. Linux, should we read $HOME/LDraw.ini ?
MacOSX ?
> For myself, because of platform portability considerations, I'll still
> check the environment variable LDRAW_SEARCH before looking for an
> ldraw.ini file. I'll separate the entries in the environment variable
> with the "|" character.
Me too.
First LDRAWSEARCH01, LDRAWSEARCH02, ...
Next LDRAWSEARCH separated with '|'.
> However, I'm undecided whether to require
> a HIDE or SHOW tag, or use only <HIDE> and make SHOW the default. Will
> anyone else be using the environment variable, and if so do you have
> a preference?
I suggest <HIDE> and <SHOW> as prefixes, <SHOW> as default if none specified.
Using < > may become useful later for other flags.
If your program doesn't understand the tag <xxx> then it can simply ignore it.
Flags as <PARTS> and <PRIMITIVES> could be used for classifying any file in a given
directory not having an "official" file type header.
(classifying is important, at least to L3P, for determining e.g. when to use seams)
Quotation marks should not be necessay if we use the < >.
Also I suggest a \ after <LDRAWDIR>: "2=<HIDE><LDRAWDIR>\P"
Unix platform should of course convert to /.
In the week end I plan to write a small library (in C) for reading the env vars and LDraw.ini's
to set up the directories. I'll also write an LDrawSetup application with a GUI for editing LDraw.ini.
All open source, if you want to save the effort yourself.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Travis Cobbs wrote:
> > > In lugnet.cad.dev, Michael Lachmann wrote:
> > > > Good idea, so how about
> > > >
> > > > [LDRAW_SEARCH]
> > > > 1=SHOW <MODELDIR>
> > > > 2=HIDE <LDRAWDIR>P
> > > > 3=SHOW <LDRAWDIR>Parts
> > > > 4=SHOW <LDRAWDIR>Models
> > > > .
> > > > .
> > > > .
> > > > 20=SHOW "C:\A special path with blanks"
> > > >
> > > > Keywords <MODELDIR> ... actual directory where the project/file is located
> > > > <LDRAWDIR> ... what it tells us
> > > > and finaly paths starting with anything different from "<" as beeing
> > > > absolute paths as beeing designed for the operating system
> > > >
> > > > I think two keywords for predefined paths should be enough.
> > >
> > > It looks good to me.
>
> Me too. I think it is a good idea with a separate section for the
> search directories, it allows shorter keys than suggested in
> http://news.lugnet.com/cad/dev/?n=9510 However, I suggest section
> name [LDrawSearch] which is more in line with [LDraw].
I also considered suggesting [LDrawSearch] but I held back and went
with the "me too". I do like [LDrawSearch] better though.
> > It works for me too. So we should check the user's home directory
> > for an ldraw.ini file containing an [LDRAW_SEARCH] section, then if not
> > found look in the ldraw.ini file in Windows directory.
>
> Yes, first %USERPROFILE%\LDraw.ini, then %WINDIR%\LDraw.ini.
> Perhaps we should add the possibility of an LDRAWINI env variable,
> this could prove useful, both for temporarily using another setting,
> and also on non-windows platforms.
>
> In e.g. Linux, should we read $HOME/LDraw.ini ? MacOSX ?
Sure, but use lowercase ldraw.ini please! I'm too lazy to remember to use
the shift key on a case sensitive filesystem.
> > For myself, because of platform portability considerations, I'll still
> > check the environment variable LDRAW_SEARCH before looking for an
> > ldraw.ini file. I'll separate the entries in the environment variable
> > with the "|" character.
>
> Me too.
> First LDRAWSEARCH01, LDRAWSEARCH02, ...
> Next LDRAWSEARCH separated with '|'.
I can live with that.
> > However, I'm undecided whether to require a HIDE or SHOW tag, or
> > use only <HIDE> and make SHOW the default. Will anyone else be
> > using the environment variable, and if so do you have a preference?
>
> I suggest <HIDE> and <SHOW> as prefixes, <SHOW> as default if none
> specified. Using < > may become useful later for other flags. If
> your program doesn't understand the tag <xxx> then it can simply
> ignore it. Flags as <PARTS> and <PRIMITIVES> could be used for
> classifying any file in a given directory not having an "official"
> file type header. (classifying is important, at least to L3P, for
> determining e.g. when to use seams)
Yes, I agree with the <> for all tags, and ignore tags you don't
recognize. I wanted to suggest this for the ldraw.ini file, but once
again I chickened out. Think about it, flagging a directory as
<PARTS> also helps identify and count things for a parts list.
> Quotation marks should not be necessay if we use the < >.
As far as I can tell, that's correct.
> Also I suggest a \ after <LDRAWDIR>: "2=<HIDE><LDRAWDIR>\P"
> Unix platform should of course convert to /.
I disagree with this one. It should be implicit in the <LDRAWDIR> and
<MODELDIR> tags. This way we can define all the current default search
paths without any platform dependent characters.
<MODELDIR>
<LDRAWDIR>P
<LDRAWDIR>PARTS
<LDRAWDIR>MODELS
> In the week end I plan to write a small library (in C) for reading
> the env vars and LDraw.ini's to set up the directories. I'll also
> write an LDrawSetup application with a GUI for editing LDraw.ini.
> All open source, if you want to save the effort yourself.
That sounds wonderful. There is source for getprivateprofilestring()
writeprivateprofilestring() replacement functions here, if it helps.
http://www.kargs.net/software.html
You must have peeked at the ldglite todo list. If not, here's the
entry I'm talking about. It has a few extra ideas for your GUI if
you get really motivated. I love the idea about making an LDDP
plugin wrapper for the GUI, then it can be used seamlessly by LDDP,
ldglite, and anyone else supporting LDDP style plugins.
Don
----------------------
Make some way to register ldglite since win2k and winXP do not allow
creation of new MIME types via explorer. Either do something like
ldglite -reg or distribute a ldglite.reg file with instructions on how
to set the directory path of the executable.
Oh, Oh, I know. This could be a plugin. The registerme plugin.
That way I can distribute it with the windows binary only, and it'll
already know what directory the executable is installed in. And it
should also know the name of the executable to register. However it
should provide a GUI to change it, and add command line arguments.
This could get really fancy and incorporate the ldrawinfotip DLL and
registry settings. Would this be useful to the lddp folks?
Hmm, maybe it could also create or add the ldraw.ini setting for
the LDRAWDIR if it can't find it.
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > In e.g. Linux, should we read $HOME/LDraw.ini ? MacOSX ?
>
> Sure, but use lowercase ldraw.ini please! I'm too lazy to remember to use
> the shift key on a case sensitive filesystem.
OK.
> > Also I suggest a \ after <LDRAWDIR>: "2=<HIDE><LDRAWDIR>\P"
> > Unix platform should of course convert to /.
>
> I disagree with this one. It should be implicit in the <LDRAWDIR> and
> <MODELDIR> tags.
But you don't declare LDRAWDIR as C:\LDraw\, i.e. with a trailing backslash.
We also use %WINDIR%\ldraw.ini and not %WINDIR%ldraw.ini.
I think most variable substitution in any (script) language uses explicit delimiters
in stead of having delimiters as part of the variable.
Probably because it difficult to remove the trailing delimiter in cases it is not needed.
> This way we can define all the current default search
> paths without any platform dependent characters.
So ? Is that important ?
> > In the week end I plan to write a small library (in C) for reading
> > the env vars and LDraw.ini's to set up the directories. I'll also
> > write an LDrawSetup application with a GUI for editing LDraw.ini.
> > All open source, if you want to save the effort yourself.
>
> That sounds wonderful. There is source for getprivateprofilestring()
> writeprivateprofilestring() replacement functions here, if it helps.
>
> http://www.kargs.net/software.html
Thanks, I'll have a look.
> You must have peeked at the ldglite todo list. If not, here's the
> entry I'm talking about. It has a few extra ideas for your GUI if
> you get really motivated.
I already had the MIME-types in mind, but it should have been a surprise :-)
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> > > Also I suggest a \ after <LDRAWDIR>: "2=<HIDE><LDRAWDIR>\P"
> > > Unix platform should of course convert to /.
> >
> > I disagree with this one. It should be implicit in the <LDRAWDIR> and
> > <MODELDIR> tags.
>
> But you don't declare LDRAWDIR as C:\LDraw\, i.e. with a trailing
> backslash.
Exactly, and you don't look for a part named "\3006.DAT" in the PARTS
directory? When you combine the full path to the PARTS directory with
the part filename you have to add the "\" yourself, right? So I know
you can do it...
> We also use %WINDIR%\ldraw.ini and not %WINDIR%ldraw.ini.
Ah, but %WINDIR% is already platform specific so it's OK there.
By the way, are you suggesting we might allow environemnt variables
in the paths inside the ldraw.ini file? Perhaps something like
%USERPROFILE%\PARTS or $HOME/models depending on the platform?
> I think most variable substitution in any (script) language uses
> explicit delimiters instead of having delimiters as part of the
> variable. Probably because it difficult to remove the trailing
> delimiter in cases it is not needed.
>
> > This way we can define all the current default search
> > paths without any platform dependent characters.
>
> So ? Is that important ?
Actually I don't really care all that much. Especially if you write
the code that parses it. :^)
Don
|
|
| |
Sorry to be a bit harsh now but whats going on here now is exactly what I
ment with overkill in discussions. We discuss about a quite simple small
usefull feature - but we also discuss how we can make things complicated and
beeing a long process until we get something done.
For myself I'll wait another week and then I'll go with my approach for a
first start - maybe taking an official solution later on when everything is
stable and agreed.
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> Sorry to be a bit harsh now but whats going on here now is exactly what I
> ment with overkill in discussions. We discuss about a quite simple small
> usefull feature - but we also discuss how we can make things complicated and
> beeing a long process until we get something done.
I think you are being a bit unreasonable.
The discussion is about a fundamental functionality of LDraw,
which has impact on all programs.
Agreement is important to ease the life of the end user: *one* place for setup.
We try to accomodate special wishes about e.g. hide-flags.
Adding < > around HIDE was an important step for future needs.
We also try to come up with something that can work on all platforms.
I understand your impatience. Internet discussions take very long time
due to different online times.
But I think it important to get many comments, one can easily overlook details
because you often have a certain use in mind.
I do hope you'll join the final agreement and support it.
/Lars
|
|
| |
I just start a new sub-thread to discuss two very important points where I
thought over two nights now:
The location of the ini file and environment variables!
I would not recommend to go with both solutions, because its source for
possible errors and confusion for the user. The thing is what would be the
first thing to consider for a software - what if environment variables and
ini files contain path definitions but different ones? I would prefere to go
with the ini file variant only - even if some of you have implemented this
strategy already - this should not be a point, also I have to discard my
current implementation on this topic.
Also I have something in mind - correct if I'm wrong - but Java does not
support this environment varables very well - and as we mentioned earlier
they are very dependend on the operating system.
An other thing regards the location of the ini file. In past weeks I got
several questions regarding the central installation of LDraw and MLCad,
where universities and schools are trying to install everything on a server,
read-only for the user. Users should either not have the possiblity to
change configs ore should be restricted somehow.
- Now having a ini file in the windows directory would not support this
approach, and personaly I'm not a favorite of spamming the windows system
directories with private files (even if some windows variants do that on
theire own :-)
So my suggestion is to have one ini file in the ldraw directory itself, and
another one optionally in the users home directory.
So what is your opinion on that points?
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> I just start a new sub-thread to discuss two very important points where I
> thought over two nights now:
>
> The location of the ini file and environment variables!
>
> I would not recommend to go with both solutions, because its source for
> possible errors and confusion for the user. The thing is what would be the
> first thing to consider for a software - what if environment variables and
> ini files contain path definitions but different ones? I would prefere to go
> with the ini file variant only - even if some of you have implemented this
> strategy already - this should not be a point, also I have to discard my
> current implementation on this topic.
> Also I have something in mind - correct if I'm wrong - but Java does not
> support this environment varables very well - and as we mentioned earlier
> they are very dependend on the operating system.
I agree. I like the ini file solution over the environmet varible
> An other thing regards the location of the ini file. In past weeks I got
> several questions regarding the central installation of LDraw and MLCad,
> where universities and schools are trying to install everything on a server,
> read-only for the user. Users should either not have the possiblity to
> change configs ore should be restricted somehow.
> - Now having a ini file in the windows directory would not support this
> approach, and personaly I'm not a favorite of spamming the windows system
> directories with private files (even if some windows variants do that on
> theire own :-)
> So my suggestion is to have one ini file in the ldraw directory itself, and
> another one optionally in the users home directory.
I agree that putting the ldraw.ini the LDRAW dir would make much more sense (why
it wasn't in the first place is puzzling) but the problem is that the programs
the use it expect it in the Windows directory. If we move it then all these
programs (some of which are not actively developed any more) would have to be
changed.
-Orion
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> I agree that putting the ldraw.ini the LDRAW dir would make much more sense (why
> it wasn't in the first place is puzzling) but the problem is that the programs
> the use it expect it in the Windows directory. If we move it then all these
> programs (some of which are not actively developed any more) would have to be
> changed.
Well, the ldraw directory itself can be specified in ldraw.ini. And while I
agree that filling up the Windows directory is generally a bad thing, you can't
have the file be in the LDraw directory if it is the file that specifies where
to find the LDraw directory.
The real problem is that Windows wasn't designed as a multiple user OS. And if
you want to support Windows 95/98/ME, you at least need to have fallback
mechanisms in place to deal with this fact.
Even having said the above, I still like the idea of have an ldraw.ini file in
the LDraw directory. Obviously it wouldn't contain the setting telling you
where to find the LDraw directory, but any other settings could be there.
--Travis
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> So what is your opinion on that points?
I agree (although I did point something out in a response to Orion's response).
Unix (and Unix-like) environments do often use the environment to control
things, but they also use dot files. And while it wouldn't make sense to have
an ldraw.ini file in the user's home directory in Unix, it would make perfect
sense to have a .ldrawrc file, that just happened to be in the same format as
the ldraw.ini file from Windows.
--Travis
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> I just start a new sub-thread to discuss two very important points
> where I thought over two nights now:
>
> The location of the ini file and environment variables!
>
> I would not recommend to go with both solutions, because its source
> for possible errors and confusion for the user. The thing is what
> would be the first thing to consider for a software - what if
> environment variables and ini files contain path definitions but
> different ones? I would prefere to go with the ini file variant only
> - even if some of you have implemented this strategy already - this
> should not be a point, also I have to discard my current
> implementation on this topic.
I'm only willing to abandon environment variables if you're willing to
go the distance and really try to work out a standard that we all can
use. I, like Lars, was quite disappointed when you got impatient and
cut short the previous discussion thread. I thought we were still
making good progress at the time. Since you're currently an LSC
member, I'd think you could at least try to be more patient with the
rest of us as we work this out. Please rejoin that thread and
comment on the remaining issues:
1. <LDRAWDIR>\p or <LDRAWDIR>p
2. <HIDE> instead of HIDE
3. Allowing other tags like <PARTS> and ignoring unrecognized ones.
Ok now as Travis pointed out, we still need to find the LDRAWDIR
directory. We also need environment variables to find the other
places ldraw.ini (or .ldrawrc) could reside; the WINDIR, USERPROFILE,
and HOME directories. So we can't completely abandon environment
variables. However there are there are reasons like java and macos9
why we might want to limit their use.
> Also I have something in mind - correct if I'm wrong - but Java does
> not support this environment varables very well - and as we
> mentioned earlier they are very dependend on the operating system.
Java has other problems, but yes, you need a helper script or program
to pass environment variables to the current version of java. However
there is a bit of a holy war about this in the java bug list so things
may change again.
> Another thing regards the location of the ini file. In past weeks I
> got several questions regarding the central installation of LDraw
> and MLCad, where universities and schools are trying to install
> everything on a server, read-only for the user. Users should either
> not have the possiblity to change configs ore should be restricted
> somehow.
Yes, I alluded to this in my previous comment about CACLS and
Windows administrators.
> - Now having a ini file in the windows directory would not support
> this approach, and personaly I'm not a favorite of spamming the
> windows system directories with private files (even if some windows
> variants do that on theire own :-)
>
> So my suggestion is to have one ini file in the ldraw directory
> itself, and another one optionally in the users home directory.
I think we need to allow for an ldraw.ini in the Windows directory
for backwards compatibliity with old programs and older single user
Windows systems, but it should be the last place searched. Ie.
search HOME, LDRAWDIR, and then Windows. Also, you may want to do
a different search for the LDRAWDIR. First look in the environment,
then the HOME directory, then the WINDOWS directory. On unix/MacOsX
could we substitute /etc for the Windows directory?
Andrew, it'd be nice if an active Mac developer spoke up on this.
Finally, if we start putting ldraw.ini in the LDRAWDIR, how do we
decide what belongs in ldraw.ini and ldconfig.ldr? For instance if we
go with the <LDRAWDIR>p form (without the slash character), the
default search paths are platform independent and could conceivably be
worked into the ldconfig.ldr file.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> > Another thing regards the location of the ini file. In past weeks I
> > got several questions regarding the central installation of LDraw
> > and MLCad, where universities and schools are trying to install
> > everything on a server, read-only for the user. Users should either
> > not have the possiblity to change configs ore should be restricted
> > somehow.
>
> Yes, I alluded to this in my previous comment about CACLS and
> Windows administrators.
Oops, I forgot to add this.
These sort of restrictions mean a user may be forced to put extra
search directories in their home directory. Rather than recognize
$HOME or %USERPROFILE% in an absolute path, it might be nice to add
a <HOME> directory tag in addition to <LDRAWDIR> and <MODELDIR>.
I'm not sure what this would default to in single user systems
though. Perhaps the root directory?
Don
|
|
| |
> I think we need to allow for an ldraw.ini in the Windows directory
> for backwards compatibliity with old programs and older single user
> Windows systems, but it should be the last place searched. Ie.
> search HOME, LDRAWDIR, and then Windows. Also, you may want to do
> a different search for the LDRAWDIR. First look in the environment,
> then the HOME directory, then the WINDOWS directory. On unix/MacOsX
> could we substitute /etc for the Windows directory?
>
> Andrew, it'd be nice if an active Mac developer spoke up on this.
>
> Finally, if we start putting ldraw.ini in the LDRAWDIR, how do we
> decide what belongs in ldraw.ini and ldconfig.ldr? For instance if we
> go with the <LDRAWDIR>p form (without the slash character), the
> default search paths are platform independent and could conceivably be
> worked into the ldconfig.ldr file.
/etc would work, except it would require admin permission to install,
which is something the Mac OS X community doesn't like for an
installer/app that isn't a system modifying type of installer/app.
Saving stuff in /etc/ will also not survive a major OS upgrade (from
10.2 to 10.3) unless the user chooses the less preferred upgrade method
which merges 10.2 and 10.3 (which is messy and nobody recommends it).
The other Unix way of doing things exists on Mac OS X too, that is,
~/.bla_rc. Most Unix/linux ports do this. This will survive a major
OS upgrade if the user choose to preserve user and networking data,
which is the most preferred method of upgrading.
The Apple preferred "GUI" way to store prefs is for a user level pref
to use ~/Library/Preferences/com.name.app.plist and a computer level
pref to use /Library/Preferences/com.name.app.plist.
I don't think us Mac OS X people have really decided how to do this.
I'm saving my prefs in
~/Library/Preferences/org.ldraw.mac.l3p_launcher.plist. I Andrew is
using ~/Library/Preferences/Mac Brick CAD.plist.
A plist file is a "property list", which is an xml formated file with
keys and values. Andrew's file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>LdrawFolder</key>
<string>/Library/ldraw/</string>
...
</dict>
Mine plist looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>ldraw_folder</key>
<string>/Library/ldraw</string>
...
</dict>
We talked about making it uniform awhile back, and I even said I was
going to write some code that would check for the folder and ask the
user to define it and such and such but I never did.
--
James Reynolds
http://www.cc.utah.edu/~jer29950
james@magnusviri.com - james@scl.utah.edu
|
|
| |
One other thing. Environment variables work too, but only serious
Unixy Mac OS X people actually modify them--that is, some developers,
but no one else. Normal users would even know what they are. Heck,
even I don't modify mine. For my l3p and ldglite launcher apps, I grab
the ldrawdir from the prefs, then I modify the environment variable
before it is launched. But the variable is wiped out once the app is
quit.
--
James Reynolds
http://www.cc.utah.edu/~jer29950
james@magnusviri.com - james@scl.utah.edu
|
|
| |
In lugnet.cad.dev.mac, James Reynolds wrote:
> One other thing. Environment variables work too, but only serious
> Unixy Mac OS X people actually modify them--that is, some developers,
> but no one else. Normal users would even know what they are. Heck,
> even I don't modify mine. For my l3p and ldglite launcher apps, I grab
> the ldrawdir from the prefs, then I modify the environment variable
> before it is launched. But the variable is wiped out once the app is
> quit.
Actually Environment variables work pretty well on OS X because they've
set up a standard place to put them, and it's one of those plist files.
See here for details.
http://ldglite.sourceforge.net/osxinstall.html
It would be nice though to have a standard fallback location for the
LDRAWDIR and LDRAWSEARCH paths. Somewhere generic like:
/Library/Preferences/org.ldraw.mac.plist
or
~/Library/Preferences/org.ldraw.mac.plist
I'll have to go back and see what we said about it over the summer.
Don
|
|
| |
Ok I hop on again ...
"Lars C. Hassing" <sp.lars@am.hassings.dk> schrieb im Newsbeitrag
news:Htnz7B.G2z@lugnet.com...
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Travis Cobbs wrote:
> > > In lugnet.cad.dev, Michael Lachmann wrote:
> > > > Good idea, so how about
> > > >
> > > > [LDRAW_SEARCH]
> > > > 1=SHOW <MODELDIR>
> > > > 2=HIDE <LDRAWDIR>P
> > > > 3=SHOW <LDRAWDIR>Parts
> > > > 4=SHOW <LDRAWDIR>Models
> > > > .
> > > > .
> > > > .
> > > > 20=SHOW "C:\A special path with blanks"
> > > >
> > > > Keywords <MODELDIR> ... actual directory where the project/file is • located
> > > > <LDRAWDIR> ... what it tells us
> > > > and finaly paths starting with anything different from "<" as beeing
> > > > absolute paths as beeing designed for the operating system
> > > >
> > > > I think two keywords for predefined paths should be enough.
> > >
> > > It looks good to me.
>
> Me too. I think it is a good idea with a separate section for the search • directories,
> it allows shorter keys than suggested in • http://news.lugnet.com/cad/dev/?n=9510
> However, I suggest section name [LDrawSearch] which is more in line with
[LDraw].
I can agree nothing would speak against that.
<SNIP> Section of environments <SNIP>
I'm happy with any solution here, but I will not read it - so I don't want
to hinder anything beeing
agreed here.
> > However, I'm undecided whether to require
> > a HIDE or SHOW tag, or use only <HIDE> and make SHOW the default. Will
> > anyone else be using the environment variable, and if so do you have
> > a preference?
>
> I suggest <HIDE> and <SHOW> as prefixes, <SHOW> as default if none • specified.
> Using < > may become useful later for other flags.
> If your program doesn't understand the tag <xxx> then it can simply ignore • it.
> Flags as <PARTS> and <PRIMITIVES> could be used for classifying any file • in a given
> directory not having an "official" file type header.
> (classifying is important, at least to L3P, for determining e.g. when to
use seams)
I'm talking on file level now, I still would prefer the syntax like style of
HIDE and SHOW but we can also see it as an
option in which case I would take them into brackets.
So if it is easier or better when using in environment variables go for it -
but we should get them equally processed in variables and files.
>
> Quotation marks should not be necessay if we use the < >.
You are right but I still would allow them for the rare case of blanks at
the end of a directory name.
>
> Also I suggest a \ after <LDRAWDIR>: "2=<HIDE><LDRAWDIR>\P"
> Unix platform should of course convert to /.
I cannot see any reason for this but we could eliminate it later on
anyway. - at least Windows doesn't care about single or double backslashes.
>
> In the week end I plan to write a small library (in C) for reading the env • vars and LDraw.ini's
> to set up the directories. I'll also write an LDrawSetup application with • a GUI for editing LDraw.ini.
> All open source, if you want to save the effort yourself.
> /Lars
>
>
I will have to write it myself - MLCad is not open source!
Michael
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:HtwMAE.3BM@lugnet.com...
> I'm only willing to abandon environment variables if you're willing to
> go the distance and really try to work out a standard that we all can
> use. I, like Lars, was quite disappointed when you got impatient and
> cut short the previous discussion thread. I thought we were still
> making good progress at the time. Since you're currently an LSC
> member, I'd think you could at least try to be more patient with the
> rest of us as we work this out. Please rejoin that thread and
> comment on the remaining issues:
>
> 1. <LDRAWDIR>\p or <LDRAWDIR>p
> 2. <HIDE> instead of HIDE
> 3. Allowing other tags like <PARTS> and ignoring unrecognized ones.
Done, sorry about that - but it was a hard day at work :-(
>
> Ok now as Travis pointed out, we still need to find the LDRAWDIR
> directory. We also need environment variables to find the other
> places ldraw.ini (or .ldrawrc) could reside; the WINDIR, USERPROFILE,
> and HOME directories. So we can't completely abandon environment
> variables. However there are there are reasons like java and macos9
> why we might want to limit their use.
As mentioned earlier in this thread ... we should go with:
1) Users Home Directory
2) LDraw Directory
3) Windows directory
This work fine for single user systems as well - they would just start at
"Ldraw directory" if there is no users directory.
<SNIP>
> Finally, if we start putting ldraw.ini in the LDRAWDIR, how do we
> decide what belongs in ldraw.ini and ldconfig.ldr? For instance if we
> go with the <LDRAWDIR>p form (without the slash character), the
> default search paths are platform independent and could conceivably be
> worked into the ldconfig.ldr file.
I would suggest program configuration information, machine relevant
information and machine dependend informations beeing in the ini files,
while ldraw and (hardware independand) rendering specific configurations
(like colours) should be in the ldconfig.ldr.
This makes sence, as your program might not be able to read the ldconfig.ldr
without knowing machine and installation details.
Michael
>
> Don
|
|
| |
> In lugnet.cad.dev.mac, James Reynolds wrote:
> > One other thing. Environment variables work too, but only serious
> > Unixy Mac OS X people actually modify them--that is, some developers,
> > but no one else. Normal users would even know what they are. Heck,
> > even I don't modify mine. For my l3p and ldglite launcher apps, I
> > grab
> > the ldrawdir from the prefs, then I modify the environment variable
> > before it is launched. But the variable is wiped out once the app is
> > quit.
>
> Actually Environment variables work pretty well on OS X because they've
> set up a standard place to put them, and it's one of those plist files.
> See here for details.
>
> http://ldglite.sourceforge.net/osxinstall.html
>
> It would be nice though to have a standard fallback location for the
> LDRAWDIR and LDRAWSEARCH paths. Somewhere generic like:
>
> /Library/Preferences/org.ldraw.mac.plist
>
> or
>
> ~/Library/Preferences/org.ldraw.mac.plist
>
> I'll have to go back and see what we said about it over the summer.
Oh. I didn't know it was as easy as:
~/MacOSX/environment.plist
I guess that is one route.
In Cocoa, which is what Andrew and I are both developing in now, it is
really easy to grab prefs that have a unique name for the application.
It isn't too much harder to look somewhere else. But I am assuming
Andrew was like me and just took the easier road and grabbed the prefs
that had the application's unique name. This was the code I was going
to write. We can use ~/MacOSX/environment.plist as easily as anything
else. We just have to decide what to do.
I'm starting to spend my free time on LDraw stuff again, so maybe I
will finally write it.
--
James Reynolds
http://www.cc.utah.edu/~jer29950
james@magnusviri.com - james@scl.utah.edu
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> Lars C. Hassing wrote:
> > In the week end I plan to write a small library (in C) for reading the
> > env vars and LDraw.ini's to set up the directories. I'll also write an
> > LDrawSetup application with a GUI for editing LDraw.ini.
> > All open source, if you want to save the effort yourself.
>
> I will have to write it myself - MLCad is not open source!
That's not exactly true. I'm sure you can work out an arrangement
with Lars. After all, L3P is not entirely open source, and the
benefit of all the LDRAW tools using an identical parts search strategy
is probably more useful than having you write a duplicate function.
It can't hurt to ask...
Don
|
|
| |
Where to store the preferences?
While I've been aware of this thread, I haven't actually been following it, so
correct me if I've got the wrong end of the stick.
> Ok now as Travis pointed out, we still need to find the LDRAWDIR
> directory. We also need environment variables to find the other
> places ldraw.ini (or .ldrawrc) could reside; the WINDIR, USERPROFILE,
> and HOME directories. So we can't completely abandon environment
> variables. However there are there are reasons like java and macos9
> why we might want to limit their use.
MacOS 9 and earlier is a single user environment and it was easy to place (and
therefore find) any environment variables in the "Preferences" directory.
However, with the migration to MacOS X the rules changed and there is both a
main "System" directory as well as seperate user directories.
As far as I can tell this discussion relates to what information should be
stored in the "System" directory so that all compatable applications can
automatically access a series of global variables such as the location of the
LDRAW directory.
As James has indicated, under MacOS X to make changes to the system directory
the user has to have administration priveleges, this means that the proposed
.ini file would need to static once installed.
With my "full install" version of MBC, I include the LDRAW directory which my
installer then loads into the "System" directory. With this approach, any user
has access the LDRAW files and more importantly, updates made by the
administrator will be automatically available to all users. Likewise, casual
users cannot mess with the LDRAW directory or it's files.
However this does have two distinct disadvantages - uninstalling MBC under this
approach requires more than just dragging the application to the trash (not very
Mac-like) and only administrators can update the LDRAW directory.
> > Another thing regards the location of the ini file. In past weeks I
> > got several questions regarding the central installation of LDraw
> > and MLCad, where universities and schools are trying to install
> > everything on a server, read-only for the user. Users should either
> > not have the possiblity to change configs ore should be restricted
> > somehow.
>
> > So my suggestion is to have one ini file in the ldraw directory
> > itself, and another one optionally in the users home directory.
In the users home directory, I (or actually MacOS X) stores the .plist file
containing my applications settings. At present, this includes MBC specific
settings as well as the location of the LDRAW directory.
Personally I favor having each user store ther own configs seperately. Also
consider something else, under MacOS X the system itself stores information in
the users .plist file that even the programmer may not be aware of. For example,
if I look in the MBC .plist file there are window location details that I don't
put there, likewise when I activated the "Open recent" command, MacOS X then
uses MBC's .plist file to store this info. So at least under MacOS X, it must be
considered that any preferences file may be altered without the programmers or
users knowledge.
> I think we need to allow for an ldraw.ini in the Windows directory
> for backwards compatibliity with old programs and older single user
> Windows systems, but it should be the last place searched. Ie.
> search HOME, LDRAWDIR, and then Windows. Also, you may want to do
> a different search for the LDRAWDIR. First look in the environment,
> then the HOME directory, then the WINDOWS directory. On unix/MacOsX
> could we substitute /etc for the Windows directory?
>
> Andrew, it'd be nice if an active Mac developer spoke up on this.
>
> Finally, if we start putting ldraw.ini in the LDRAWDIR, how do we
> decide what belongs in ldraw.ini and ldconfig.ldr? For instance if we
> go with the <LDRAWDIR>p form (without the slash character), the
> default search paths are platform independent and could conceivably be
> worked into the ldconfig.ldr file.
Personally, I see this as the crux of the issue - what is stored in the
environment file?
If it's static information only such as the location of the LDRAW / LGEO
directories etc, then the main System directory would be OK under MacOS X.
Finally, MBC automatically, first searches the LDRAW directory, the open models'
file directory and then the users directory for files. So for me storing the
location of finding the LDRAW directory isn't as critical as protecting this
directory from unwanted invasions (in the case of puplic or multi user
environments).
Andrew...
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > Also I suggest a \ after <LDRAWDIR>: "2=<HIDE><LDRAWDIR>\P"
> > Unix platform should of course convert to /.
>
> I cannot see any reason for this but we could eliminate it later on
> anyway. - at least Windows doesn't care about single or double backslashes.
I believe that this isn't entirely true. We had a problem at work where a
program didn't work right in Windows 9x (I think it was 98, but I'm not entirely
sure), but worked fine in Windows NT and Windows 2000. After some careful
debugging, I determined that that version of Windows didn't accept a double
backslash in a path. Aditionally, there is of course special behavior for \\
(or //, for that matter) at the beggining of a path.
On a side note, all Windows API calls accept / as a path separator with the
exact same meaning as \. They can even both be used in the same path (ie
C:/ldraw\parts). This might even date back to the DOS days, although I'm not
sure on that one. One catch is that / on the command line is treated entirely
differently from \, making it impossible to use it on the command line (or at
the least very difficult). You can, however, use / in the address bar of
Explorer (and I do mean explorer, not IE, although it works in IE as well with
the appropriate file:// URL syntax).
Having said all that, I think it looks better to have the \ in the ini file. I
think it makes it more obvious that a path is being specified when just glancing
at the file. I think any program making use of the file needs to carefully make
sure a single \ (or /) separates the special dir from whatever's after it, but I
don't think either syntax in the ini file is easier or more difficult than the
other. (I personally try to always strip trailing \ and / characters off my
paths when storing them in variables, and then always add them back when
concatenating path segments together.)
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> On a side note, all Windows API calls accept / as a path separator with the
> exact same meaning as \. They can even both be used in the same path (ie
Sorry to immediately respond to my own respond to my own reply, but I forgot one
minor detail. The corallary to this bit is that to be safe, Windows programs
should treat both / and \ as path separators any time they parse paths, and work
correctly with either or both in a path. The easiest way to do this is to
simply replace all / characters with \ (or vice versa, but that might confuse
users).
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> I'm talking on file level now, I still would prefer the syntax like style of
> HIDE and SHOW but we can also see it as an
> option in which case I would take them into brackets.
> So if it is easier or better when using in environment variables go for it -
> but we should get them equally processed in variables and files.
The data contained in either environment variables or ini files
should have exactly the same format.
> > Quotation marks should not be necessay if we use the < >.
>
> You are right but I still would allow them for the rare case of blanks at
> the end of a directory name.
Trailing blanks are preserved in both env var and ini files.
So I still don't think quotation marks are necessary...
> > In the week end I plan to write a small library (in C) for reading the env • vars and LDraw.ini's
> > to set up the directories. I'll also write an LDrawSetup application with • a GUI for editing LDraw.ini.
> > All open source, if you want to save the effort yourself.
> > /Lars
> >
> >
>
> I will have to write it myself - MLCad is not open source!
I didn't mean open source in the GPL way.
The library is free to use with no ties - other than I would like to be notified
if you make any changes/corrections, so I can update it.
Actually I hope you will all use it, so we get the exact same behaviour in all programs.
An LDraw code repository...
I'm almost done writing the library and the LDrawSetup application.
I want the library to be as simple as possible to use.
Reading the env vars and ini files is platform independent,
only the hunt for ini files goes into #ifdef's.
I think having ldraw.ini in LDRAWDIR is contradictory, the hen and egg problem.
To keep thing simple I would like to have only *one* ldraw.ini,
and since we're going to have it in HOME/USERPROFILE/windir anyway to find the LDRAWDIR,
I don't see any reason to spread it out.
The hunt for ldraw.ini could be:
Windows:
%LDRAWINI%
%USERPROFILE%\ldraw.ini
%ALLUSERSPROFILE%\ldraw.ini
%windir%\ldraw.ini
Unix:
$LDRAWINI
$HOME/.ldrawrc
$HOME/ldraw.ini
/etc/ldraw.ini
Mac:
plist or like Unix?
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> The data contained in either environment variables or ini files
> should have exactly the same format.
I agree, and prefer <> around all tags.
> > > Quotation marks should not be necessay if we use the < >.
> >
> > You are right but I still would allow them for the rare case of
> > blanks at the end of a directory name.
>
> Trailing blanks are preserved in both env var and ini files.
> So I still don't think quotation marks are necessary...
Ah, but what about leading blanks. ;^) Nevermind, I don't think you
can create an absolute path that starts with leading blanks.
> I'm almost done writing the library and the LDrawSetup application.
> I want the library to be as simple as possible to use.
> Reading the env vars and ini files is platform independent,
> only the hunt for ini files goes into #ifdef's.
> I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> egg problem. To keep thing simple I would like to have only *one*
> ldraw.ini, and since we're going to have it in
> HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> reason to spread it out.
> The hunt for ldraw.ini could be:
> Windows:
> %LDRAWINI%
> %USERPROFILE%\ldraw.ini
> %ALLUSERSPROFILE%\ldraw.ini
> %windir%\ldraw.ini
But wait. The reason given for looking in LDRAWDIR is for a central
networked LDRAW installation at a school. It'd be nice to have a
default ldraw.ini file at the central location that can be overridden
by one in a users home directory. This doesn't work for that scenario
because %WINDIR% is on the client PC, not on the server. However, you
still have the chicken/egg problem because you need an LDRAWDIR
setting somewhere on the client to find the LDRAWDIR on the server.
You can however limit the number of chickens by making LDRAWDIR the
only setting required to be set on the client pc.
Or are you promoting LDRAWINI as the one and only setting required to
be on the client? Should we depreciate the LDRAWDIR environment
variable since it can be set in the file found by the LDRAWINI hunt?
I don't like this. I think we can use LDRAWDIR if we're clever.
On windows the envronment variables are global. You don't get a
personal login script to set your own, so I'd look in USERPROFILE
first. Now an administrator can set the %LDRAWDIR% variable in the
\\PDC\netlogin\login.bat script for all users on an NT style domain.
That solves the chicken/egg problem for the centralized Windows
scenario and eliminates any need for an LDRAWINI variable.
So, how about this search strategy?
Windows:
%USERPROFILE%\ldraw.ini
%ALLUSERSPROFILE%\ldraw.ini
%LDRAWDIR%\ldraw.ini
%WINDIR%\ldraw.ini
Unix:
$HOME/.ldrawrc
$HOME/ldraw.ini
$LDRAWDIR/ldraw.ini
/etc/ldraw.ini
Mac OS X:
~/Library/Preferences/org.ldraw.plist
/Library/Preferences/org.ldraw.plist
$LDRAWDIR/ldraw.ini (I'm not sure about this one)
Obviously if you don't have LDRAWDIR set by an environment variable
you'll have to skip the step that looks in the LDRAWDIR.
Enjoy,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> But wait. The reason given for looking in LDRAWDIR is for a central
> networked LDRAW installation at a school. It'd be nice to have a
> default ldraw.ini file at the central location that can be overridden
> by one in a users home directory.
Oh yeah. One other thing about an ldraw.ini located on a central server.
I'd prefer to leave the client OS up to the user. This reinforces my case
for the <LDRAWDIR>parts path format without the nasty OS specific slash
character.
Enjoy,
Don
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hu0CMF.1Fyv@lugnet.com...
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > The data contained in either environment variables or ini files
> > should have exactly the same format.
>
> I agree, and prefer <> around all tags.
Ok, agreed too. So with have <HIDE> and optionally <SHOW> - right?
>
> > > > Quotation marks should not be necessay if we use the < >.
> > >
> > > You are right but I still would allow them for the rare case of
> > > blanks at the end of a directory name.
> >
> > Trailing blanks are preserved in both env var and ini files.
> > So I still don't think quotation marks are necessary...
>
> Ah, but what about leading blanks. ;^) Nevermind, I don't think you
> can create an absolute path that starts with leading blanks.
I would still like the quotation marks as an option - not a must. If a user
uses them fine, if not also fine - if there is a problem with blanks or tabs
the user can still use quotation marks.
<SNIP>
> So, how about this search strategy?
>
> Windows:
> %USERPROFILE%\ldraw.ini
> %ALLUSERSPROFILE%\ldraw.ini
> %LDRAWDIR%\ldraw.ini
> %WINDIR%\ldraw.ini
That would be a perfect way I guess. MLCad also allows to let the user
specify the ldraw dir manualy in a dialog. I could imagine having this
option as an emergency solution if no ldraw dir can be found.
>
> Unix:
> $HOME/.ldrawrc
> $HOME/ldraw.ini
> $LDRAWDIR/ldraw.ini
> /etc/ldraw.ini
>
> Mac OS X:
> ~/Library/Preferences/org.ldraw.plist
> /Library/Preferences/org.ldraw.plist
> $LDRAWDIR/ldraw.ini (I'm not sure about this one)
no idea about Mac's but unix looks good.
>
> Obviously if you don't have LDRAWDIR set by an environment variable
> you'll have to skip the step that looks in the LDRAWDIR.
Or open a dialog to ask the user for this path once, my feeling is if the
user didn't setup the variable - the user will not modify the ldraw.ini file
either - at least that is what I learned from houndreds of support requests
from MLCad users.
Michael
|
|
| |
"Lars C. Hassing" <sp.lars@am.hassings.dk> schrieb im Newsbeitrag
news:Htz996.1H4@lugnet.com...
> In lugnet.cad.dev, Michael Lachmann wrote:
> > I'm talking on file level now, I still would prefer the syntax like • style of
> > HIDE and SHOW but we can also see it as an
> > option in which case I would take them into brackets.
> > So if it is easier or better when using in environment variables go for • it -
> > but we should get them equally processed in variables and files.
>
> The data contained in either environment variables or ini files
> should have exactly the same format.
What I said ;-)
<SNIP>
> > > In the week end I plan to write a small library (in C) for reading the • env
> > vars and LDraw.ini's
> > > to set up the directories. I'll also write an LDrawSetup application • with
> > a GUI for editing LDraw.ini.
> > > All open source, if you want to save the effort yourself.
> > > /Lars
> > >
> > >
> >
> > I will have to write it myself - MLCad is not open source!
>
> I didn't mean open source in the GPL way.
> The library is free to use with no ties - other than I would like to be • notified
> if you make any changes/corrections, so I can update it.
> Actually I hope you will all use it, so we get the exact same behaviour in • all programs.
> An LDraw code repository...
That sound interesting - any way I can help you? E.g. writing a
class-wrapper for c++? Cause MLCad is written in C++ so I will need that
anyway ...
Thanks for the offer - it will save me time.
Michael
P.S: I hope you've forgiven me already :-|
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > Trailing blanks are preserved in both env var and ini files.
> > So I still don't think quotation marks are necessary...
>
> Ah, but what about leading blanks. ;^) Nevermind, I don't think you
> can create an absolute path that starts with leading blanks.
No, but leading blanks would be preserved as well...
> > I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> > egg problem. To keep thing simple I would like to have only *one*
> > ldraw.ini, and since we're going to have it in
> > HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> > reason to spread it out.
>
> > The hunt for ldraw.ini could be:
> > Windows:
> > %LDRAWINI%
> > %USERPROFILE%\ldraw.ini
> > %ALLUSERSPROFILE%\ldraw.ini
> > %windir%\ldraw.ini
>
> But wait. The reason given for looking in LDRAWDIR is for a central
> networked LDRAW installation at a school. It'd be nice to have a
> default ldraw.ini file at the central location that can be overridden
> by one in a users home directory.
Isn't that what %ALLUSERSPROFILE% is for?
> Or are you promoting LDRAWINI as the one and only setting required to
> be on the client? Should we depreciate the LDRAWDIR environment
> variable since it can be set in the file found by the LDRAWINI hunt?
> I don't like this. I think we can use LDRAWDIR if we're clever.
LDRAWINI is just an opportunity for quickly temporarily using another
specific ldraw.ini file.
/Lars
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Oh yeah. One other thing about an ldraw.ini located on a central server.
> I'd prefer to leave the client OS up to the user. This reinforces my case
> for the <LDRAWDIR>parts path format without the nasty OS specific slash
> character.
It's no problem handling the \ or /'s.
We do that all the time already in our parts referencing e.g. S\3039S01.DAT,
we do manage to find the subpart on unix too :-)
My library reads env vars and ini files in any format
and converts it to the format used on the platform it is running.
/Lars
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> > I agree, and prefer <> around all tags.
>
> Ok, agreed too. So with have <HIDE> and optionally <SHOW> - right?
Sure.
> > > > > Quotation marks should not be necessay if we use the < >.
> > > >
> > > > You are right but I still would allow them for the rare case of
> > > > blanks at the end of a directory name.
> > >
> > > Trailing blanks are preserved in both env var and ini files.
> > > So I still don't think quotation marks are necessary...
> >
> > Ah, but what about leading blanks. ;^) Nevermind, I don't think you
> > can create an absolute path that starts with leading blanks.
>
> I would still like the quotation marks as an option - not a must. If a user
> uses them fine, if not also fine - if there is a problem with blanks or tabs
> the user can still use quotation marks.
OK.
> <SNIP>
> > So, how about this search strategy?
> >
> > Windows:
> > %USERPROFILE%\ldraw.ini
> > %ALLUSERSPROFILE%\ldraw.ini
> > %LDRAWDIR%\ldraw.ini
> > %WINDIR%\ldraw.ini
>
> That would be a perfect way I guess. MLCad also allows to let the user
> specify the ldraw dir manualy in a dialog. I could imagine having this
> option as an emergency solution if no ldraw dir can be found.
Fine.
> Or open a dialog to ask the user for this path once, my feeling is if the
> user didn't setup the variable - the user will not modify the ldraw.ini file
> either - at least that is what I learned from houndreds of support requests
> from MLCad users.
I think so too.
Users will also have the option to use the new app LDrawSetup,
which can setup LDrawDir, SearchDirs, LgeoDirectory, MIME-types.
/Lars
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> > I didn't mean open source in the GPL way.
> > The library is free to use with no ties - other than I would like to be notified
> > if you make any changes/corrections, so I can update it.
> > Actually I hope you will all use it, so we get the exact same behaviour in all programs.
> > An LDraw code repository...
>
> That sound interesting - any way I can help you? E.g. writing a
> class-wrapper for c++? Cause MLCad is written in C++ so I will need that
> anyway ...
> Thanks for the offer - it will save me time.
You're welcome.
I chose C rather than C++ because L3P is still also compiled with 1988 TurboC.
L3Lab and LDrawSetup is C++, but can easily interface to a lib in C.
You can write a wrapper class if you think it's necessary.
> P.S: I hope you've forgiven me already :-|
But of course :-)
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Lars C. Hassing wrote:
> > > I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> > > egg problem. To keep thing simple I would like to have only *one*
> > > ldraw.ini, and since we're going to have it in
> > > HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> > > reason to spread it out.
> >
> > > The hunt for ldraw.ini could be:
> > > Windows:
> > > %LDRAWINI%
> > > %USERPROFILE%\ldraw.ini
> > > %ALLUSERSPROFILE%\ldraw.ini
> > > %windir%\ldraw.ini
> >
> > But wait. The reason given for looking in LDRAWDIR is for a central
> > networked LDRAW installation at a school. It'd be nice to have a
> > default ldraw.ini file at the central location that can be overridden
> > by one in a users home directory.
>
> Isn't that what %ALLUSERSPROFILE% is for?
I'm logged onto an NT domain right now at work and it's set to this:
ALLUSERSPROFILE=C:\Documents and Settings\All Users
That's on the local drive. But I suppose you're right, a competent
administrator could set it up somewhere on the network. What does a
typical networked Windows installation look like? My USERPROFILE
and ALLUSERSPROFILE are on the C drive, but the "My Documents" folder
on the start menu is mapped to a location on the network via the
"%USERPROFILE%\Start Menu\Shortcut to My Documents.lnk" file. I suspect
the admins created that lnk via the login script, but I'm not positive.
> LDRAWINI is just an opportunity for quickly temporarily using another
> specific ldraw.ini file.
I don't think I'll ever use it because it confuses me. If you have
both LDRAWDIR and LDRAWINI environment variables set, which setting
do you use to determine the LDRAWDIR: the LDRAWDIR environment var,
or the BaseDirectory setting in $LDRAWINI/ldraw.ini? If you have a
particularly evil Windows administrator who points both LDRAWINI and
LDRAWDIR to his undesireable parts directories, how does the poor
Windows user go about overriding it?
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > In lugnet.cad.dev, Don Heyse wrote:
> > > In lugnet.cad.dev, Lars C. Hassing wrote:
> > > > I think having ldraw.ini in LDRAWDIR is contradictory, the hen and
> > > > egg problem. To keep thing simple I would like to have only *one*
> > > > ldraw.ini, and since we're going to have it in
> > > > HOME/USERPROFILE/windir anyway to find the LDRAWDIR, I don't see any
> > > > reason to spread it out.
> > >
> > > > The hunt for ldraw.ini could be:
> > > > Windows:
> > > > %LDRAWINI%
> > > > %USERPROFILE%\ldraw.ini
> > > > %ALLUSERSPROFILE%\ldraw.ini
> > > > %windir%\ldraw.ini
> > >
> > > But wait. The reason given for looking in LDRAWDIR is for a central
> > > networked LDRAW installation at a school. It'd be nice to have a
> > > default ldraw.ini file at the central location that can be overridden
> > > by one in a users home directory.
> >
> > Isn't that what %ALLUSERSPROFILE% is for?
>
> I'm logged onto an NT domain right now at work and it's set to this:
>
> ALLUSERSPROFILE=C:\Documents and Settings\All Users
>
> That's on the local drive. But I suppose you're right, a competent
> administrator could set it up somewhere on the network. What does a
> typical networked Windows installation look like? My USERPROFILE
> and ALLUSERSPROFILE are on the C drive, but the "My Documents" folder
> on the start menu is mapped to a location on the network via the
> "%USERPROFILE%\Start Menu\Shortcut to My Documents.lnk" file. I suspect
> the admins created that lnk via the login script, but I'm not positive.
>
> > LDRAWINI is just an opportunity for quickly temporarily using another
> > specific ldraw.ini file.
>
> I don't think I'll ever use it because it confuses me. If you have
> both LDRAWDIR and LDRAWINI environment variables set, which setting
> do you use to determine the LDRAWDIR: the LDRAWDIR environment var,
> or the BaseDirectory setting in $LDRAWINI/ldraw.ini? If you have a
> particularly evil Windows administrator who points both LDRAWINI and
> LDRAWDIR to his undesireable parts directories, how does the poor
> Windows user go about overriding it?
Seems to me programs need the ability to specify the LDRAWINI directory (and
possibly LDRAWDIR) on the command line, for non-standard setups.
Maybe the library needs an Ldraw-specific getopt[1] function as well.
ROSCO
[1] http://www.rt.com/man/getopt.3.html
|
|
| |
In lugnet.cad.dev, Ross Crawford wrote:
> Seems to me programs need the ability to specify the LDRAWINI directory
> (and possibly LDRAWDIR) on the command line, for non-standard setups.
I'm not sure what you're trying to say. Do you mean "USERS need the
ability to specify", or "programs need the ability to READ"? Either way,
that approach is for advanced users (software geeks) only. We're trying
to improve things for ordinary users, and forcing them run a command
prompt to use their preferred non-standard settings in their LDRAW
programs is just wrong. Even for an advanced user, how is this better
than just setting an environment variable right before running the
program?
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Ross Crawford wrote:
> > Seems to me programs need the ability to specify the LDRAWINI directory
> > (and possibly LDRAWDIR) on the command line, for non-standard setups.
>
> I'm not sure what you're trying to say. Do you mean "USERS need the
> ability to specify", or "programs need the ability to READ"? Either way,
> that approach is for advanced users (software geeks) only. We're trying
> to improve things for ordinary users, and forcing them run a command
> prompt to use their preferred non-standard settings in their LDRAW
> programs is just wrong. Even for an advanced user, how is this better
> than just setting an environment variable right before running the
> program?
And I'm pretty sure on Mac OS X, if you use the finder to activate
your program, you have no control whatsoever over the command line.
So you already need another way if you want to click on a LDR file
or link and have something happen.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Ross Crawford wrote:
> > Seems to me programs need the ability to specify the LDRAWINI directory
> > (and possibly LDRAWDIR) on the command line, for non-standard setups.
>
> I'm not sure what you're trying to say. Do you mean "USERS need the
> ability to specify", or "programs need the ability to READ"?
Well to be usable, both must be implemented.
> Either way,
> that approach is for advanced users (software geeks) only. We're trying
> to improve things for ordinary users, and forcing them run a command
> prompt to use their preferred non-standard settings in their LDRAW
> programs is just wrong. Even for an advanced user, how is this better
> than just setting an environment variable right before running the
> program?
As I said it would only be for non-standard setups. I think the Lars' search
list is ample for the vast majority of people.
Those using networks, etc, probably would classify as "advanced users" or need
help from their network administrators to set stuff up anyway, so creating a
shortcut (or whatever for their platform) with command line parameters is
probably not gonna be a big issue.
I think trying to get a solution that works automatically for every environment
is next to impossible, this would cater for those that "dont fit the mold".
ROSCO
|
|
| |
In lugnet.cad.dev, Ross Crawford wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Ross Crawford wrote:
> > > Seems to me programs need the ability to specify the LDRAWINI directory
> > > (and possibly LDRAWDIR) on the command line, for non-standard setups.
> >
> > That approach is for advanced users (software geeks) only. We're trying
> > to improve things for ordinary users, and forcing them run a command
> > prompt to use their preferred non-standard settings in their LDRAW
> > programs is just wrong. Even for an advanced user, how is this better
> > than just setting an environment variable right before running the
> > program?
>
> As I said it would only be for non-standard setups. I think the Lars'
> search list is ample for the vast majority of people.
>
> Those using networks, etc, probably would classify as "advanced users"
> or need help from their network administrators to set stuff up anyway,
> so creating a shortcut (or whatever for their platform) with command
> line parameters is probably not gonna be a big issue.
>
> I think trying to get a solution that works automatically for every
> environment is next to impossible, this would cater for those that
> "dont fit the mold".
Ok, I can see where I myself might use this in a pinch because I
almost always run things from the command prompt. However, even I
would rather set an environment variable or use some other global
setting in an ini file. Why? Because if I use the commandline
shortcut, or script file, I have to duplicate the same setting (perhaps
with a different syntax) for every LDRAW program I want to use. That's
exactly what we're trying to avoid here. We want a way for all the
LDRAW programs to easily SHARE the SAME settings.
But hey, if you're only interested in one program then maybe a command
line option is for you. Which program were you thinking of, and what
sort of command line syntax are we talking about? Might as well flesh
the idea out.
Don
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> An other thing regards the location of the ini file. In past weeks I got
> several questions regarding the central installation of LDraw and MLCad,
> where universities and schools are trying to install everything on a server,
> read-only for the user. Users should either not have the possiblity to
> change configs ore should be restricted somehow.
How will such an installation be laid out?
Will users install MLCad on their local machine and
MLCad will then first thing ask the user to locate the LDrawDir,
which the user specifies as e.g. L:\LDraw or \\server\LDraw ?
If the search path should also contain \\server\ExtraParts
then you can not place that information in \\server\LDraw\ldraw.ini
if \\server\LDraw is used from Unix clients also.
These clients would expect e.g. /net/server/ExtraParts in the ldraw.ini.
How do we solve that?
How can the user or administrator specify where to find ldraw.ini?
I'm beginning to understand why you want ldraw.ini in LDrawDir.
Then you can place ExtraParts below LDrawDir,
i.e. \\server\LDraw\ExtraParts, and the search path would include
<LDRAWDIR>\ExtraParts which is usable on all platforms.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Michael Lachmann wrote:
> > An other thing regards the location of the ini file. In past weeks I got
> > several questions regarding the central installation of LDraw and MLCad,
> > where universities and schools are trying to install everything on a server,
> > read-only for the user. Users should either not have the possiblity to
> > change configs ore should be restricted somehow.
>
> How will such an installation be laid out?
>
> Will users install MLCad on their local machine and
> MLCad will then first thing ask the user to locate the LDrawDir,
> which the user specifies as e.g. L:\LDraw or \\server\LDraw ?
>
> If the search path should also contain \\server\ExtraParts
> then you can not place that information in \\server\LDraw\ldraw.ini
> if \\server\LDraw is used from Unix clients also.
> These clients would expect e.g. /net/server/ExtraParts in the ldraw.ini.
>
> How do we solve that?
> How can the user or administrator specify where to find ldraw.ini?
>
> I'm beginning to understand why you want ldraw.ini in LDrawDir.
> Then you can place ExtraParts below LDrawDir,
> i.e. \\server\LDraw\ExtraParts, and the search path would include
> <LDRAWDIR>\ExtraParts which is usable on all platforms.
Here's how I see it working:
1. The admin creates an LDRAW directory on the server.
2. The admin creates extra parts directories under <LDRAWDIR> on the server.
3. The admin creates an ldraw.ini file in the <LDRAWDIR> using the new
GUI program and adds extra LDrawSearch paths for the extra dirs using
the OS neutral <LDRAWDIR>\ExtraParts format.
4. The admin edits the NT login script \\PDC\netlogin\login.bat
to set LDRAWDIR env variable. This will cause all NT users
to find the ldraw.ini file on the server and use the extra dirs.
4.5. Depending on the installation, there may be a global script for
UNIX clients that does the same thing.
4.75 For networked Mac users he creates the global pref file
/Library/Preferences/org.ldraw.plist with LDRAWDIR and LDrawSearch
settings in it.
5. The user logs on and runs MLCAD off of the server. It reads
the LDRAWDIR environment variable and finds the <LDRAWDIR>/ldraw.ini file
with the extra part directories.
6. The user decides he wants to add the MegaBlok parts. He copies the
<LDRAWDIR>ldraw.ini file to his HOME directory and adds a path for
<HOME>/clones where he has stored the clone parts. Maybe he even adds
the tags <PARTS> and <CLONES> to identify them better for some future
version of LPUB.
7. He also adds the knex parts and labels the directory with the extra tags
<PARTS>, <KNEX>, and <SKIP> because he wants to search for knex parts
before things in the <MODELDIR>, but only when he's enabled KNEX. Most
of the time he wants to ignore them.
8. Finally he adds the boxer parts and labels that directory <PARTS>, <BOXES>,
and <SKIP> for similar reasons. He can't put them in %LDRAWDIR%\PARTS\B
because that's set to read only by the admin. Hopefully a future version
of the boxer program will be able to find them in the new location. Or
maybe a future version of Windows will allow a user to create real soft
links instead of those useless shortcut links...
I think this all works ok with the search strategy I listed earlier.
Don
|
|
| |
"Lars C. Hassing" <sp.lars@am.hassings.dk> schrieb im Newsbeitrag
news:Hu438x.Ko0@lugnet.com...
> In lugnet.cad.dev, Michael Lachmann wrote:
> > An other thing regards the location of the ini file. In past weeks I got
> > several questions regarding the central installation of LDraw and MLCad,
> > where universities and schools are trying to install everything on a • server,
> > read-only for the user. Users should either not have the possiblity to
> > change configs ore should be restricted somehow.
>
> How will such an installation be laid out?
>
> Will users install MLCad on their local machine and
> MLCad will then first thing ask the user to locate the LDrawDir,
> which the user specifies as e.g. L:\LDraw or \\server\LDraw ?
They install everything on a NT network, using a server which hold the ldraw
library and also a copy of MLCad.
I recommended to do the installation on the clients using small registry
scripts which setup the registry for the user, pointing
them to the correct installation of the ldraw library already.
I don't know if they used UNC or plain old style directory specifications -
but I guess the old one with X:\\bla\bla.
>
> If the search path should also contain \\server\ExtraParts
> then you can not place that information in \\server\LDraw\ldraw.ini
> if \\server\LDraw is used from Unix clients also.
> These clients would expect e.g. /net/server/ExtraParts in the ldraw.ini.
Depends, using NFS and under Linux there is another thing (I don't know its
name, but it simulates an NT server), each operating system can specify the
file names however they like. I didn't see any mixed network with unix and
NT within one department - even in the company I'm working for, we have a
lot of different systems including unix and nt systems. But certain
applications are accessible from nt side only, while the others can be
reached via terminal simulations. We do not have any direct storage on unix
which needs to be accessed from nt. Even if its possible.
>
> How do we solve that?
> How can the user or administrator specify where to find ldraw.ini?
>
> I'm beginning to understand why you want ldraw.ini in LDrawDir.
> Then you can place ExtraParts below LDrawDir,
> i.e. \\server\LDraw\ExtraParts, and the search path would include
> <LDRAWDIR>\ExtraParts which is usable on all platforms.
> /Lars
Yes, I'm also starting to think about unix style path notation, this way we
can use them directly on unix without modification, on windows we could
replace the slash against a back-slash.
Michael
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hu4BBu.20n4@lugnet.com...
<SNIP>
> Here's how I see it working:
>
> 1. The admin creates an LDRAW directory on the server.
> 2. The admin creates extra parts directories under <LDRAWDIR> on the • server.
> 3. The admin creates an ldraw.ini file in the <LDRAWDIR> using the new
> GUI program and adds extra LDrawSearch paths for the extra dirs using
> the OS neutral <LDRAWDIR>\ExtraParts format.
> 4. The admin edits the NT login script \\PDC\netlogin\login.bat
> to set LDRAWDIR env variable. This will cause all NT users
> to find the ldraw.ini file on the server and use the extra dirs.
> 4.5. Depending on the installation, there may be a global script for
> UNIX clients that does the same thing.
> 4.75 For networked Mac users he creates the global pref file
> /Library/Preferences/org.ldraw.plist with LDRAWDIR and LDrawSearch
> settings in it.
> 5. The user logs on and runs MLCAD off of the server. It reads
> the LDRAWDIR environment variable and finds the <LDRAWDIR>/ldraw.ini • file
> with the extra part directories.
> 6. The user decides he wants to add the MegaBlok parts. He copies the
> <LDRAWDIR>ldraw.ini file to his HOME directory and adds a path for
> <HOME>/clones where he has stored the clone parts. Maybe he even adds
> the tags <PARTS> and <CLONES> to identify them better for some future
> version of LPUB.
> 7. He also adds the knex parts and labels the directory with the extra • tags
> <PARTS>, <KNEX>, and <SKIP> because he wants to search for knex parts
> before things in the <MODELDIR>, but only when he's enabled KNEX. • Most
> of the time he wants to ignore them.
> 8. Finally he adds the boxer parts and labels that directory <PARTS>, • <BOXES>,
> and <SKIP> for similar reasons. He can't put them in • %LDRAWDIR%\PARTS\B
> because that's set to read only by the admin. Hopefully a future • version
> of the boxer program will be able to find them in the new location. • Or
> maybe a future version of Windows will allow a user to create real • soft
> links instead of those useless shortcut links...
>
> I think this all works ok with the search strategy I listed earlier.
>
> Don
There is also some network software for NT and unix, which mounts a network
drive as a sub-directory (event under Windows). This could be a possible way
to do as well.
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
>
> "Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
> news:Hu4BBu.20n4@lugnet.com...
> <SNIP>
> > Here's how I see it working:
> >
> > 1. The admin creates an LDRAW directory on the server.
> > 2. The admin creates extra parts directories under <LDRAWDIR> on the server.
> > 3. The admin creates an ldraw.ini file in the <LDRAWDIR> using the new
> > GUI program and adds extra LDrawSearch paths for the extra dirs using
> > the OS neutral <LDRAWDIR>\ExtraParts format.
> > 4. The admin edits the NT login script \\PDC\netlogin\login.bat
> > to set LDRAWDIR env variable. This will cause all NT users
> > to find the ldraw.ini file on the server and use the extra dirs.
> > 4.5. Depending on the installation, there may be a global script for
> > UNIX clients that does the same thing.
> > 4.75 For networked Mac users he creates the global pref file
> > /Library/Preferences/org.ldraw.plist with LDRAWDIR and LDrawSearch
> > settings in it.
> > 5. The user logs on and runs MLCAD off of the server. It reads
> > the LDRAWDIR environment variable and finds the <LDRAWDIR>/ldraw.ini file
> > with the extra part directories.
> > 6. The user decides he wants to add the MegaBlok parts. He copies the
> > <LDRAWDIR>ldraw.ini file to his HOME directory and adds a path for
> > <HOME>/clones where he has stored the clone parts. Maybe he even adds
> > the tags <PARTS> and <CLONES> to identify them better for some future
> > version of LPUB.
> > 7. He also adds the knex parts and labels the directory with the extra tags
> > <PARTS>, <KNEX>, and <SKIP> because he wants to search for knex parts
> > before things in the <MODELDIR>, but only when he's enabled KNEX. Most
> > of the time he wants to ignore them.
> > 8. Finally he adds the boxer parts and labels that directory <PARTS>, <BOXES>,
> > and <SKIP> for similar reasons. He can't put them in %LDRAWDIR%\PARTS\B
> > because that's set to read only by the admin. Hopefully a future version
> > of the boxer program will be able to find them in the new location. Or
> > maybe a future version of Windows will allow a user to create real soft
> > links instead of those useless shortcut links...
> >
> > I think this all works ok with the search strategy I listed earlier.
> >
> > Don
>
> There is also some network software for NT and unix, which mounts a network
> drive as a sub-directory (event under Windows). This could be a possible way
> to do as well.
There are all sorts of network mounting tools out there. I'm not sure,
but perhaps you're thinking of samba. I've used that from the unix side
to be both a client and a server for Windows networks. But there are
plenty of other more obscure methods. I think I've even used software
to mount an ftp site as a directory under Windows.
Anyhow, the point I was trying to make is that it's possible to put
it all in one place on the server and make it available to everyone
with minimal effort. Then the users can easily override the default
settings.
The MLCAD registry settings could be created by a regedit script in
the global \\PDC\netlogin\login.bat file. And I believe there are other
ways to push registry settings onto clients from the server.
I see you didn't object to all the new tags I proposed in steps
6, 7, and 8. ;^) What do you think of <SKIP> as third alternative
to <HIDE> and <SHOW>?
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Ross Crawford wrote:
> > In lugnet.cad.dev, Don Heyse wrote:
> > > In lugnet.cad.dev, Ross Crawford wrote:
> > > > Seems to me programs need the ability to specify the LDRAWINI directory
> > > > (and possibly LDRAWDIR) on the command line, for non-standard setups.
> > >
> > > That approach is for advanced users (software geeks) only. We're trying
> > > to improve things for ordinary users, and forcing them run a command
> > > prompt to use their preferred non-standard settings in their LDRAW
> > > programs is just wrong. Even for an advanced user, how is this better
> > > than just setting an environment variable right before running the
> > > program?
> >
> > As I said it would only be for non-standard setups. I think the Lars'
> > search list is ample for the vast majority of people.
> >
> > Those using networks, etc, probably would classify as "advanced users"
> > or need help from their network administrators to set stuff up anyway,
> > so creating a shortcut (or whatever for their platform) with command
> > line parameters is probably not gonna be a big issue.
> >
> > I think trying to get a solution that works automatically for every
> > environment is next to impossible, this would cater for those that
> > "dont fit the mold".
>
> Ok, I can see where I myself might use this in a pinch because I
> almost always run things from the command prompt. However, even I
> would rather set an environment variable or use some other global
> setting in an ini file. Why? Because if I use the commandline
> shortcut, or script file, I have to duplicate the same setting (perhaps
> with a different syntax) for every LDRAW program I want to use. That's
> exactly what we're trying to avoid here. We want a way for all the
> LDRAW programs to easily SHARE the SAME settings.
>
> But hey, if you're only interested in one program then maybe a command
> line option is for you. Which program were you thinking of, and what
> sort of command line syntax are we talking about? Might as well flesh
> the idea out.
Well I don't know how mac command lines work but I was thinking along these
lines:
Windoze:
xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
Unix:
xxx --ldrawdir ${HOME}/ldraw --ldrawini /etc/ldraw
You might also wanna provide old single letter switches -d & -i or something.
If this could be handled by a platform independent library, then any or all of
the Ldraw suite programs could easily parse these options.
ROSCO
|
|
| |
"Ross Crawford" <rosscraw@bigpond.net.au> schrieb im Newsbeitrag
news:Hu4L6M.1Eyo@lugnet.com...
<SNIP>
> Well I don't know how mac command lines work but I was thinking along • these
> lines:
>
> Windoze:
> xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
in some cases "xxx.exe /LDRAWDIR=C:/LDRAW /LDRAWINI=\\LDRAW_BOX/INI will
work too.
There is no standard function set in windows parsing this commands, every
program can do that how it likes. e.g. you could replace the = by a white
space.
Michael
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hu4BBu.20n4@lugnet.com...
<SNIP>
> 6. The user decides he wants to add the MegaBlok parts. He copies the
> <LDRAWDIR>ldraw.ini file to his HOME directory and adds a path for
> <HOME>/clones where he has stored the clone parts. Maybe he even adds
> the tags <PARTS> and <CLONES> to identify them better for some future
> version of LPUB.
> 7. He also adds the knex parts and labels the directory with the extra • tags
> <PARTS>, <KNEX>, and <SKIP> because he wants to search for knex parts
> before things in the <MODELDIR>, but only when he's enabled KNEX. • Most
> of the time he wants to ignore them.
> 8. Finally he adds the boxer parts and labels that directory <PARTS>, • <BOXES>,
> and <SKIP> for similar reasons. He can't put them in • %LDRAWDIR%\PARTS\B
> because that's set to read only by the admin. Hopefully a future • version
> of the boxer program will be able to find them in the new location. • Or
> maybe a future version of Windows will allow a user to create real • soft
> links instead of those useless shortcut links...
>
> I think this all works ok with the search strategy I listed earlier.
>
> Don
Ahhh I didn't see that in the first place, good that you pointed me to,
thanks.
I generally do not recommend to bring in third party definitions into the
standard definition. So in my opinion there is no need to take care on Knex,
MegaBloks or what ever in our definition of keywords - and just a second -
this sounds like the user will define tags - no that shouldn't happen.
We shouldn't drop the ball - but we are going to define a way of specifying
how a ldraw-lib compatible software should go through the directories when
it is searching for a part, nothing else. Additionally I thought SHOW/HIDE
might be nice in order to allow a user to define what he will get in a part
library display.
If a user is trying to use any of our programms to make none lego models, he
will be an expirienced user anyway - and I guess be able to use different
ini files.
Please don't add any none LDraw specific keywords or definition - and this
should be a programming language either :-)
Michael
|
|
| |
> Well I don't know how mac command lines work but I was thinking along these
> lines:
>
> Windoze:
> xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
>
> Unix:
> xxx --ldrawdir ${HOME}/ldraw --ldrawini /etc/ldraw
Mac OS 9 does not have a command line. That OS is a dinosaur.
You can think of Mac OS X as a decendant of BSD, with a Mac OS 9 look-a-like
window server. In fact, you can remove Apple's window server and add X11,
turning Mac OS X into just another Unix.
Also, the Unix core of Mac OS X (Darwin) is open source (headed by Jordan
Hubbard, creator of FreeBSD) and can be installed on a PC (x86). You can't
install Apple's window server though. But you can install X11.
http://www.opendarwin.org/
So, just think of OS X as just another UNIX.
The biggest difference between Mac OS X and other Unixes is the users. Mac OS X
users are very untechnical compared to other Unix users. It would be a bad idea
to require them to use the command line. They wont even know what you are
talking about.
James
|
|
| |
In lugnet.cad.dev, James Reynolds wrote:
> > Well I don't know how mac command lines work but I was thinking along these
> > lines:
> >
> > Windoze:
> > xxx.exe /LDRAWDIR=C:\LDRAW /LDRAWINI=\\LDRAW_BOX\INI
> >
> > Unix:
> > xxx --ldrawdir ${HOME}/ldraw --ldrawini /etc/ldraw
>
> Mac OS 9 does not have a command line. That OS is a dinosaur.
[snip]
> So, just think of OS X as just another UNIX.
>
> The biggest difference between Mac OS X and other Unixes is the users. Mac OS X
> users are very untechnical compared to other Unix users. It would be a bad idea
> to require them to use the command line. They wont even know what you are
> talking about.
Again, I'm not talking about most users - most will be covered by the search
paths proposed earlier in the thread. This would only be for non-standard
installations, where the people installing WOULD be likely to know what I am
talking about.
The only reason I proposed this idea is so the parts & ini file location is
"open-ended" - to provide the ultimate flexibility for those that want to abuse
it. If you create a closed list of options, sure as eggs someone will come along
later saying "but how do I get it to work THIS way?". Better to allow for that
eventuality from the start, IMO.
ROSCO
|
|
| |
> > The biggest difference between Mac OS X and other Unixes is the users. Mac OS X
> > users are very untechnical compared to other Unix users. It would be a bad idea
> > to require them to use the command line. They wont even know what you are
> > talking about.
>
> Again, I'm not talking about most users - most will be covered by the search
> paths proposed earlier in the thread. This would only be for non-standard
> installations, where the people installing WOULD be likely to know what I am
> talking about.
>
> The only reason I proposed this idea is so the parts & ini file location is
> "open-ended" - to provide the ultimate flexibility for those that want to abuse
> it. If you create a closed list of options, sure as eggs someone will come along
> later saying "but how do I get it to work THIS way?". Better to allow for that
> eventuality from the start, IMO.
Right. I actually manage 350 Macs and I tried to put LDraw on them and ran into
several problems that I had to take up with the Mac developers. So anything
that makes this easier for admins is good in my opinion.
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> "Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
> news:Hu4BBu.20n4@lugnet.com...
> <SNIP>
> > 6. The user decides he wants to add the MegaBlok parts. He copies the
> > <LDRAWDIR>ldraw.ini file to his HOME directory and adds a path for
> > <HOME>/clones where he has stored the clone parts. Maybe he even adds
> > the tags <PARTS> and <CLONES> to identify them better for some future
> > version of LPUB.
> > 7. He also adds the knex parts and labels the directory with the extra tags
> > <PARTS>, <KNEX>, and <SKIP> because he wants to search for knex parts
> > before things in the <MODELDIR>, but only when he's enabled KNEX. Most
> > of the time he wants to ignore them.
> > 8. Finally he adds the boxer parts and labels that directory <PARTS>, <BOXES>,
> > and <SKIP> for similar reasons. He can't put them in %LDRAWDIR%\PARTS\B
> > because that's set to read only by the admin. Hopefully a future version
> > of the boxer program will be able to find them in the new location. Or
> > maybe a future version of Windows will allow a user to create real soft
> > links instead of those useless shortcut links...
> >
> > I think this all works ok with the search strategy I listed earlier.
> >
> > Don
>
> Ahhh I didn't see that in the first place, good that you pointed me to,
> thanks.
> I generally do not recommend to bring in third party definitions into the
> standard definition. So in my opinion there is no need to take care on Knex,
> MegaBloks or what ever in our definition of keywords - and just a second -
> this sounds like the user will define tags - no that shouldn't happen.
>
> We shouldn't drop the ball - but we are going to define a way of specifying
> how a ldraw-lib compatible software should go through the directories when
> it is searching for a part, nothing else. Additionally I thought SHOW/HIDE
> might be nice in order to allow a user to define what he will get in a part
> library display.
> If a user is trying to use any of our programms to make none lego models, he
> will be an expirienced user anyway - and I guess be able to use different
> ini files.
>
> Please don't add any none LDraw specific keywords or definition - and this
> should be a programming language either :-)
Oh I don't know. I'm still hoping some of these ideas will eventually
start to grow on you. Hopefully Lars will write some really nice code
that finds the parts search list and somehow associates a list of tags
with each directory in the list. If he makes SHOW or HIDE the first tag
then you should be able to ignore everything else until someday when you
decide it might be really cool to associate some other attributes with
the directories.
I'm also kinda hoping that Lars' code library will allow programs, and
his GUI will allow advanced users to add whatever tags they want, in
addition to the HIDE or SHOW tags. This will allow us to create new
features for our programs where certain parts directories are known to
have special uses, like the boxer parts they're talking about right now
in the Datsville animation thread.
Anyhow, I will now attempt to hypnotize you. Repeat after me. <HIDE>,
<SHOW>, or <SKIP>. <HIDE>, <SHOW>, or <SKIP>. <HIDE>, <SHOW>, or <SKIP>.
You're getting veeerrry sleeeepy...
Enjoy,
Don
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hu6s61.1FM9@lugnet.com...
<SNIP>
> Oh I don't know. I'm still hoping some of these ideas will eventually
> start to grow on you. Hopefully Lars will write some really nice code
> that finds the parts search list and somehow associates a list of tags
> with each directory in the list. If he makes SHOW or HIDE the first tag
> then you should be able to ignore everything else until someday when you
> decide it might be really cool to associate some other attributes with
> the directories.
>
> I'm also kinda hoping that Lars' code library will allow programs, and
> his GUI will allow advanced users to add whatever tags they want, in
> addition to the HIDE or SHOW tags. This will allow us to create new
> features for our programs where certain parts directories are known to
> have special uses, like the boxer parts they're talking about right now
> in the Datsville animation thread.
>
> Anyhow, I will now attempt to hypnotize you. Repeat after me. <HIDE>,
> <SHOW>, or <SKIP>. <HIDE>, <SHOW>, or <SKIP>. <HIDE>, <SHOW>, or <SKIP>.
> You're getting veeerrry sleeeepy...
"Snip", you got me two days sleeping ;-)
I do not have anything against additional keyword, but I realy do not get
what's behind them you suggest. Somewhere I missed the point I guess.
Michael
|
|
| |
In lugnet.cad.dev, James Reynolds wrote:
> Mac OS 9 does not have a command line. That OS is a dinosaur.
rofl. I think this qualifies as quote of the day.
Steve
|
|
| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, James Reynolds wrote:
>
> > Mac OS 9 does not have a command line. That OS is a dinosaur.
>
> rofl. I think this qualifies as quote of the day.
Ok, so maybe there was a bit of irony, considering Mac OS X's roots are much
older than 9's. But the lack of pre-emptive multiprocessing, protected memory,
and other more evolved stuff does make OS 9 a dinosaur. Apple's washed their
hands of the OS. One of the funnies thing I saw about this was the Mac OS 9's
technical lead talk about the future of Mac OS 9 *after* the release of Mac OS
X.
http://homepage.mac.com/stattenf/FutureOfMacOS9/
audio is kinda bad though :(
James
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> Don Heyse schrieb:
> > Anyhow, I will now attempt to hypnotize you. Repeat after me. <HIDE>,
> > <SHOW>, or <SKIP>. <HIDE>, <SHOW>, or <SKIP>. <HIDE>, <SHOW>, or <SKIP>.
> > You're getting veeerrry sleeeepy...
>
> "Snip", you got me two days sleeping ;-)
>
> I do not have anything against additional keyword, but I realy do not get
> what's behind them you suggest. Somewhere I missed the point I guess.
Hmmm, I must've put myself to sleep as well. Actually, I've been a bit
busy lately. Now what was I trying to say...
I guess I was thinking that a <SKIP> tag might be a third choice between
<HIDE> and <SHOW>, but after a few days I now think it might be
complimentary to <HIDE> and <SHOW>. What I was trying to accomplish
was a tag which allows people to insert a part directory in a specific
location in the directory search list, but to have the programs ignore
it most of the time. However LDRAW programs would need to have some way
to temporarily activate the <SKIP> directory for this to be useful. The
idea was to be able to temporarily activate a normally skipped directory
to quickly see the effects of using an alternate set of parts. Maybe
someone would use it to enable/disable unofficial parts, or (hold your
nose if you find this disturbing) perhaps enable/disable clone parts.
I suppose this could be done by substituting INI files and restarting
the program, but I thought it might be nice to try and define a tag
to make it easier and quicker. We'd have to agree on it up front
though because there's no point having a <SKIP> tag if some of the
LDRAW programs don't skip the directory.
Anyhow, I was just trying to get as many ideas out there as possible
before Lars finishes his code and things are set in stone.
Enjoy,
Don
|
|
| |
86 messages have been posted in this thread so far. I don't have a chance to
catch up what has been discussed by reading all posts.
Is it possible to make a brief and relatively easy-to-read summary of the most
significant suggestions, and what where the current discussion tends to lead to?
I think that this could be benificial for more than just me.
Just one small question: will these parameters be put in ldraw.ini and/or the
system's table of environment variables? Or somewhere else, like in the
%LDrawBaseDir%? (Hopefully not the third option) Personally, I would really
prefer ldraw.ini only. If an environment variable, is it portable to use 8+
characters?
Any another sillier question just to show my ignorance: Pre and post stands for
before and after. In this case, before and after what? Before scanning the
default search path for LCad files I guess? If so, will it stop scanning by the
first match?
Is there a page where the current consensus is published?
Well, that was a little more than jst one question...
/Tore
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:HuD629.DxI@lugnet.com...
<SNIP>
> I guess I was thinking that a <SKIP> tag might be a third choice between
> <HIDE> and <SHOW>, but after a few days I now think it might be
> complimentary to <HIDE> and <SHOW>. What I was trying to accomplish
> was a tag which allows people to insert a part directory in a specific
> location in the directory search list, but to have the programs ignore
> it most of the time. However LDRAW programs would need to have some way
> to temporarily activate the <SKIP> directory for this to be useful. The
> idea was to be able to temporarily activate a normally skipped directory
> to quickly see the effects of using an alternate set of parts. Maybe
> someone would use it to enable/disable unofficial parts, or (hold your
> nose if you find this disturbing) perhaps enable/disable clone parts.
>
> I suppose this could be done by substituting INI files and restarting
> the program, but I thought it might be nice to try and define a tag
> to make it easier and quicker. We'd have to agree on it up front
> though because there's no point having a <SKIP> tag if some of the
> LDRAW programs don't skip the directory.
Ok now I understand, might be a nice idea. The drawback is that it would
"only" allow one alternate part enabling not more. I can already hear people
saying: Oh nice can you make that configureable so that I can have multiple
sub-directories to enable by selecting a configuration from a menu, let say
a SKIP opt 1, SKIP opt 2 ...?
> Anyhow, I was just trying to get as many ideas out there as possible
> before Lars finishes his code and things are set in stone.
Thats fine, nothing against that. I'm still open to additional ideas ...
Michael
|
|
| |
In lugnet.cad.dev, Tore Eriksson wrote:
> 86 messages have been posted in this thread so far. I don't have a chance to
> catch up what has been discussed by reading all posts.
>
> Is it possible to make a brief and relatively easy-to-read summary of the most
> significant suggestions, and what where the current discussion tends to lead to?
> I think that this could be benificial for more than just me.
I took the time to read all the posts, and I still would like a summary. It
seems like the discussion has converged to conclusion, but I'd like to see the
conclusion written up.
I know that Lars is writing up code to match the conclusion, but a doc to go
with that would be greatly appreciated.
Kevin
|
|
| |
"Tore Eriksson" <tore.eriksson@mbox325.swipnet.se> schrieb im Newsbeitrag
news:HuDDv0.1KDF@lugnet.com...
> 86 messages have been posted in this thread so far. I don't have a chance • to
> catch up what has been discussed by reading all posts.
>
> Is it possible to make a brief and relatively easy-to-read summary of the • most
> significant suggestions, and what where the current discussion tends to • lead to?
> I think that this could be benificial for more than just me.
Ok I try and hope that I do not forget something here, all others please
correct me if i'm wrong - but no cheating!
The discussion is about finding a way to specify alternate directories to be
searched before, after or inbetween the standard ldraw directories. Each
directory has to be on a single line preseeded by optional keywords
indicating if you would like to see parts in this directory in a part view
(e.g. MLCad's Part-Preview) or not.
Another keyword will tell the programm if the directory specified is a
sub-directory of a standard one or not.
Here the general syntax:
The definition begins with
[LDrawSearch]
followed by one or more lines like
n = <VisibilityOption> [<PathKeyname>]Path
where n is a running nummber starting with 1 and counting up,
VisibilityOption currently is one of
<SHOW> .... to display parts in this directory
<HIDE> .... to use them when rendering a model only, but not to display
them a useable parts
more options might follow
PathKeyname is one of the standard directories
<LDRAWDIR> is e.g. C:\LDRAW
<MODELDIR> is the current directory of your project or the directory
where the current loaded file is located.
more paths might follow
As an expamle the ini section for the standard search path:
[LDrawSearch]
1 = <SHOW> <MODELDIR>
2 = <HIDE> <LDRAWDIR>P
3 = <SHOW> <LDRAWDIR>Parts
4 = <SHOW> <LDRAWDIR>Models
> Just one small question: will these parameters be put in ldraw.ini and/or • the
> system's table of environment variables? Or somewhere else, like in the
> %LDrawBaseDir%? (Hopefully not the third option) Personally, I would • really
> prefer ldraw.ini only. If an environment variable, is it portable to use • 8+
> characters?
We suggested to have that in the ldraw.ini, but it might also be used in
environment variables and
in the registry as well - but I believe we said in the file now ... (not
sure anymore).
>
> Any another sillier question just to show my ignorance: Pre and post • stands for
> before and after. In this case, before and after what? Before scanning the
> default search path for LCad files I guess? If so, will it stop scanning • by the
> first match?
You can insert your directories wherever you like, before, after or between
the standard lines.
>
> Is there a page where the current consensus is published?
Not yet.
>
>
> Well, that was a little more than jst one question...
Doesn't matter!
> /Tore
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> Ok now I understand, might be a nice idea. The drawback is that it would
> "only" allow one alternate part enabling not more. I can already hear people
> saying: Oh nice can you make that configureable so that I can have multiple
> sub-directories to enable by selecting a configuration from a menu, let say
> a SKIP opt 1, SKIP opt 2 ...?
Exactly. That's what the <CLONE>, <KNEX>, <BOXES> etc. tags I mentioned
previously were for. We could work out later whether these are user
defined or LSC defined tags. The important part for now would be to
agree that <SKIP> means ignore the directory under normal circumstances.
Enjoy,
Don
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> Ok I try and hope that I do not forget something here, all others please
> correct me if i'm wrong - but no cheating!
>
> The discussion is about finding a way to specify alternate directories to be
> searched before, after or inbetween the standard ldraw directories. Each
> directory has to be on a single line preseeded by optional keywords
> indicating if you would like to see parts in this directory in a part view
> (e.g. MLCad's Part-Preview) or not.
> Another keyword will tell the programm if the directory specified is a
> sub-directory of a standard one or not.
>
> Here the general syntax:
>
> The definition begins with
>
> [LDrawSearch]
>
> followed by one or more lines like
>
> n = <VisibilityOption> [<PathKeyname>]Path
>
> where n is a running nummber starting with 1 and counting up,
> VisibilityOption currently is one of
> <SHOW> .... to display parts in this directory
> <HIDE> .... to use them when rendering a model only, but not to display
> them a useable parts
> more options might follow
>
> PathKeyname is one of the standard directories
> <LDRAWDIR> is e.g. C:\LDRAW
> <MODELDIR> is the current directory of your project or the directory
> where the current loaded file is located.
> more paths might follow
>
> As an expamle the ini section for the standard search path:
> [LDrawSearch]
> 1 = <SHOW> <MODELDIR>
> 2 = <HIDE> <LDRAWDIR>P
> 3 = <SHOW> <LDRAWDIR>Parts
> 4 = <SHOW> <LDRAWDIR>Models
Currently my code doesn't expect all the spaces above, but I'm open to that.
The LDrawSetup program that I'm also writing at the same time
can not preserve the spaces if you add or delete options,
so it will ruin any nice table formatting you have made in Notepad.
However, to support advanced users who are only going to use an editor
I guess we should allow spaces.
Also I currently use a \ in "2=<HIDE><LDRAWDIR>\P" because I have
always thought of it as variable substitution.
However, you could also consider <LDRAWDIR> as a flag (like <HIDE> is a flag)
saying that the following path is a subpath to LDRAWDIR.
In that case it makes sense to omit the \.
\ or / will appear anyway in the file and are not a problem to handle.
More comments on that?
> > Just one small question: will these parameters be put in ldraw.ini and/or • the
> > system's table of environment variables? Or somewhere else, like in the
> > %LDrawBaseDir%? (Hopefully not the third option) Personally, I would • really
> > prefer ldraw.ini only. If an environment variable, is it portable to use • 8+
> > characters?
>
> We suggested to have that in the ldraw.ini, but it might also be used in
> environment variables and
> in the registry as well - but I believe we said in the file now ... (not
> sure anymore).
I support both env var and ini files.
Windows users will typically only use ini files, I guess.
I think it's portable to use 8+ characters for env vars.
> > Any another sillier question just to show my ignorance: Pre and post • stands for
> > before and after. In this case, before and after what? Before scanning the
> > default search path for LCad files I guess? If so, will it stop scanning • by the
> > first match?
>
> You can insert your directories wherever you like, before, after or between
> the standard lines.
Yes, originally I just suggested extra dirs before and after the usual search dirs.
However, with the current scheme you can rearrange the order of all dirs (usual and extras)
completely - though not advisable.
And the search will stop at first match like today. Eh, what else?
I'll post my current ideas of the API shortly
so you can have an idea of how to use the routines.
/Lars
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> The definition begins with
>
> [LDrawSearch]
>
> followed by one or more lines like
>
> n = <VisibilityOption> [<PathKeyname>]Path
>
> where n is a running nummber starting with 1 and counting up,
If it is just a sequential number, wouldn't it be easier to just leave it out
altogether, and say the directories will be searched in the order they appear in
the file?
ROSCO
|
|
| |
In lugnet.cad.dev, Ross Crawford wrote:
> In lugnet.cad.dev, Michael Lachmann wrote:
> > n = <VisibilityOption> [<PathKeyname>]Path
> >
> > where n is a running nummber starting with 1 and counting up,
>
> If it is just a sequential number, wouldn't it be easier to just leave it out
> altogether, and say the directories will be searched in the order they appear in
> the file?
The desire was to preserve standard Windows INI file formatting, and each data
line in an INI file has the form <key> = <value> (spaces optional). The numbers
were suggested as keys, with positive responses from the people that responded.
As a pratical manner, it's actually easier for a Windows program to load the
settings this way, since it can repeatedly ask for the next numeric key in the
[LDrawSearch] section until it gets a failed read.
--Travis
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Michael Lachmann wrote: • [snip]
> >
> > Here the general syntax:
> >
> > The definition begins with
> >
> > [LDrawSearch]
> >
> > followed by one or more lines like
> >
> > n = <VisibilityOption> [<PathKeyname>]Path
> >
> > where n is a running nummber starting with 1 and counting up,
> > VisibilityOption currently is one of
> > <SHOW> .... to display parts in this directory
> > <HIDE> .... to use them when rendering a model only, but not to display
> > them a useable parts
> > more options might follow
> >
> > PathKeyname is one of the standard directories
> > <LDRAWDIR> is e.g. C:\LDRAW
> > <MODELDIR> is the current directory of your project or the directory
> > where the current loaded file is located.
> > more paths might follow
> >
> > As an expamle the ini section for the standard search path:
> > [LDrawSearch]
> > 1 = <SHOW> <MODELDIR>
> > 2 = <HIDE> <LDRAWDIR>P
> > 3 = <SHOW> <LDRAWDIR>Parts
> > 4 = <SHOW> <LDRAWDIR>Models
>
> Currently my code doesn't expect all the spaces above, but I'm open to that.
> The LDrawSetup program that I'm also writing at the same time
> can not preserve the spaces if you add or delete options,
> so it will ruin any nice table formatting you have made in Notepad.
> However, to support advanced users who are only going to use an editor
> I guess we should allow spaces.
>
> Also I currently use a \ in "2=<HIDE><LDRAWDIR>\P" because I have
> always thought of it as variable substitution.
> However, you could also consider <LDRAWDIR> as a flag (like <HIDE> is a flag)
> saying that the following path is a subpath to LDRAWDIR.
> In that case it makes sense to omit the \.
> \ or / will appear anyway in the file and are not a problem to handle.
> More comments on that?
OK, so I'm a new guy in the ldraw dev community, but I figured if I don't say
something now it'll never get considered. So please go gently on me. I don't
know the full protocol you guys use to come up with these standers. But I'll
catch on soon.
Enough disclaimer, on to my comments...
Allowing white space is always a good idea.
I like having the backslash because I agree with Lars, I thought the
<LDRAWDIR>\Parts was a directory and the stuff in the brackets was the base
directory substitution.
Having said that, what about suggesting an additional flag. One that indicates
what kind of directory this is. For example:
[LDrawSearch]
1 = <SHOW> <MODELDIR> <Models>
2 = <HIDE> <LDRAWDIR>\P <Primitaves>
3 = <SHOW> <LDRAWDIR>\Parts <Parts>
4 = <SHOW> <LDRAWDIR>\Models <Models>
5 = <SHOW> <LDRAWDIR>\Unofficial <Unofficial Parts>
6 = <SHOW> <LDRAWDIR>\KimsParts <Unofficial Parts>
7 = <SHOW> C:\temp\downloaded_models <Models>
8 = <SHOW> C:\temp\MOTM <Models>
The final flag, if present, could be a user defined category that would let them
clump the contents of similar groups together. For instance, all things with
the <Unoficial Parts> tag could be shown together in a MLCad style tree view.
Or if the user preferred, they could just mark them all as <Parts> and all the
unofficial parts would show up under the <Parts> node along with the official
parts. And you could have several different directories that contain models and
they could all show up under the <Model> node.
I'm trying to explore options that allow a user to have multiple directories
with similar objects in them but have some control as how they would show up in
viewers or editors.
Any merit to this idea? Any ideas on better ways to get this kind of
functionality?
Kim
|
|
| |
"Kim Toll" <kim.toll@intel.com> schrieb im Newsbeitrag
news:HuHvvE.w2t@lugnet.com...
<SNIP>
>
> Allowing white space is always a good idea.
>
> I like having the backslash because I agree with Lars, I thought the
> <LDRAWDIR>\Parts was a directory and the stuff in the brackets was the • base
> directory substitution.
>
> Having said that, what about suggesting an additional flag. One that • indicates
> what kind of directory this is. For example:
>
> [LDrawSearch]
> 1 = <SHOW> <MODELDIR> <Models>
> 2 = <HIDE> <LDRAWDIR>\P <Primitaves>
> 3 = <SHOW> <LDRAWDIR>\Parts <Parts>
> 4 = <SHOW> <LDRAWDIR>\Models <Models>
> 5 = <SHOW> <LDRAWDIR>\Unofficial <Unofficial Parts>
> 6 = <SHOW> <LDRAWDIR>\KimsParts <Unofficial Parts>
> 7 = <SHOW> C:\temp\downloaded_models <Models>
> 8 = <SHOW> C:\temp\MOTM <Models>
>
> The final flag, if present, could be a user defined category that would • let them
> clump the contents of similar groups together. For instance, all things • with
> the <Unoficial Parts> tag could be shown together in a MLCad style tree • view.
> Or if the user preferred, they could just mark them all as <Parts> and all • the
> unofficial parts would show up under the <Parts> node along with the • official
> parts. And you could have several different directories that contain • models and
> they could all show up under the <Model> node.
This is a good idea, theoretically we can add anything at the end of this
line. Programms not willing to support can simply ignore it.
However in this case I would like to use quotationmarks - hello lars ;.-) -
to make clear where a directory start and where it ends. I've seen windows
and unix directories with names including < and > so ....
Michael
|
|
| |
"Travis Cobbs" <tcobbs@REMOVE.halibut.com> schrieb im Newsbeitrag
news:HuG3s7.qDu@lugnet.com...
<SNIP>
> > If it is just a sequential number, wouldn't it be easier to just leave • it out
> > altogether, and say the directories will be searched in the order they • appear in
> > the file?
>
> The desire was to preserve standard Windows INI file formatting, and each • data
> line in an INI file has the form <key> = <value> (spaces optional). The • numbers
> were suggested as keys, with positive responses from the people that • responded.
>
> As a pratical manner, it's actually easier for a Windows program to load • the
> settings this way, since it can repeatedly ask for the next numeric key in • the
> [LDrawSearch] section until it gets a failed read.
Easier ? Hmmm - when you read from a file its more easy to do it by hand and
read it line by line.
If you read from the registry there is a enum function which returns every
value in a key ...
I'm still somehow a favorit of no numbers and equals at the beginning of the
line .....
Michael
|
|
| |
I tend to agree on both points. I would like to point out that primitives is
mis-spelled in the example. Let's make sure that the official way has the
correct spelling ;-).
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> "Travis Cobbs" wrote:
> > The desire was to preserve standard Windows INI file formatting,
> > and each data line in an INI file has the form <key> = <value>
> > (spaces optional). The numbers were suggested as keys, with
> > positive responses from the people that responded.
> >
> > As a pratical manner, it's actually easier for a Windows program to
> > load the settings this way, since it can repeatedly ask for the next
> > numeric key in the [LDrawSearch] section until it gets a failed read.
>
> Easier ? Hmmm - when you read from a file its more easy to do it by
> hand and read it line by line.
> If you read from the registry there is a enum function which returns
> every value in a key ...
>
> I'm still somehow a favorit of no numbers and equals at the beginning
> of the line .....
Ah, but we've already covered this ground. In addition to the registry
functions, there are also Windows functions for reading and writing
to INI files in the format with the = sign. Search in this thread
for getprivateprofilestring and/or writeprivateprofilestring. It sounded
like Lars was going to use these functions, so I think we should stick
with that plan.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Michael Lachmann wrote:
> > "Travis Cobbs" wrote:
> > > The desire was to preserve standard Windows INI file formatting,
> > > and each data line in an INI file has the form <key> = <value>
> > > (spaces optional). The numbers were suggested as keys, with
> > > positive responses from the people that responded.
> > >
> > > As a pratical manner, it's actually easier for a Windows program to
> > > load the settings this way, since it can repeatedly ask for the next
> > > numeric key in the [LDrawSearch] section until it gets a failed read.
> >
> > Easier ? Hmmm - when you read from a file its more easy to do it by
> > hand and read it line by line.
> > If you read from the registry there is a enum function which returns
> > every value in a key ...
> >
> > I'm still somehow a favorit of no numbers and equals at the beginning
> > of the line .....
>
> Ah, but we've already covered this ground. In addition to the registry
> functions, there are also Windows functions for reading and writing
> to INI files in the format with the = sign. Search in this thread
> for getprivateprofilestring and/or writeprivateprofilestring. It sounded
> like Lars was going to use these functions, so I think we should stick
> with that plan.
>
> Don
Yes, I'd prefer numbers and equals signs. All the functions I use to read INI
files require this format (or something similar. e.g. <string> <separator>
<string>)
-Orion
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> "Kim Toll" <kim.toll@intel.com> schrieb:
> > Allowing white space is always a good idea.
> >
> > I like having the backslash because I agree with Lars, I thought
> > the <LDRAWDIR>\Parts was a directory and the stuff in the brackets
> > was the base directory substitution.
> >
> > Having said that, what about suggesting an additional flag. One
> > that indicates what kind of directory this is. For example:
> >
> > [LDrawSearch]
> > 1 = <SHOW> <MODELDIR> <Models>
> > 2 = <HIDE> <LDRAWDIR>\P <Primitaves>
> > 3 = <SHOW> <LDRAWDIR>\Parts <Parts>
> > 4 = <SHOW> <LDRAWDIR>\Models <Models>
> > 5 = <SHOW> <LDRAWDIR>\Unofficial <Unofficial Parts>
> > 6 = <SHOW> <LDRAWDIR>\KimsParts <Unofficial Parts>
> > 7 = <SHOW> C:\temp\downloaded_models <Models>
> > 8 = <SHOW> C:\temp\MOTM <Models>
> >
> > The final flag, if present, could be a user defined category that
> > would let them clump the contents of similar groups together. For
> > instance, all things with the <Unoficial Parts> tag could be shown
> > together in a MLCad style tree view. Or if the user preferred,
> > they could just mark them all as <Parts> and all the unofficial
> > parts would show up under the <Parts> node along with the official
> > parts. And you could have several different directories that
> > contain models and they could all show up under the <Model> node.
>
> This is a good idea, theoretically we can add anything at the end of
> this line. Programms not willing to support can simply ignore it.
> However in this case I would like to use quotationmarks - hello lars
> ;.-) - to make clear where a directory start and where it ends. I've
> seen windows and unix directories with names including < and > so
Ok, you're starting to catch on to the versatility of extra tags,
but don't stop at just one more tag at the end of the line. Allow as
many as the user wants. I think <Unofficial> and <Parts> should
be separate tags. Just like I know you want to separate <Clones> from
<Parts>. <Parts> can be used to generate a bill of materials (LPUB?).
The <Unofficial>, <BFC>, <Boxes>, <Clones>, or whatever add different
additional information and thus should be a separate tag.
Also, I sorta like the convention of throwing all the optional
tags up front with the one required bit of information (the directory)
last. Examples:
5 = <SHOW> <Parts> <Unofficial> <LDRAWDIR>\Unofficial
6 = <HIDE> <Parts> <Unofficial> <LDRAWDIR>\KimsParts
7 = <SHOW> <SKIP> <Parts> <Clones> <HOMEDIR>\MegaBloks
I also think quotes should be allowed, but optional. We all know
they're going to end up in some INI file somewhere.
If we're going to use the <LDRAWDIR>\folder syntax with the
slash, should we restrict it to the DOS style since we already
must deal with that inside the official parts files with the
parts\s and p\48 subdirectories. Just a thought...
And I'm curious about the <> characters in filenames. I tried to make
some under Win2K and on a linux EXT2 filesystem and failed. Ok, that's
not a really extensive filesystem test, but do you remember where you
saw them?
Don
PS. Tore, I know you asked for the summary and I don't think the
<Boxes> tag was mentioned yet in the summary subthread. You may want
to search for it in the main thread and see if my random thoughts on
it fit in with your plans for your boxer project.
|
|
| |
> This is a good idea, theoretically we can add anything at the end of this
> line. Programms not willing to support can simply ignore it.
> However in this case I would like to use quotationmarks - hello lars ;.-) -
> to make clear where a directory start and where it ends. I've seen windows
> and unix directories with names including < and > so ....
They could be encoded. This is how Mac OS X pref files are encoded:
<sometag>/Path/><&</sometag>
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
>
> And I'm curious about the <> characters in filenames. I tried to make
> some under Win2K and on a linux EXT2 filesystem and failed. Ok, that's
> not a really extensive filesystem test, but do you remember where you
> saw them?
Most *nix file systems allow those characters in filenames - just enclose them
in quotes. Dunno about Windows. I just tried it on NT and it didn't like it, but
I didn't try very hard.
ROSCO
|
|
| |
Don Heyse wrote:
>
> And I'm curious about the <> characters in filenames. I tried to make
> some under Win2K and on a linux EXT2 filesystem and failed. Ok,
> that's not a really extensive filesystem test
[testing...]
WinXP with NTFS does not let you use < or > in filenames when renaming a
file.
You could probably generate such a name in plain old DOS - not from the
command line interface, but by calling the file operations from a program.
At least that's how one made cryptic file names with embedded control
characters in "the good ol' days" (love to have a file name with the 'clear
screen' escape sequence :-)
--
Anders Isaksson, Sweden
BlockCAD: http://w1.161.telia.com/~u16122508/proglego.htm
Gallery: http://w1.161.telia.com/~u16122508/gallery/index.htm
|
|
| |
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:HuLIG9.210E@lugnet.com...
<SNIP>
> I also think quotes should be allowed, but optional. We all know
> they're going to end up in some INI file somewhere.
Yes, I prefere that too.
>
> If we're going to use the <LDRAWDIR>\folder syntax with the
> slash, should we restrict it to the DOS style since we already
> must deal with that inside the official parts files with the
> parts\s and p\48 subdirectories. Just a thought...
No I don't think so, there will be no old programm reading this file, or the
section in it. I think there are no real dos applications created now, or?
Even if you create command line applications now, they will be able to work
with long file names.
>
> And I'm curious about the <> characters in filenames. I tried to make
> some under Win2K and on a linux EXT2 filesystem and failed. Ok, that's
> not a really extensive filesystem test, but do you remember where you
> saw them?
I must say I didn't try that after windows nt 3.51 which did allow that,
when you created a file at least. I will have a test on that.
Michael
|
|
| |
<SNIP
> > Ah, but we've already covered this ground. In addition to the registry
> > functions, there are also Windows functions for reading and writing
> > to INI files in the format with the = sign. Search in this thread
> > for getprivateprofilestring and/or writeprivateprofilestring. It • sounded
> > like Lars was going to use these functions, so I think we should stick
> > with that plan.
> >
> > Don
>
> Yes, I'd prefer numbers and equals signs. All the functions I use to read • INI
> files require this format (or something similar. e.g. <string> <separator>
> <string>)
>
> -Orion
Ok, Ok ... I agree! No problem with that, I just thought I could convice you
for the different side of the river ;->
The solution is not beautyfull, but I can live with it.
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> "Don Heyse" schrieb:
> > If we're going to use the <LDRAWDIR>\folder syntax with the
> > slash, should we restrict it to the DOS style since we already
> > must deal with that inside the official parts files with the
> > parts\s and p\48 subdirectories. Just a thought...
>
> No I don't think so, there will be no old programm reading this file, or the
> section in it. I think there are no real dos applications created now, or?
> Even if you create command line applications now, they will be able to work
> with long file names.
Actually I wasn't thinking about long filenames, just the slashes.
I can never remember which one is called backslash so I probably
wasn't all that clear. Maybe we should just *recommend* using the
DOS style slashes as the directory separator, especially for any
directories that start with <LDRAWDIR> because we know from the
part files that all programs (new or old) must be able to handle
the DOS \ path separator character.
> > And I'm curious about the <> characters in filenames. I tried to make
> > some under Win2K and on a linux EXT2 filesystem and failed. Ok, that's
> > not a really extensive filesystem test, but do you remember where you
> > saw them?
>
> I must say I didn't try that after windows nt 3.51 which did allow that,
> when you created a file at least. I will have a test on that.
I wouldn't bother. I bet there are plenty of filesystems where you
can create really weird filenames as long as you use a program instead
of the command line to do it. Once someone mentioned doing it that
way with DOS I remembered running into both UNIX and DOS filenames that
I had to build special programs to work with.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Michael Lachmann wrote:
> > "Don Heyse" schrieb:
> > > If we're going to use the <LDRAWDIR>\folder syntax with the
> > > slash, should we restrict it to the DOS style since we already
> > > must deal with that inside the official parts files with the
> > > parts\s and p\48 subdirectories. Just a thought...
> >
> > No I don't think so, there will be no old programm reading this file, or the
> > section in it. I think there are no real dos applications created now, or?
> > Even if you create command line applications now, they will be able to work
> > with long file names.
>
> Actually I wasn't thinking about long filenames, just the slashes.
Well, I still compile a 16-bit DOS version of L3P for a few users (2%),
but I think the coming version 1.4 will be the last. The possibilities
when having the full tree in memory are too tempting.
We can recommend the few hardcore DOS users to use 8+3 naming.
> I can never remember which one is called backslash so I probably
> wasn't all that clear. Maybe we should just *recommend* using the
> DOS style slashes as the directory separator, especially for any
> directories that start with <LDRAWDIR> because we know from the
> part files that all programs (new or old) must be able to handle
> the DOS \ path separator character.
My API will provide you with the kind of slashes used on the platform
you are running no matters what's in the ini file.
> > > And I'm curious about the <> characters in filenames. I tried to make
> > > some under Win2K and on a linux EXT2 filesystem and failed. Ok, that's
> > > not a really extensive filesystem test, but do you remember where you
> > > saw them?
> >
> > I must say I didn't try that after windows nt 3.51 which did allow that,
> > when you created a file at least. I will have a test on that.
>
> I wouldn't bother. I bet there are plenty of filesystems where you
> can create really weird filenames as long as you use a program instead
> of the command line to do it. Once someone mentioned doing it that
> way with DOS I remembered running into both UNIX and DOS filenames that
> I had to build special programs to work with.
On Linux try this
touch ' "<|>'
the only illegal characters are '/' and '\0'.
So even double-quotes won't work. I think the *only* correct solution is what James Reynolds
told us Apple uses: <sometag>/Path/><&</sometag>
But we can of course choose to say that we don't support directories with double-quotes...
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> On Linux try this
> touch ' "<|>'
> the only illegal characters are '/' and '\0'.
>
> So even double-quotes won't work. I think the *only* correct solution is
> what James Reynolds told us Apple uses:
> <sometag>/Path/><&</sometag>
>
> But we can of course choose to say that we don't support directories
> with double-quotes...
Hey, this reminded me of something. Is there some flavor of Windows that
uses nasty 16 bit unicode filenames? That could get quite messy. I think
the unix world is moving toward UTF-8 which sounds a bit more sane, and
should work with either of the two strategies you mention above.
Don
|
|
| |
Here are my ideas of an API for accessing the LDrawIni settings.
The basic idea is that it should be very simple to use, there are only four functions
and a data structure declaration.
First you call LDrawIniGet to read and initialize all relevant ldraw.ini data,
the LDrawDir, the search directories, the LGEO directory.
The data is initialized from environment variables and/or ini files
suitable for the platform you are running and in the agreed order.
L3P, as an example, will now look for the model in each of the search dirs.
When found L3P calls LDrawIniComputeRealDirs with the directory of the model.
This will recalculate the search dirs in the data structure to include those with <MODELDIR>.
L3P will now (probably) have an extra search dir to look in for the remaining loading of parts.
(directories marked with <SKIP> will of course be excluded from the search dirs)
For each search dir there may be a number of flags. The known ones are parsed into bit-flags
to speed up testing (e.g. LDSDF_HIDE|LDSDF_DEFPRIM), the remaining are available
as a string, e.g "<MyFlag><UnknownFlag>".
(or would you like a NULL terminated array of strings?)
When finding a file in one of the search dirs and the file has no official header
L3P can quickly determine whether the default filetype is e.g. Primitive.
When done L3P calls LDrawIniFree to release the data structure.
L3Lab works the same way, only it calls LDrawIniComputeRealDirs
whenever a new model is loaded.
The last function is LDrawIniResetSearchDirs, only to be called from the
LDrawSetup program - or if you wish to override the search to be the
standard one.
In C (not C++ for greatest compatibility) it may look like this, LDrawIni.h:
struct LDrawSearchDirS
{
int Flags; /* Parsed and known flags LDSDF_XXX */
char *UnknownFlags; /* Any unknown flags <XXX> */
char *Dir; /* The full path of a search dir */
};
struct LDrawIniS
{
/* The LDRAWDIR containing the P, PARTS and MODELS directories */
char *LDrawDir;
/* The LDrawSearch directories ready to use */
int nSearchDirs;
struct LDrawSearchDirS *SearchDirs;
/* The LGEODIR (named LGEO) containing the LGEO .inc files */
char *LgeoDir;
/* Private date for the LDrawIni routines */
struct LDrawIniPrivateDataS *PrivateData;
};
/* LDrawSearchDir Flags */
#define LDSDF_HIDE 0x0001 /* Hide directory */
#define LDSDF_DEFPART 0x0002 /* Default filetype: Part */
#define LDSDF_DEFPRIM 0x0004 /* Default filetype: Primitive */
#ifdef __cplusplus
extern "C" {
#endif
/*
Initialize and read all settings.
If the argument LDrawDir is not NULL
it will override the normal initialization of the LDraw directory.
If ErrorCode is not NULL it will return a code telling why
LDrawIniGet returned NULL.
If all is OK then a pointer to struct LDrawIniS is returned.
You should then call LDrawIniComputeRealDirs to obtain the search dirs.
Remember to free the struct by calling LDrawIniFree.
*/
struct LDrawIniS *LDrawIniGet(const char *LDrawDir, int *ErrorCode);
/*
Compute Real Dirs by substituting <LDRAWDIR> and <MODELDIR> in
the Symbolic Dirs read from the env vars or ini files.
If OnlyValidDirs is true then non-existing search dirs is skipped
If AddTrailingSlash is true then the search dirs will have a slash/backslash appended.
If ModelDir is NULL then search dir <MODELDIR> is skipped.
Returns 1 if OK, 0 on error
*/
int LDrawIniComputeRealDirs(struct LDrawIniS * LDrawIni,
int OnlyValidDirs,
int AddTrailingSlash,
const char *ModelDir);
/*
Reset search dirs to default if LDrawSearch is NULL
or to the dirs specified in LDrawSearch delimited by |.
Returns 1 if OK, 0 on error
*/
int LDrawIniResetSearchDirs(struct LDrawIniS * LDrawIni,
const char *LDrawSearch);
/*
Free the LDrawIni data
*/
void LDrawIniFree(struct LDrawIniS * LDrawIni);
#ifdef __cplusplus
}
#endif
/* Error codes returned by LDrawIniGet */
#define LDRAWINI_ERROR_OUT_OF_MEMORY 1
#define LDRAWINI_ERROR_LDRAWDIR_NOT_SET 2
(end of LDrawIni.h)
The LDrawSetup program would like to have access to the private data
and to some internal (static) functions for reading ini files and parsing,
so I am thinking of an additional include file, LDrawIniP.h:
struct LDrawIniPrivateDataS
{
/* The LDrawSearch directories as read */
int nSymbolicSearchDirs;
char **SymbolicSearchDirs;
};
some reading/parsing functions
(end of LDrawIniP.h)
I have currently tested the functions in L3P on Windows and will shortly test on Linux.
I had to rearrange some code in L3P now that you can't be sure
that the <MODELDIR> is the first search dir...
The L3P usage of the LDrawIni API is:
LDrawIni = LDrawIniGet(NULL, &LDrawIniErrorCode);
if (!LDrawIni)
{
if (LDrawIniErrorCode == LDRAWINI_ERROR_LDRAWDIR_NOT_SET)
{
/* Neither environment variable, nor ldraw.ini, simply try current dir */
if (IsDir("P") && IsDir("PARTS") && IsDir("MODELS"))
LDrawIni = LDrawIniGet(".", &LDrawIniErrorCode);
}
}
if (!LDrawIni)
{
Exit("\
Environment variable LDRAWDIR must be set to directory with P,PARTS,MODELS.\n\
e.g. 'set LDRAWDIR=c:\\Lego\\LDraw' (don't use long names)\n\
You may type the set command at the DOS prompt or put it into C:\\AUTOEXEC.BAT", NULL);
}
if (L3Pov.UseLgeoParts && !LDrawIni->LgeoDir)
{
Exit("\
Environment variable LGEODIR must be set to directory with LGEO parts.\n\
e.g. 'set LGEODIR=c:\\Lego\\LGEO' (don't use long names)\n\
You may type the set command at the DOS prompt or put it into C:\\AUTOEXEC.BAT", NULL);
}
i = LDrawIniComputeRealDirs(LDrawIni, 1, 1, NULL);
if (!i)
Exit("Failed to compute search dirs", NULL);
fp = OpenDatFile(ModelFilename, 1);
if (!fp)
Exit("Cannot find model file '%s'", ModelFilename);
fclose(fp);
Preparing load of model:
strcpy(ModelDir, lpszPathName);
for (i = strlen(ModelDir); --i >= 0;)
if (ModelDir[i] == '/' || ModelDir[i] == '\\')
break;
ModelDir[i<0? 0 : i] = '\0'; /* ModelDir may be empty. */
if (!LDrawIniComputeRealDirs(LDrawIni, 1, 1, ModelDir))
return -1;
And when loading DAT files:
static int FileIsFromP;
static int FileIsFromPARTS;
static FILE *OpenDatFile2(char *DatName, char *Extension)
{
FILE *fp;
register int i;
for (i = 0; i < LDrawIni->nSearchDirs; i++)
{
strcpy(DatPath, LDrawIni->SearchDirs[i].Dir); /* Has trailing \ */
strcat(DatPath, DatName);
strcat(DatPath, Extension);
FileIsFromP = (LDrawIni->SearchDirs[i].Flags & LDSDF_DEFPRIM) ? 1 : 0;
FileIsFromPARTS = (LDrawIni->SearchDirs[i].Flags & LDSDF_DEFPART) ? 1 : 0;
fp = fopeni(DatPath, "rb");
if (fp)
return fp;
}
return NULL;
}
FILE *OpenDatFile(char *DatName, int IsModel)
{
static char *Extensions[] = { "", ".ldr", ".dat", ".mpd" };
int i;
FILE *fp;
if (IsModel)
{
/* Be sure to load model; can't be sure <MODELDIR> is in search dirs */
strcpy(DatPath, ModelDir); /* ModelDir may be "" */
if (DatPath[0])
strcat(DatPath, BACKSLASH_STRING);
strcat(DatPath, DatName);
FileIsFromP = 0;
FileIsFromPARTS = 0;
fp = fopeni(DatPath, "rb");
if (fp)
return fp;
}
for (i = 0; i < sizeof(Extensions)/sizeof(char *); i++)
{
fp = OpenDatFile2(DatName, Extensions[i]);
if (fp)
return fp;
}
return NULL;
}
I hope the above gives you an idea of how to use the LDrawIni API in your program.
Let me know if you have other wishes I haven't thought of.
After a little more testing I'll soon publish LDrawIni.c.
I'll make an HTML page describing the functionlity,
the env var and ini file order, the format and the API.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> Here are my ideas of an API for accessing the LDrawIni settings.
<Snip ideas>
Here are a few random thoughts on those ideas...
I haven't thought about it enough to decide if I have a preference
on the format of the UnknownFlags. Either way seems ok to me.
If directories marked with <SKIP> are excluded from the search dirs,
how would I temporarily enable a <SKIP> directory? It looks like I might
be able to go into the PrivateData struct to find it. Then perhaps build
up a | delimited string from the SymbolicSearchDirs, except with the <SKIP>
tag removed from the newly enabled directory. Finally pass this string to
LDrawIniResetSearchDirs() and rerun LDrawIniComputeRealDirs() on the
modified LdrawIniS struct. So maybe the PrivateData really shouldn't
be all that private.
I mentioned this before but apparently nobody noticed. :^) How about
having LDrawIniComputeRealDirs() also substitute the value of
%USERPROFILE% or $HOME for a <HOMEDIR> tag? That way I can have a
platform independent way of pointing to part directories in my home
directory from a centralized ldraw.ini file on the network. Or a
single ldraw.ini file on a dual boot PC.
Perhaps the PrivateData should tell where the info came from: what ini
file, environment vars, or LdrawIniResetSearchDirs(). (I'm not actually
sure I need to know unless I'm planning on saving ini modifications.)
Are you planning on making a similar API for creating or modifying and
saving the ini file? I'll probably try to use the LdrawSetup program
as an LDDP style plugin, but others may want to incorporate it directly
into their programs.
I see you've included the LGEODIR. Have you given any thought to
making this extensible beyond that? We might someday like to be able
to locate some other ldraw part conversion library via the ldraw.ini
file. For example the LDRAWPOV library. Could LDrawIniGet() be
extended to handle this, or would a more generic function be better.
char *LDrawIniGetVar(const char *LdrawDir, char *VarName, int *ErrorCode);
LgeoDir = LdrawIniGetVar(NULL, "LgeoDirectory", &err);
ldrawpovDir = LdrawIniGetVar(NULL, "LdrawpovDir", &err);
Enjoy,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > Here are my ideas of an API for accessing the LDrawIni settings.
>
> <Snip ideas>
>
> Here are a few random thoughts on those ideas...
>
> I haven't thought about it enough to decide if I have a preference
> on the format of the UnknownFlags. Either way seems ok to me.
>
> If directories marked with <SKIP> are excluded from the search dirs,
> how would I temporarily enable a <SKIP> directory?
By modifying ldraw.ini or setting an env var.
Why would you want to enable a <SKIP> dir from within a program?
> I mentioned this before but apparently nobody noticed. :^) How about
> having LDrawIniComputeRealDirs() also substitute the value of
> %USERPROFILE% or $HOME for a <HOMEDIR> tag? That way I can have a
> platform independent way of pointing to part directories in my home
> directory from a centralized ldraw.ini file on the network. Or a
> single ldraw.ini file on a dual boot PC.
I did notice, but forgot it, sorry.
%USERPROFILE% or $HOME for <HOMEDIR>, OK fine with me.
> Perhaps the PrivateData should tell where the info came from: what ini
> file, environment vars, or LdrawIniResetSearchDirs(). (I'm not actually
> sure I need to know unless I'm planning on saving ini modifications.)
Yes, I actually thought of adding
char *LDrawDirSource;
char *SearchDirsSource;
char *LgeoDirSource;
strings you could use for e.g. debugging.
L3P could print them in the POV header.
Any interest?
> Are you planning on making a similar API for creating or modifying and
> saving the ini file? I'll probably try to use the LdrawSetup program
> as an LDDP style plugin, but others may want to incorporate it directly
> into their programs.
You can copy'n'paste the dialog resources and the corresponding
.h and .cpp files from the LDrawSetup project (VC6) into your program,
or you can simply launch LDrawSetup.
> I see you've included the LGEODIR. Have you given any thought to
> making this extensible beyond that? We might someday like to be able
> to locate some other ldraw part conversion library via the ldraw.ini
> file. For example the LDRAWPOV library. Could LDrawIniGet() be
> extended to handle this, or would a more generic function be better.
>
> char *LDrawIniGetVar(const char *LdrawDir, char *VarName, int *ErrorCode);
>
> LgeoDir = LdrawIniGetVar(NULL, "LgeoDirectory", &err);
> ldrawpovDir = LdrawIniGetVar(NULL, "LdrawpovDir", &err);
I had my doubts about whether to include LgeoDir or not.
I know that probably only L3P uses it, but the structure could/should contain
all data found in ldraw.ini?
In that case you would simply publish an update of the LDrawIni source code
supporting the LdrawpovDir.
However, LDrawIniGetVar is a good idea for not very common variables.
More arguments could be: const char *EnvVar, char **Source
I'm open to both.
/Lars
|
|
| |
"Anders Isaksson" <isaksson.etuna@REMOVEtelia.com> schrieb im Newsbeitrag
news:HuoL3w.LHF@lugnet.com...
> Don Heyse wrote:
> >
> > Hey, this reminded me of something. Is there some flavor of Windows
> > that uses nasty 16 bit unicode filenames?
>
> The NTFS (NT, XP, W2000) file system uses unicode. I don't know if that
> matters as long as you are using a western alphabet, but on a Chinese • system
> for example, your file names can of course be in Chinese.
>
> --
> Anders Isaksson, Sweden
> BlockCAD: http://w1.161.telia.com/~u16122508/proglego.htm
> Gallery: http://w1.161.telia.com/~u16122508/gallery/index.htm
>
>
Which would mean, we will have to support ini files in uni-code, which isn't
a problem either, but allows funny characters written into the file - could
be fun testing that thing later on in different countries all over the world
:-)
Michael
|
|
| |
"Lars C. Hassing" <sp.lars@am.hassings.dk> schrieb im Newsbeitrag
news:Hun57C.1xM8@lugnet.com...
> Here are my ideas of an API for accessing the LDrawIni settings.
>
> The basic idea is that it should be very simple to use, there are only • four functions
> and a data structure declaration.
>
> First you call LDrawIniGet to read and initialize all relevant ldraw.ini • data,
> the LDrawDir, the search directories, the LGEO directory.
> The data is initialized from environment variables and/or ini files
> suitable for the platform you are running and in the agreed order.
>
> L3P, as an example, will now look for the model in each of the search • dirs.
> When found L3P calls LDrawIniComputeRealDirs with the directory of the • model.
> This will recalculate the search dirs in the data structure to include • those with <MODELDIR>.
> L3P will now (probably) have an extra search dir to look in for the • remaining loading of parts.
> (directories marked with <SKIP> will of course be excluded from the search
dirs)
Don mentioned that already, it would be good to enable <SKIP> from the
programm. Imagine an
alternate set of files with <SKIP> flag before official ones. When the user
can enable/disable the SKIP
detection, the user can see the different view without to modify any ini
file - on some systems users
might not be able to modify these files (e.g. when running with a guest
account).
>
> For each search dir there may be a number of flags. The known ones are • parsed into bit-flags
> to speed up testing (e.g. LDSDF_HIDE|LDSDF_DEFPRIM), the remaining are • available
> as a string, e.g "<MyFlag><UnknownFlag>".
> (or would you like a NULL terminated array of strings?)
I would prefere the current variant, as this allows quick searching for
flags using just one standard function call.
>
> When finding a file in one of the search dirs and the file has no official • header
> L3P can quickly determine whether the default filetype is e.g. Primitive.
>
> When done L3P calls LDrawIniFree to release the data structure.
>
> L3Lab works the same way, only it calls LDrawIniComputeRealDirs
> whenever a new model is loaded.
>
> The last function is LDrawIniResetSearchDirs, only to be called from the
> LDrawSetup program - or if you wish to override the search to be the
> standard one.
Do we have to call LDrawIniResetSearchDirs before each call to
LDrawIniComputeRealDirs?
<SNIP>
>
> static int FileIsFromP;
> static int FileIsFromPARTS;
> static FILE *OpenDatFile2(char *DatName, char *Extension)
> {
> FILE *fp;
> register int i;
>
> for (i = 0; i < LDrawIni->nSearchDirs; i++)
> {
> strcpy(DatPath, LDrawIni->SearchDirs[i].Dir); /* Has trailing \ */
> strcat(DatPath, DatName);
> strcat(DatPath, Extension);
> FileIsFromP = (LDrawIni->SearchDirs[i].Flags & LDSDF_DEFPRIM) ? 1 : • 0;
> FileIsFromPARTS = (LDrawIni->SearchDirs[i].Flags & LDSDF_DEFPART) ? • 1 : 0;
> fp = fopeni(DatPath, "rb");
> if (fp)
> return fp;
> }
> return NULL;
> }
> FILE *OpenDatFile(char *DatName, int IsModel)
> {
> static char *Extensions[] = { "", ".ldr", ".dat", ".mpd" };
> int i;
> FILE *fp;
>
> if (IsModel)
> {
> /* Be sure to load model; can't be sure <MODELDIR> is in search dirs • */
> strcpy(DatPath, ModelDir); /* ModelDir may be "" */
> if (DatPath[0])
> strcat(DatPath, BACKSLASH_STRING);
> strcat(DatPath, DatName);
> FileIsFromP = 0;
> FileIsFromPARTS = 0;
> fp = fopeni(DatPath, "rb");
> if (fp)
> return fp;
> }
> for (i = 0; i < sizeof(Extensions)/sizeof(char *); i++)
> {
> fp = OpenDatFile2(DatName, Extensions[i]);
> if (fp)
> return fp;
> }
> return NULL;
> }
Don't you ever need FileIsFrom* flags when processing the files themself? If
you use global variables you cannot tell, which flag belongs to which file?!
These library is ideal for me at least, and I like this suggestion. Well
done Lars!
Is there any interest out there on a c++ class? If yes, I'll write a well
documented one otherwice I do the quick and dirty way without comments and
documentation :-)
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> Don mentioned that already, it would be good to enable <SKIP> from the
> programm. Imagine an alternate set of files with <SKIP> flag before
> official ones. When the user can enable/disable the SKIP detection,
> the user can see the different view without to modify any ini file
> - on some systems users might not be able to modify these files
> (e.g. when running with a guest account).
OK, <SKIP> will be parsed into a bit-flag LDSDF_SKIP and LDrawIniComputeRealDirs
will have an extra parameter to include/exclude <SKIP> dirs:
KeepSkippedDirs, IncludeSkipDirs, DontSkipDirs, ExcludeSkipDirs, SkipSkipDirs
- please come up with a good name...
> > The last function is LDrawIniResetSearchDirs, only to be called from the
> > LDrawSetup program - or if you wish to override the search to be the
> > standard one.
>
>
> Do we have to call LDrawIniResetSearchDirs before each call to
> LDrawIniComputeRealDirs?
No. It is needed in LDrawSetup for a "Reset to default" button.
However, you may use it too if you wish to discard the search dirs
loaded by LDrawIniGet from the ini file and use the default search dirs in stead.
> Don't you ever need FileIsFrom* flags when processing the files themself? If
> you use global variables you cannot tell, which flag belongs to which file?!
Well, I call OpenDatFile and right after I use the FileIsFrom* flags.
However, L3P also calls OpenDatFile in other contexts (e.g. l3p -check)
where the default part type is irrelevant.
But I know it's bad design, I'll pass it as parameters in stead.
> These library is ideal for me at least, and I like this suggestion. Well
> done Lars!
Thanks, I'm glad you like it.
> Is there any interest out there on a c++ class? If yes, I'll write a well
> documented one otherwice I do the quick and dirty way without comments and
> documentation :-)
:-) As mentioned earlier I need to stick to C code, but you are welcome.
/Lars
|
|
| |
"Lars C. Hassing" <sp.lars@am.hassings.dk> schrieb im Newsbeitrag
news:HusLAn.8Cz@lugnet.com...
> In lugnet.cad.dev, Michael Lachmann wrote: • <SNIP>
> OK, <SKIP> will be parsed into a bit-flag LDSDF_SKIP and • LDrawIniComputeRealDirs
> will have an extra parameter to include/exclude <SKIP> dirs:
> KeepSkippedDirs, IncludeSkipDirs, DontSkipDirs, ExcludeSkipDirs, • SkipSkipDirs
> - please come up with a good name...
I don't realy care but IncludeSkipDirs sounds reasonable.
>
> > > The last function is LDrawIniResetSearchDirs, only to be called from • the
> > > LDrawSetup program - or if you wish to override the search to be the
> > > standard one.
> >
> >
> > Do we have to call LDrawIniResetSearchDirs before each call to
> > LDrawIniComputeRealDirs?
>
> No. It is needed in LDrawSetup for a "Reset to default" button.
> However, you may use it too if you wish to discard the search dirs
> loaded by LDrawIniGet from the ini file and use the default search dirs in
stead.
That means LDrawIniComputeRealDirs will reset the paths to the original
loaded ones,
than take care of model path and eventually the IncludeSkipDirs flag, right?
> > Is there any interest out there on a c++ class? If yes, I'll write a • well
> > documented one otherwice I do the quick and dirty way without comments • and
> > documentation :-)
>
> :-) As mentioned earlier I need to stick to C code, but you are welcome.
> /Lars
Ok, so if you are ready I will add a wrapper class to you library ...
Michael
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> "Lars C. Hassing" <sp.lars@am.hassings.dk> schrieb:
> > OK, <SKIP> will be parsed into a bit-flag LDSDF_SKIP and
> > LDrawIniComputeRealDirs will have an extra parameter to
> > include/exclude <SKIP> dirs: KeepSkippedDirs, IncludeSkipDirs,
> > DontSkipDirs, ExcludeSkipDirs, SkipSkipDirs - please come up with a
> > good name...
>
> I don't realy care but IncludeSkipDirs sounds reasonable.
I like the LDSDF_SKIP bit-flag but I don't think we need to add a
parameter to to LDrawIniComputeRealDirs(). Here's why. The parameter
would make it all or nothing for skipped dirs. I'd rather toggle the
LDSDF_SKIP bit-flags of some of the directories myself before calling
LDrawIniComputeRealDirs(), because I envision the need for several
distinct groups of skip dirs. Imagine some skip dirs are sorted into
groups by the "unknown" flags:
<group unofficial>
<group bfc>
<group boxes>
<group clones>
Maybe I should be really specific and call them skipgroups. I don't
know yet. Anyhow, I can easily imagine a scenario where I want to
temporarily enable the unofficial parts, but not the rest.
The only problem with my new approach is I have to remember which
directories I toggled the bit-flag in so I can undo it later. Yeah, I
know the original information is still in the private data. Perhaps
instead of a global parameter, you could add another bit-flag for each
directory called LDSF_INCLUDE_SKIP that I could toggle before calling
LDrawIniComputeRealDirs(). Then I could write a quick function to
clear all the LDSF_INCLUDE_SKIP flags, before I set the ones I want
(if any) and call LDrawIniComputeRealDirs().
Don
|
|
| |
In lugnet.cad.dev, Michael Lachmann wrote:
> > > Do we have to call LDrawIniResetSearchDirs before each call to
> > > LDrawIniComputeRealDirs?
> >
> > No. It is needed in LDrawSetup for a "Reset to default" button.
> > However, you may use it too if you wish to discard the search dirs
> > loaded by LDrawIniGet from the ini file and use the default search dirs in
> stead.
>
> That means LDrawIniComputeRealDirs will reset the paths to the original loaded ones,
> than take care of model path and eventually the IncludeSkipDirs flag, right?
Right.
/Lars
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> I like the LDSDF_SKIP bit-flag but I don't think we need to add a
> parameter to to LDrawIniComputeRealDirs().
The idea was to make it simple for ordinary usage.
I guess most programs would call LDrawIniComputeRealDirs() with
IncludeSkipDirs=0 and simply search the dirs returned.
However, you can call LDrawIniComputeRealDirs with IncludeSkipDirs=1
and then postprocess the search dirs at your liking
building your own new array of search dirs.
I follow your idea but I think it goes beyond the simple scope.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > I like the LDSDF_SKIP bit-flag but I don't think we need to add a
> > parameter to to LDrawIniComputeRealDirs().
>
> The idea was to make it simple for ordinary usage.
> I guess most programs would call LDrawIniComputeRealDirs() with
> IncludeSkipDirs=0 and simply search the dirs returned.
>
> However, you can call LDrawIniComputeRealDirs with IncludeSkipDirs=1
> and then postprocess the search dirs at your liking
> building your own new array of search dirs.
> I follow your idea but I think it goes beyond the simple scope.
Hmmm, POSTprocess eh? Yes, I think that'll work just fine. Now why
didn't I think of it...
Thanks Lars,
Don
|
|
| |
On Tue, 02 Mar 2004 06:44:07 +0000, Travis Cobbs wrote:
> On a side note, all Windows API calls accept / as a path separator with the
> exact same meaning as \. They can even both be used in the same path (ie
> C:/ldraw\parts). This might even date back to the DOS days, although I'm not
> sure on that one. One catch is that / on the command line is treated entirely
> differently from \, making it impossible to use it on the command line (or at
> the least very difficult).
Directory separators were added in DOS 2, which accepted both / and \ for
that purpose. The feature was imitated from Unix. At the time, there also
appeared a config.sys setting for *switch* character, which would default
to / but could be set to something else, for instance - for a more
unix-like behaviour. DOS has a system call to determine the current switch
character, which still remains, but the setting itself is gone. Messing
things up further, there's no way to know beforehand how any program will
interpret the command line; it's just passed as a string and it's up to
each program whether to respect the switch character.
In short, if you're lucky, most things work between double quotes. In
system calls, / and \ are equivalent to DOS.
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Michael Lachmann wrote:
> > Don mentioned that already, it would be good to enable <SKIP> from the
> > programm. Imagine an alternate set of files with <SKIP> flag before
> > official ones. When the user can enable/disable the SKIP detection,
> > the user can see the different view without to modify any ini file
> > - on some systems users might not be able to modify these files
> > (e.g. when running with a guest account).
>
> OK, <SKIP> will be parsed into a bit-flag LDSDF_SKIP and LDrawIniComputeRealDirs
> will have an extra parameter to include/exclude <SKIP> dirs:
> KeepSkippedDirs, IncludeSkipDirs, DontSkipDirs, ExcludeSkipDirs, SkipSkipDirs
> - please come up with a good name...
>
> > > The last function is LDrawIniResetSearchDirs, only to be called from the
> > > LDrawSetup program - or if you wish to override the search to be the
> > > standard one.
> >
> >
> > Do we have to call LDrawIniResetSearchDirs before each call to
> > LDrawIniComputeRealDirs?
>
> No. It is needed in LDrawSetup for a "Reset to default" button.
> However, you may use it too if you wish to discard the search dirs
> loaded by LDrawIniGet from the ini file and use the default search dirs in stead.
>
>
> > Don't you ever need FileIsFrom* flags when processing the files themself? If
> > you use global variables you cannot tell, which flag belongs to which file?!
>
> Well, I call OpenDatFile and right after I use the FileIsFrom* flags.
> However, L3P also calls OpenDatFile in other contexts (e.g. l3p -check)
> where the default part type is irrelevant.
> But I know it's bad design, I'll pass it as parameters in stead.
>
> > These library is ideal for me at least, and I like this suggestion. Well
> > done Lars!
>
> Thanks, I'm glad you like it.
>
> > Is there any interest out there on a c++ class? If yes, I'll write a well
> > documented one otherwice I do the quick and dirty way without comments and
> > documentation :-)
>
> :-) As mentioned earlier I need to stick to C code, but you are welcome.
> /Lars
Dear LSC,
I examined the LDraw website and was unable to find formalization for the
support of optional part paths. I'm updating LPub and would like to include
support for this concept of alternate paths for LDraw parts. The PRE and POST
concepts make sense to me.
Parts authors would want PRE to point to directories where they have updated
or new parts.
Mere mortal users would want POST to point to the directories where the
unofficial parts are stored.
The above implementation seems Windows environment specific. Could we possibly
have a more platform independent method? It would seem that this is best
specified outside an LDraw file because not all people will have their parts
directories organized the same way.
One simple implementation would be to simply to specify the name of official
directories for pre and post. This way we would not need a separate method and
data files for specifying and accessing this information. The unofficial parts
bulk package would dump its files into post.
Could we get a formal specification for this>
Keep up the good work and thanks,
Kevin
|
|
| |
----- Original Message -----
From: "Kevin L. Clague" <kevin_clague@yahoo.com>
To: <lugnet.cad.dev@lugnet.com>
Sent: Monday, July 09, 2007 5:56 PM
Subject: Dear LSC, was: LDrawIni API (was: LDRAWPREDIRS LDRAWPOSTDIRS -
additional search paths)
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > In lugnet.cad.dev, Michael Lachmann wrote:
> > > Don mentioned that already, it would be good to enable <SKIP> from the
> > > programm. Imagine an alternate set of files with <SKIP> flag before
> > > official ones. When the user can enable/disable the SKIP detection,
> > > the user can see the different view without to modify any ini file
> > > - on some systems users might not be able to modify these files
> > > (e.g. when running with a guest account).
> >
> > OK, <SKIP> will be parsed into a bit-flag LDSDF_SKIP and
> > LDrawIniComputeRealDirs
> > will have an extra parameter to include/exclude <SKIP> dirs:
> > KeepSkippedDirs, IncludeSkipDirs, DontSkipDirs, ExcludeSkipDirs,
> > SkipSkipDirs
> > - please come up with a good name...
> >
> > > > The last function is LDrawIniResetSearchDirs, only to be called from
> > > > the
> > > > LDrawSetup program - or if you wish to override the search to be the
> > > > standard one.
> > >
> > >
> > > Do we have to call LDrawIniResetSearchDirs before each call to
> > > LDrawIniComputeRealDirs?
> >
> > No. It is needed in LDrawSetup for a "Reset to default" button.
> > However, you may use it too if you wish to discard the search dirs
> > loaded by LDrawIniGet from the ini file and use the default search dirs
> > in stead.
> >
> >
> > > Don't you ever need FileIsFrom* flags when processing the files
> > > themself? If
> > > you use global variables you cannot tell, which flag belongs to which
> > > file?!
> >
> > Well, I call OpenDatFile and right after I use the FileIsFrom* flags.
> > However, L3P also calls OpenDatFile in other contexts (e.g. l3p -check)
> > where the default part type is irrelevant.
> > But I know it's bad design, I'll pass it as parameters in stead.
> >
> > > These library is ideal for me at least, and I like this suggestion. Well
> > > done Lars!
> >
> > Thanks, I'm glad you like it.
> >
> > > Is there any interest out there on a c++ class? If yes, I'll write a
> > > well
> > > documented one otherwice I do the quick and dirty way without comments
> > > and
> > > documentation :-)
> >
> > :-) As mentioned earlier I need to stick to C code, but you are welcome.
> > /Lars
>
> Dear LSC,
>
> I examined the LDraw website and was unable to find formalization for the
> support of optional part paths. I'm updating LPub and would like to
> include
> support for this concept of alternate paths for LDraw parts. The PRE and
> POST
> concepts make sense to me.
>
> Parts authors would want PRE to point to directories where they have
> updated
> or new parts.
>
> Mere mortal users would want POST to point to the directories where the
> unofficial parts are stored.
>
> The above implementation seems Windows environment specific. Could we
> possibly
> have a more platform independent method? It would seem that this is best
> specified outside an LDraw file because not all people will have their
> parts
> directories organized the same way.
>
> One simple implementation would be to simply to specify the name of
> official
> directories for pre and post. This way we would not need a separate
> method and
> data files for specifying and accessing this information. The unofficial
> parts
> bulk package would dump its files into post.
>
> Could we get a formal specification for this>
>
> Keep up the good work and thanks,
> Kevin
How do these differ from an official "unofficial" sub-directory? - see
http://news.lugnet.com/cad/dev/mac/?n=768
The LSC has already voted against having a formal "unofficial"
sub-directory, prefering to leave it to software authors, so we may take
some convincing.
From a programming point of view, so long as you read PRE and POST from some
system (environment) variables you should be platform independant as both
Windows and Unix support them.
|
|
| |
To all developers,
The LSC does not want to specify how unofficial parts are handled. Personally
if find the recommendation that we pull down individual unofficial parts into
the same directory as our LDraw file a hassle.
Would the group prefer environment variables that provide paths for
directories, or known subdirectory names?
I think that for the novice user, known subdirectory names would be simplest.
For advanced users environment variables provide the most control.
I could see implementing both. "unofficial" for parts that are not officially
released for the simple user and environment variables for part authors and
advanced users. We could use LDRAWPREDIRS and LDRAWPOSTDIRS for the environment
variables.
So, this convention can only work for a given user if all the tools they use
follow the convention.
Unless someone comes up with an alternate plan, I will implement this in LPub.
I believe that I can compensate for L3P and the renderers by substituting parts
found in alternate paths with their full file system path name before handing
off the generated LDraw file to them.
PLMKWYT
Kevin
|
|
| |
To all developers,
The LSC does not want to specify how unofficial parts are handled. Personally
if find the recommendation that we pull down individual unofficial parts into
the same directory as our LDraw file a hassle.
Would the group prefer environment variables that provide paths for
directories, or known subdirectory names?
I think that for the novice user, known subdirectory names would be simplest.
For advanced users environment variables provide the most control.
I could see implementing both. "unofficial" subdirectory for parts that are
not officially released for the simple user and environment variables for part
authors and advanced users. We could use LDRAWPREDIRS and LDRAWPOSTDIRS for the
environment variables.
So, this convention can only work for a given user if all the tools they use
follow the convention.
Unless someone comes up with an alternate plan, I will implement this in LPub.
I believe that I can compensate for L3P and the renderers by substituting parts
found in alternate paths with their full file system path name before handing
off the generated LDraw file to them.
PLMKWYT
Kevin
|
|
| |
> Would the group prefer environment variables that provide paths for
> directories, or known subdirectory names?
Get the best of both worlds and do both. Check for the environment variable
and if it is blank
(or non-existant) default it to a "known" sub-directory.
W
|
|
| |
In lugnet.cad.dev, William Howard wrote:
> > Would the group prefer environment variables that provide paths for
> > directories, or known subdirectory names?
>
> Get the best of both worlds and do both. Check for the environment variable
> and if it is blank
> (or non-existant) default it to a "known" sub-directory.
That makes sense to me too.
Based on the coincidental informal convention already used by LDView and
Bricksmith, I suggest $LDRAWDIR/Unofficial as the default unofficial parts
directory. It is structured like the regular LDraw directory with parts,
parts/s, p, and p/48 subdirectories.
Using the full path to unofficial parts is a great tip for L3P! I like that
solution. Beats my previous approach of merging and unmerging the official and
unofficial hierarchies with a script.
Jim
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> To all developers,
>
> The LSC does not want to specify how unofficial parts are handled. Personally
> if find the recommendation that we pull down individual unofficial parts into
> the same directory as our LDraw file a hassle.
I agree (which is why I voted yes on the other proposal, although it's not an
exact match for what you're asking for). Having said that, Lars did offer the
INI parsing code, and since it's already in LDView (which is under GPL), anyone
who wants to can already access and use Lars's code. While it's true that INI
files are a Windows invention, they do make an easily human-readable format for
settings files, and they are easy to parse. Lars's code does all the parsing,
and it's written in C (not C++) that has been designed to be as portable as
possible. I updated his code to provide support for a filename search callback
function to handle platform-specific case-sensitive file systems. (And I have
an implementation of one such function in LDView's QT code.)
So if you want my opinion, I think we should all use Lars's code. If you're not
writing in C, then the code could probably be rolled into a library quite easily
(although it does use structures, which have varied ease-of-use in non C-based
programming languages).
> Would the group prefer environment variables that provide paths for
> directories, or known subdirectory names?
Lars's code supports using environment variables for everything, or the
ldraw.ini for everything (assuming it can find it), or a combination of the two.
I think what he has is sufficient for use on any OS.
Of course, the fact that I'm already using Lars's code in LDView may make me
biased. Additionally, I haven't yet updated LDView's "extra dirs" UI to use
Lars's code, so you might (somewhat legitimately) claim that I'm being
hypocritical.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > To all developers,
> >
> > The LSC does not want to specify how unofficial parts are handled. Personally
> > if find the recommendation that we pull down individual unofficial parts into
> > the same directory as our LDraw file a hassle.
>
> I agree (which is why I voted yes on the other proposal, although it's not an
> exact match for what you're asking for). Having said that, Lars did offer the
> INI parsing code, and since it's already in LDView (which is under GPL), anyone
> who wants to can already access and use Lars's code. While it's true that INI
> files are a Windows invention, they do make an easily human-readable format for
> settings files, and they are easy to parse. Lars's code does all the parsing,
> and it's written in C (not C++) that has been designed to be as portable as
> possible. I updated his code to provide support for a filename search callback
> function to handle platform-specific case-sensitive file systems. (And I have
> an implementation of one such function in LDView's QT code.)
I'm using Qt, and LPub is under GPL, so this sounds perfect.
I'm all for standardization, so this sounds great.
>
> So if you want my opinion, I think we should all use Lars's code. If you're not
> writing in C, then the code could probably be rolled into a library quite easily
> (although it does use structures, which have varied ease-of-use in non C-based
> programming languages).
>
>
> > Would the group prefer environment variables that provide paths for
> > directories, or known subdirectory names?
>
> Lars's code supports using environment variables for everything, or the
> ldraw.ini for everything (assuming it can find it), or a combination of the two.
> I think what he has is sufficient for use on any OS.
>
> Of course, the fact that I'm already using Lars's code in LDView may make me
> biased. Additionally, I haven't yet updated LDView's "extra dirs" UI to use
> Lars's code, so you might (somewhat legitimately) claim that I'm being
> hypocritical.
I'm not looking to judge or criticize anyone. All of our programming
efforts are works in progress, so these self analysis' are all very
understandable in my book.
>
> --Travis
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> I'm using Qt, and LPub is under GPL, so this sounds perfect.
>
> I'm all for standardization, so this sounds great.
The following files in LDView's source tree contain the LDrawIni stuff:
LDLoader/LDrawIni.c
LDLoader/LDrawIni.h
LDLoader/LDrawInP.h
There's a #include <TCFoundation/TCDefines.h> near the top of LDrawIni.c. You
can delete that; the only reason it's there is to define
_CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE to get rid of warnings in
Visual Studio 2005.
My file case callback function can be found in QT/ModelViewerWidget.cpp and is
named staticFileCaseCallback. It uses another function in the same file named
staticFileCaseLevel. Additionally, it uses replaceStringCharacter from
TCFoundation/mystring.{cpp,h}. You'll probably want to either copy that one
function or reimplement it. It just does a global search and replace in a
string looking for one character and replacing it with another (in this case,
replacing backslash with forward slash).
All of the above files can be downloaded from LDView's SourceForge CVS browse
here:
http://ldview.cvs.sourceforge.net/ldview/LDView/
Alternatively, you can do an anonymous cvs checkout of the LDView source tree
(instructions here: http://ldview.sourceforge.net/Downloads.html#SourceCode).
--Travis
|
|
|
