[LDView] LDView 4.4 Alpha 6 test release

[Travis Cobbs]

I have posted a test release for LDView 4.4 Alpha 6 to GitHub:

https://github.com/tcobbs/ldview/release...4.4_Alpha6

This release does have some known issues, but it also has quite a bit of new functionality, as well as some significant bug fixes.

Right now, I have only provided installers for macOS and 64-bit Windows. If you would like me to create an installer other than one of those two, please let me know.

The ChangeHistory.html file that is included in the release lists all of the changes. In the macOS version, ChangeHistory.html is in the dmg. In the Windows version, ChangeHistory.html gets installed to wherever you install LDView (C:\Program Files\LDView by default). I think the most important changes are:

1. Support for SPHERICAL and CYLINDRICAL texture maps.
   
2. Support for !DATA meta-command for embedding texture maps into MPDs.
   
3. Support for DPI scaling (AKA High DPI) on Windows, as well as Retina displays on macOS.
   
4. Support for macOS Finder thumbnail generation (toggle on LDraw tab of preferences).
   
5. Support for macOS Dark Mode.
   
6. Multiple important TEXMAP bug fixes.
   

[Philippe Hurbain]

As far as I can tell, there is a file path problem: 4.4 doesn't seem to find referred parts or subparts lying in the same folder or path relative folder.

[Travis Cobbs]

As far as I can tell, there is a file path problem: 4.4 doesn't seem to find referred parts or subparts lying in the same folder or path relative folder.

Thanks for the report. I will investigate.

[Travis Cobbs]

As far as I can tell, there is a file path problem: 4.4 doesn't seem to find referred parts or subparts lying in the same folder or path relative folder.

I don't understand what you are trying to say. Can you be more specific, and also preferably send me a zip example?

I thought you meant files that are in the same directory as the main file. But I tested that in both Windows and macOS, and it works fine for me. If that is what you are talking about, do you have an ldraw.ini? If so, if the LDrawSearch section is missing a <MODELDIR> entry, then that would be the expected behavior.

[Philippe Hurbain]

I thought you meant files that are in the same directory as the main file. 

Yes, that's exactly what I meant.

But I tested that in both Windows and macOS, and it works fine for me. If that is what you are talking about, do you have an ldraw.ini? If so, if the LDrawSearch section is missing a <MODELDIR> entry, then that would be the expected behavior.

I don't think I have an ldraw.ini file (or it would be well hidden!). What I can say for sure is that the same part file don't show same directory referred to files when I use LDVew 4.4, while it works fine when I use LDView 4.3 executable. Both executable versions sit in the same folder and share the same settings.

[Travis Cobbs]

Yes, that's exactly what I meant.
I don't think I have an ldraw.ini file (or it would be well hidden!). What I can say for sure is that the same part file don't show same directory referred to files when I use LDVew 4.4, while it works fine when I use LDView 4.3 executable. Both executable versions sit in the same folder and share the same settings.

Since I can't reproduce this, can you send me a zip file of a directory where this occurs for you, as well as letting me know which main file to open?

[Philippe Hurbain]

Since I can't reproduce this, can you send me a zip file of a directory where this occurs for you, as well as letting me know which main file to open?

OK, the problem is more subtle... it's related to French accentuated characters in the path. The folder where I create parts is named "Pièces en cours". In this folder, local subparts are not found. But, (as I noticed while preparing a zip for you), 4.4 works perfectly if the folder path doesn't contain special characters. The problem doesn't occur with 4.3.

[Travis Cobbs]

OK, the problem is more subtle... it's related to French accentuated characters in the path. The folder where I create parts is named "Pièces en cours". In this folder, local subparts are not found. But, (as I noticed while preparing a zip for you), 4.4 works perfectly if the folder path doesn't contain special characters. The problem doesn't occur with 4.3.

4.4 is actually supposed to fix problems with special characters in filenames, so it seems like I introduced a new one that wasn't present before. I would still appreciate it if you sent me a zip that includes the folder itself inside the zip.

Never mind about sending me a zip. I'm able to reproduce the problem.

[Travis Cobbs]

4.4 is actually supposed to fix problems with special characters in filenames, so it seems like I introduced a new one that wasn't present before. I would still appreciate it if you sent me a zip that includes the folder itself inside the zip.

Never mind about sending me a zip. I'm able to reproduce the problem.

So, I found the problem. I put a lot of effort into fixing LDView's support of Unicode characters in filenames, but forgot to enable one part of that code in my Windows Release build settings. Since all my other code had been updated to treat all filenames as Unicode (specifically, UTF-8, mostly), the one remaining bit of code that didn't do that didn't work at all any more. 

[Philippe Hurbain]

