Subject:
|
Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 1 Mar 2007 21:08:12 GMT
|
Viewed:
|
4336 times
|
| |
|
|
In lugnet.cad.dev, Tore Eriksson wrote:
| |
In lugnet.cad.dev, Timothy Gould wrote:
| |
Personally I’m against maintaining it. It forces us into strange naming
conventions for something which probably affects no users of the software.
Tim
|
It it really so? We still use renderers and utilities that have command line
inputs, and I don’t know but I have a strong feeling that long names may
cause problems like “Unofficial” turs into “Unoffi~1” followed by path not
found errors. And the next step, using space chars in a path or file name is
no doubt equal to asking for trouble.
|
First of all, I agree that we should avoid using space in filenames for all
official stuff. It’s just too problematic. However, that’s not a reason to
forbid the use of long filenames in general.
The thing is, any program that doesn’t support long filenames is almost
certainly not being updated. So it’s not going to support something like the
Unofficial directory anyway. Command line Windows programs (like l3p) happily
support long filenames. The only programs that don’t are those that are
compiled with a DOS compiler.
| |
I suggest we all try to do programs that support all kinds of file names, but
when naming official folders and files, we stick to the problem free standard
to avoid unnecessary bug reports and support requests.
|
I’m ambivalent on this. Filenames for all files in the official library still
have to conform to the 8.3 DOS filename standard. That’s because they have to
render correctly in ldraw/ledit. Given that those programs are the original
reason for the existence of the library, I can understand this. I’m not
entirely sure it’s still a good reason, but I’m not going to argue against it.
However, this proposal for having “Unofficial” be the name of a directory inside
the LDraw directory that contains its own PARTS and P subdirectories is in a
fundamentally different category. It’s functionality that would only be
supported in programs that are actively being updated. All such programs
shouldn’t have a problem with long filenames. So, to me, I don’t think it
should be vetoed simply because it is a long filename.
Note that both Allen Smith (the author of Bricksmith) and I (the author of
LDView) independently decided to look for files in this directory. There was no
communication between us and we weren’t aware of what the other had done. To
me, that indicates that what we decided on is a fairly natural thing to do.
| |
(As I took my first steps into the world of PC in pre-Windows environemts, I
find the non-DOS naming conventions (or rather, lack of conventions) very
strange) ;)
|
And I find the DOS naming convention unnecessarily obtuse and limiting. It was
somewhat appropriate for its time (when 360KB was a lot of disk space), but
hasn’t been appropriate for about 20 years now. In other words, I think MS
should have introduced long filename support LONG before Win95 was introduced.
In fact, MS-DOS 2.0 (1983) would have been the most logical time to do this, at
the same time they added support for subdirectories.
--Travis
|
|
Message is in Reply To:
39 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
