Subject:
|
Re: Adding part updates
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Mon, 19 Jan 2004 18:24:59 GMT
|
Reply-To:
|
cjmasi@*{Spamless}nogarbageplease*rcn.com
|
Viewed:
|
2835 times
|
| |
|
|
Don Heyse wrote:
> In lugnet.cad.dev.mac, Christopher Masi wrote:
>
> > Let me know what you think of the updated install instructions
> >
> > http://users.rcn.com/cjmasi/osxinstall.html
> >
> > If they are ok, I (or you) can put them on the ldglite site. I guess I
> > could also put the new directions in the downloadble executable.
>
>
> I'd switch steps 6 and 7 and maybe add a sentence that explaining
> that some options are still only available on the command line for
> ldglite and mklist.
>
> I'm also thinking about adding a link to the MegaBlock ldraw library
> if I can find it. The recent color change did away with the whole
> Lego "System" concept by introducing subtle incompatibilities. It
> seems like Lego really wants us to mix it up with the clone bricks,
> so I'm willing to help them out there.
>
> Don
Hi Don,
Yeah, looking at it again, I have to say that I agree; six and seven
should be switched. I also need to mention that the user should download
all the updates. My best guess, since the date on the ldraw parts for
linux file is not specified, is that users need all the 2003 updates.
Wow, you are taking this color thing hard. I am not happy because
rebuilding my Super Chief in 8-wide may not be possible without screwing
up the colors. It just seems like a weird thing to change. I mean
really, how much could the color inside the box really encourage someone
to buy more LEGO? I only see negatives out of the change, annoying
fanatics and causing people to think think that the quality of LEGO is
slipping because the colors don't match anymore. I wouldn't use the
MegaBlocks parts, but providing a link seems reasonable. I mean, there
are people that like and use MegaBlocks, so why not.
Hrm, I have been poking around again, and a little thing has cropped
up that bugs me a bit. When a "dat" is double clicked, LDGLite opens it,
but other than that the path is used to open the file, the path of the
file is not passed to ldglite. If save is chosen from the popup menu or
via the file menu, there is no path information. A new user might simply
enter the name and press return. When you do that, the file is saved to
the root level of the hard drive. Is there any way to get that path info
transfered to the save functions? Or is there anyway to switch the
default to the user's home directory?
I checked, when a non-administrative user tries to save a file
without specifying a path, the uses isn't told that the file isn't saved
when the program tries to save it to the root level of the hard drive.
Chris
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: Adding part updates
|
| (...) I'd switch steps 6 and 7 and maybe add a sentence that explaining that some options are still only available on the command line for ldglite and mklist. I'm also thinking about adding a link to the MegaBlock ldraw library if I can find it. The (...) (21 years ago, 19-Jan-04, to lugnet.cad.dev.mac)
|
24 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
