Ldraw linux packages

[Don Heyse]

Does anyone here know anything about this LDraw Linux packages github repository? There's a wrapper script for setting the LDRAWDIR environment variable and I was wondering if it's actually in use, or is it just simply another different solution to the problem of locating the LDraw files on linux.

Thanks,

Don

[Milan Vančura]

Sure. This is a project I announced here some time ago. I do it with my friend Jiří and we are very close to our goal: a repository of packages for your Linux distro you can just add (openSUSE, Debian, Ubuntu and probably Fedora as well). However, we both are busy at our work now so this project is going very slowly now.

What I'm interested in is your reason of making the word "different" bold in your comment. Do you know about any other working solution on Linux? Me not.

[Don Heyse]

I used bold to get your attention. It worked! I wasn't sure if your project was live because I did a test github push to your ldglite repo back in February that drew no response. So I didn't want to write a lot here if nobody was listening. I don't know of any other working solution on linux, so I'm happy to hear your project is alive.

Anyhow, I'm currently trying to incorporate the LDrawIni code into ldglite to homogenize the part search strategy between it, LDView, and L3p. That code has some "typical" fallback paths for various platforms and I noticed the linux fallback paths are different from the paths used in your wrapper. The LDrawIni code uses /usr/local/share/LDRAW and ~/LDRAW. Your wrapper uses /usr/share/ldraw for the ldraw install and then softlinks ~/.ldraw to that. Personally I prefer the setup in your wrapper because UPPERCASE is a royal pain and should be avoided. And I really like the idea of using softlinks from the home directory to the ldraw installation in the system directory. I've decided that I have to modify the LDrawIni code to make it work for ldglite because of the uppercase thing, so while I'm in there I'll add your paths to the "typical" fallback list (mostly just for me so I can run things without a wrapper).

But I'd like to make some suggestions concerning the ~/.ldraw softlink. I think it'd work better if ~/.ldraw was a real directory and inside it you could make softlinks to the files and directories inside the /usr/share/ldraw directory. That way users could easily override some of the softlinks to point at their own personal files and directories instead. They could have their own personal color setup, personal directories for Unofficial and lsynth parts, etc. For example, I prefer the brighter candy colors in ldcfgalt.ldr so I softlink ~/.ldraw/ldconfig.ldr to that instead of the standard file.

Also, ldglite in LEDIT mode uses the models directory to as the default storage location for the model you're working on. And it uses the bitmaps directory as the default screendump location. So I've softlinked them to point them at ~/Documents and ~/Pictures on my LMDE linux laptop. I suspect nobody uses LEDIT mode but me, but somebody out there could possibly be using ldglite to dump images. LPub3D also creates temporary/working files in the models directory. I don't know about the older lpub4 code, but it might as well.

Here's what I've tried so far on my puppy linux netbook.

# ls -laptr ~/.ldraw/
total 138
drwxrwxrwx 1 root root 135168 2016-03-26 17:30 ../
drwxrwxrwx 1 root root 0 2016-03-26 17:30 bitmaps/
drwxrwxrwx 1 root root 0 2016-03-26 17:31 models/
drwxrwxrwx 1 root root 0 2016-03-26 17:35 unofficial/
-rwxrwxrwx 1 root root 294 2016-03-26 17:52 ldraw.ini
lrwxrwxrwx 1 root root 42 2016-03-26 17:54 p -> /usr/share/ldraw/p
lrwxrwxrwx 1 root root 50 2016-03-26 17:54 parts -> /usr/share/ldraw/parts
lrwxrwxrwx 1 root root 76 2016-03-26 19:30 ldconfig.ldr -> /usr/share/ldraw/ldcfgalt.ldr
drwxrwxrwx 1 root root 4096 2016-03-26 19:30 ./

Hmm, I suppose this could all be in a directory like ~/ldraw and ~/.ldraw could still be a softlink that points either there or at /usr/share/ldraw depending on the users preference for customization. I think that would work with the current wrapper script as is. What do you think?

Don

[Milan Vančura]

Hello again, Don.

As I'm back on Internet I want to make some things (more) clear: at first, I'm very glad you noticed our project, it's a new motivation for us! You did not need any word in bold - it's enough to place the comment/question to "Editors" category or mention "Linux" in the subject I monitor that every day I'm on Internet

About ~/.ldraw directory: we do exactly what you described you wanted to do! I mean a real directory full of symlinks. And exactl for the same purpose you mentioned: to allow each user to add or modify parts of that directory. So I see great agreement on this. And, of course, no capital letters anywhere. It's a mess we really dislike. Windows users do not notice that but on filesystems knowing the difference between lower and upper case letters, it was very often that some LDraw SW could not read/find parts files etc. because of the "wrong" case in its filename. So we decided to both store and find everything in lower case. (Patch LDraw utilities where needed and change all filenames in LDraw librry itself.)

Another topic is ldraw.ini - our project is older than the idea of ldraw.ini so there is no support for it, so far. More on that, AFAIK, the utility using this most is LPub3D which is not released for Linux, up to now. Unfortunately. But it may be I'm wrong - is there anything you believe we should do for ldraw.ini support? Or where to look at? To not introduce another, competing, standard.

Thanks,

Milan

[Don Heyse]

Hi Milan,

The forum software switchover is giving me trouble, so this is a bit late and may be somewhat garbled.  Sorry.

Anyhow, I'm not sure how the LDraw Linux project could possibly be older than the idea of ldraw.ini.  That file was already in use -- at least on Windows -- at the tail end of last century, initially by the LDRAW Add On program and then ldglite.  It actually feels more like a *millennium* ago to me.  At that time the only shared information in the ini file was the LDRAWDIR location.  The idea of configurable subdirectory search paths in the ldraw.ini file and in some related environment variables came later.   Something like 12 years ago.  This resulted in the ldrawini sourceforge project to make the same configuration settings available on Windows, OSX, and linux.  L3p and LDView both use the ldrawini code, and now LPub3D and ldglite do as well.   All but LPub3D are currently available on linux.  LPub4 makes use of it indirectly, through the image rendering programs.

Actually, I have to say ldglite almost supports ldrawini.  I remembered this morning that my netbook has a mixed filesystem.  The HOME directory is on a case sensitive partition, but I'd managed to install the ldraw directory onto the insensitive FAT partition, so my linux testing was flawed and incomplete.  I retested it and pushed the fixes to my ldglite github fork, but there's probably some more bugs to shake out before I declare it a real release.

Meanwhile, I don't think it's necessary to do anything in your project to support ldraw.ini since the LDRAWDIR environment variable covers the essentials, and reasonable defaults are created for the rest.  However, it might be helpful to create an ldraw.ini file with the default settings in it.  Something like this example ldraw.ini file, but without the lsynth line.  I don't think it'd cause any harm if it only contained the defaults.  The contents of the ldraw.ini file and how to use it are described on the l3p site, about halfway down the page.

Don

[Milan Vančura]

Thank you for the summary of the ldraw.ini history, I did not know this idea is so old because it was not implemented in any utility which is a part of LDraw Linux project nor any I worked with.
This week I have to prepare LEGO workshop for the weekend exhibition, I look at referenced documents then.