So, I found the problem. I put a lot of effort into fixing LDView's support of Unicode characters in filenames, but forgot to enable one part of that code in my Windows Release build settings. Since all my other code had been updated to treat all filenames as Unicode (specifically, UTF-8, mostly), the one remaining bit of code that didn't do that didn't work at all any more. 

Sorry, night time when I saw your message yesterday. Great you found the problem anyway 

[Travis Cobbs]

Not sure if anyone is interested, but I found an online tool that lets you preview html files checked into GitHub. So here is a link to the LDView 4.4 Alpha 6 Change History (the same file that is distributed with the release):

https://htmlpreview.github.io/?https://g...story.html

[Philippe Hurbain]

Wondering... would it make sense to add some form of primitive substitution to lores 8\primitives? They would - for example - get higher number of sides, half of what normal primitives get?

[Steve J.]

I have posted a test release for LDView 4.4 Alpha 6 to GitHub:

https://github.com/tcobbs/ldview/release...4.4_Alpha6

This release does have some known issues, but it also has quite a bit of new functionality, as well as some significant bug fixes.

Right now, I have only provided installers for macOS and 64-bit Windows. If you would like me to create an installer other than one of those two, please let me know.

The ChangeHistory.html file that is included in the release lists all of the changes. In the macOS version, ChangeHistory.html is in the dmg. In the Windows version, ChangeHistory.html gets installed to wherever you install LDView (C:\Program Files\LDView by default). I think the most important changes are:

1. Support for SPHERICAL and CYLINDRICAL texture maps.
   
2. Support for !DATA meta-command for embedding texture maps into MPDs.
   
3. Support for DPI scaling (AKA High DPI) on Windows, as well as Retina displays on macOS.
   
4. Support for macOS Finder thumbnail generation (toggle on LDraw tab of preferences).
   
5. Support for macOS Dark Mode.
   
6. Multiple important TEXMAP bug fixes.
   

Requesting installer for Linux...  I have been using Ubuntu (16.04) 64 bit .deb up to this point on Linux Mint 19.x (Debian, Ubuntu 18.04 LTS) and Mint 18.x prior.  I have had to manually pull in one or two dependencies to make it work on Mint 19.x, but it does and beats rolling the dice with WINE.  Thanks for the continuing work.

[Travis Cobbs]

Requesting installer for Linux...  I have been using Ubuntu (16.04) 64 bit .deb up to this point on Linux Mint 19.x (Debian, Ubuntu 18.04 LTS) and Mint 18.x prior.  I have had to manually pull in one or two dependencies to make it work on Mint 19.x, but it does and beats rolling the dice with WINE.  Thanks for the continuing work.

Various Linux installers were added after my initial post. Does one of them work?

[Travis Cobbs]

Wondering... would it make sense to add some form of primitive substitution to lores 8\primitives? They would - for example - get higher number of sides, half of what normal primitives get?

Maybe. My existing substitution for 48 primitives simply forces them to have at least 48 segments. (So, if you set the curve quality on a notch for 48 or more segments, they end up with the same number of segments as the standard primitives.) I could in theory support 8\ primitives so that they always have half as many as the others. Unfortunately, it would be a huge number of small changes to my code base (at least 270), which would be a royal pain.

[Steve J.]

Various Linux installers were added after my initial post. Does one of them work?

I tried the ldview-qt5-4.4a6-ubuntu-20.04.amd64.deb on Mint 19.3.  There were some dependencies not present (2?) and installed packages not meeting version requirements (1?).  I realize the generic nature of that statement does not help, but in the process of trying to satisfy individual dependencies manually I have busted my system to the point where it is stuck in a boot loop.  I think it had something to do with the libgcc/libqt5 packages.  I did a sudo apt-get install -f, followed by a sudo apt autoremove and it went down the drain from there.  I think the latter inadvertently wiped out something required for the greeter/x-session since it thought it was no longer needed.

I'll venture to guess that you were building specifically to recently released Ubuntu 20.04 LTS to stay ahead of the curve and all of those dependencies are met in that environment.  Mint 20.x hasn't quite hit the street clear of beta yet, should within the next week or so based on reports.  I'll try again then.  I was willing to take the gamble because I got the 16.04 build(s) to work in the 18.04 environment without destroying anything, but in hindsight I should have known that backwards compatibility from the future was no guarantee as opposed to better luck with old builds going into future releases.  Oh well...  (Where did I put that backup image?)

[Roland Melkert]

I'll venture to guess that you were building specifically to recently released Ubuntu 20.04 LTS to stay ahead of the curve and all of those dependencies are met in that environment.  Mint 20.x hasn't quite hit the street clear of beta yet, should within the next week or so based on reports.  I'll try again then.  I was willing to take the gamble because I got the 16.04 build(s) to work in the 18.04 environment without destroying anything, but in hindsight I should have known that backwards compatibility from the future was no guarantee as opposed to better luck with old builds going into future releases.  Oh well...  (Where did I put that backup image?)

I've found that building on Debian results in the best / widest compatibility as most of the other popular distributions are forks of it in one way or another.

I also use static linking as much as possible / permitted by licenses etc to increase LDCad's generic binary usability.

Just my 2cts

[Peter Bartfai]

I tried the ldview-qt5-4.4a6-ubuntu-20.04.amd64.deb on Mint 19.3.  There were some dependencies not present (2?) and installed packages not meeting version requirements (1?).  I realize the generic nature of that statement does not help, but in the process of trying to satisfy individual dependencies manually I have busted my system to the point where it is stuck in a boot loop.  I think it had something to do with the libgcc/libqt5 packages.  I did a sudo apt-get install -f, followed by a sudo apt autoremove and it went down the drain from there.  I think the latter inadvertently wiped out something required for the greeter/x-session since it thought it was no longer needed.

I'll venture to guess that you were building specifically to recently released Ubuntu 20.04 LTS to stay ahead of the curve and all of those dependencies are met in that environment.  Mint 20.x hasn't quite hit the street clear of beta yet, should within the next week or so based on reports.  I'll try again then.  I was willing to take the gamble because I got the 16.04 build(s) to work in the 18.04 environment without destroying anything, but in hindsight I should have known that backwards compatibility from the future was no guarantee as opposed to better luck with old builds going into future releases.  Oh well...  (Where did I put that backup image?)

Added LinuxMint 19.3 binaries to GitHub release. Please give it a try:

https://github.com/tcobbs/ldview/release....amd64.deb
https://github.com/tcobbs/ldview/release....amd64.deb

[Steve J.]

Added LinuxMint 19.3 binaries to GitHub release. Please give it a try:

https://github.com/tcobbs/ldview/release....amd64.deb
https://github.com/tcobbs/ldview/release....amd64.deb

Thanks, will do.  (What's the difference, if any, between the two?)  In the meantime, I wanted to report that the ldview-qt5-4.4a6-ubuntu-20.04.amd64.deb installs/works on Linux Mint 20 - no complaints from package manager, no need to run sudo apt-get install -f.

[Travis Cobbs]

Thanks, will do.  (What's the difference, if any, between the two?)  In the meantime, I wanted to report that the ldview-qt5-4.4a6-ubuntu-20.04.amd64.deb installs/works on Linux Mint 20 - no complaints from package manager, no need to run sudo apt-get install -f.

The osmesa version is the command line-only version that is used purely for generating images.

[N. W. Perry]

Support for macOS Finder thumbnail generation (toggle on LDraw tab of preferences).

So, I love having this feature (although it does seem to give up after a while of generating thumbnails, and just revert to the default icon, probably a memory issue).

However, this also takes over Quick Look functionality; previously, the files would preview in TextEdit, which was nice since it allowed me to check the code without having to use Open With… (LDView was already set as the default for opening files). Is there any way to have it both ways—let LDView generate thumbnails, but still use TextEdit for Quick Look previews?

(Also, toggling the preference doesn't seem to stop thumbnail generation, but maybe I have to relaunch Finder or reboot for it to take effect.)

[Travis Cobbs]

So, I love having this feature (although it does seem to give up after a while of generating thumbnails, and just revert to the default icon, probably a memory issue).

However, this also takes over Quick Look functionality; previously, the files would preview in TextEdit, which was nice since it allowed me to check the code without having to use Open With… (LDView was already set as the default for opening files). Is there any way to have it both ways—let LDView generate thumbnails, but still use TextEdit for Quick Look previews?

(Also, toggling the preference doesn't seem to stop thumbnail generation, but maybe I have to relaunch Finder or reboot for it to take effect.)

I will investigate both problems. I honestly don't know if it's possible to generate a QuickLook thumbnail without also generating a QuickLook preview.

[N. W. Perry]

I will investigate both problems. I honestly don't know if it's possible to generate a QuickLook thumbnail without also generating a QuickLook preview.

It looks like that preference state is simply not being saved. Each time I reopen the program, that box is re-checked.

As a workaround in the meantime, is there a QuickLook plugin that can be disabled? (I found them, but didn't see one obviously related to LDView.)

[Travis Cobbs]

It looks like that preference state is simply not being saved. Each time I reopen the program, that box is re-checked.

As a workaround in the meantime, is there a QuickLook plugin that can be disabled? (I found them, but didn't see one obviously related to LDView.)

I don't know how to disable QuickLook plugins, but anything advertising for com.cobbsville.* would be from LDView. Also, since LDView.app isn't singed, you can probably remove the Library directory from inside the LDView.app directory. (The only thing in LDView.app/Library is the QuickLook plugin.

I did some more research, and it looks like, if you want to see the model image in the right pane of column-mode Finder, you definitely have to have previews enabled (which is what gets used when you hit space, I think). I still haven't determined if it is possible to have thumbnails without previews.

I haven't yet been able to reproduce the problem with the enabled setting not saving. I'll keep looking.

[Steffen]

Hello Travis,
it is awesome to see a new LDView release upcoming.
I am currently thoroughly checking out this one, here's my feedback:

(1)
I was double-checking some problem I had with camera location and lookat export to POVRay.
The problem I am suspecting is that the camera location shifting which can be done by CTRL+Mousedrag
does not make it into the POVRay export. During that I wanted to confirm that the camera location export
to clipboard (menu: "Tools" / "Show View Info...") works correctly. And voila:
there the same problem occurs: if you shift the camera by CTRL-Mousedrag, this change is not reflected in the camera data which is copied to
the clipboard. I was able to reproduce this bug also in the currently official release 4.3.

(2)
I like that LDView now supports !TEXTURE elements. However, they did not make it into the POVRay export for me.
That's a pity I think, because I think adding that would be nearly trivial, compared to supporting it in LDView itself.
Or did I miss something? I tried the POVRay export with the file attached.

Maybe I will come up with more things in another post.

best
Steffen

[Travis Cobbs]

Thank you for your reports. Responses below.

(1)
I was double-checking some problem I had with camera location and lookat export to POVRay.
The problem I am suspecting is that the camera location shifting which can be done by CTRL+Mousedrag
does not make it into the POVRay export. During that I wanted to confirm that the camera location export
to clipboard (menu: "Tools" / "Show View Info...") works correctly. And voila:
there the same problem occurs: if you shift the camera by CTRL-Mousedrag, this change is not reflected in the camera data which is copied to
the clipboard. I was able to reproduce this bug also in the currently official release 4.3.

I created an Issue for this on GitHub. I will investigate, and attempt to fix the problem in both places.

(2)
I like that LDView now supports !TEXTURE elements. However, they did not make it into the POVRay export for me.
That's a pity I think, because I think adding that would be nearly trivial, compared to supporting it in LDView itself.
Or did I miss something? I tried the POVRay export with the file attached.

Unfortunately, that's not going to happen in the 4.4 release. I wanted it to be supported, and I actually spent a ton of time trying to get this to work, but I failed miserably. (So badly that I just threw out everything I did, since not only did it not work at all, but it didn't seem like the path I was going down could even be made to work.) It's obviously possible, but I decided to spend my limited amount of time working on other things.

Maybe I will come up with more things in another post.

All problem reports are appreciated. If you have a GitHub account (or create one), you can create issues directly in LDView's GitHub project. If you post them here, I'll try to create such issues for my own tracking purposes.

[N. W. Perry]

I haven't yet been able to reproduce the problem with the enabled setting not saving. I'll keep looking.

I wonder if it could have to do with the existing 4.3 installation, the two versions trying to read the same prefs file or something?

[Travis Cobbs]

I wonder if it could have to do with the existing 4.3 installation, the two versions trying to read the same prefs file or something?

LDView uses the standard macOS preferences mechanism to store its preferences. Ultimately these settings go to com.cobbsville.LDView* files in ~/Library/Preferences, and are in fact shared between different versions. However, this particular preference goes into its own separate file, and that file isn't used by LDView 4.3.

[Steffen]

> All problem reports are appreciated.

Yes, good, I also would like to have them seen as that, not as nitpicking.
LDView is my everyday go-to tool, and appreciated a lot, and I think you know that.

> If you have a GitHub account (or create one), you can create issues directly in LDView's GitHub project

Nice. Doing that is much preferred over these forum posts. Thanks.

[Travis Cobbs]

(1)
I was double-checking some problem I had with camera location and lookat export to POVRay.
The problem I am suspecting is that the camera location shifting which can be done by CTRL+Mousedrag
does not make it into the POVRay export. During that I wanted to confirm that the camera location export
to clipboard (menu: "Tools" / "Show View Info...") works correctly. And voila:
there the same problem occurs: if you shift the camera by CTRL-Mousedrag, this change is not reflected in the camera data which is copied to
the clipboard. I was able to reproduce this bug also in the currently official release 4.3.

I created an Issue for this on GitHub. I will investigate, and attempt to fix the problem in both places.

The "Show View Info..." dialog does not support arbitrary camera positioning. This is in fact documented in LDView's help. The reason for this is that LDView doesn't support arbitrary camera positioning from the command line. It probably won't ever.

The POV export does support arbitrary camera positioning. If you can provide me with a set of steps where this isn't working properly, please do. Please note that in order to be sure that it isn't working properly, you must use View->Standard Sizes in LDView to select an aspect ratio that matches your aspect ratio in POV-Ray. I would appreciate it if you would add your feedback to the GitHub issue linked above.