LDFind 1.3.5.1

[Michael Heidemann]

Seems that I missed to announce version 1.3.5.0 of LDFind.

But that is good as there has been an error in that version.

So I just released the bugfix version 1.3.5.1 of LDFind.

The Name: tag is now again available as search word.

LDFind can be downloaded from http://ldraw.heidemann.org/index.php?page=ldfind

Please send all questions, suggestion for this version as answer to this thread.
Thanks.

[Philippe Hurbain]

Hi Mike,
The new version works fine here. Now a few possibilities for future development...
- Possibility to choose more options for the built-in viewer (mainly shading/lighting). This could be as low level as a .ini file in LDFind folder...
- Remember size of LDFind window across sessions (screens are getting larger these days...).
- Related to previous one, possibility to widen the text list window (by moving separation between text and preview windows) - descriptions are getting longer these days too
- And a more philosophical one: I never liked the negative choice ("Hide subparts", "hide primitives"), and would prefer a positive one ("Show subparts", "show primitives"). When I look for -say- a subpart, it seems much more natural to me to hit a "show subparts" checkbox, rather than hide parts, and primitives, and... (etc)

[Max Martin Richter]

Why didn't you fix the typo? ;-)

edit: fixed my own typo, here.

[Michael Heidemann]

Typo is fixed in my delop version, but yesterday I focused on the error and simply forgot about that until I uploaded the zip. And at that point I thought - ok, next time

[Michael Heidemann]

- Possibility to choose more options for the built-in viewer (mainly shading/lighting). This could be as low level as a .ini file in LDFind folder...

Personally I do not like these "hidden" possibilities. That's one of the reasons I never have stepped deeper into LINUX systems. I am very visually driven and therefore this should be done also by a good user interface.
Please let me know the names in the menu of DATHeader of the features you like to have, so it's easier for me to find the right function

- Remember size of LDFind window across sessions (screens are getting larger these days...).

Ok, that should be done quickly.

- Related to previous one, possibility to widen the text list window (by moving separation between text and preview windows) - descriptions are getting longer these days too

I know exactly what you mean. I have to see how many work this will generate. It's easy to be done in first layout, but later it can be more difficult.

- And a more philosophical one: I never liked the negative choice ("Hide subparts", "hide primitives"), and would prefer a positive one ("Show subparts", "show primitives"). When I look for -say- a subpart, it seems much more natural to me to hit a "show subparts" checkbox, rather than hide parts, and primitives, and... (etc)

I think this change will never happen as all the underlying code needs to be rewritten. Any benefit of the lot of work? - I can not see it in real. The global design of LDFind is to see the whole library and narrow your search until you find what you are looking for.
Your attempt will just inverse this what is IMHO not a good idea.


I invite also other users of LDFind to contribute to this wishlist, so I am hopefully able to fulfil most of your demands.

[Philippe Hurbain]

Personally I do not like these "hidden" possibilities. That's one of the reasons I never have stepped deeper into LINUX systems. I am very visually driven and therefore this should be done also by a good user interface.

That's something I totally agree. My point was that viewer in LDFind is not something you change, except on setup to get the configuration you like - a menu used only once might be considered as a waste

Please let me know the names in the menu of DATHeader of the features you like to have, so it's easier for me to find the right function

The functions I'd like to set in LDFind are
- Lighting / no specular highlight
- Lighting / no subdued lighting (BTW, there is a typo in Datheader, it's lighting, not lightning)
- Line smoothing enabled
- Texture map enabled

I think this change will never happen as all the underlying code needs to be rewritten. Any benefit of the lot of work? - I can not see it in real. The global design of LDFind is to see the whole library and narrow your search until you find what you are looking for. Your attempt will just inverse this what is IMHO not a good idea.

I don't agree, but as I said, it's a philosophical question ...especially if it's a lot of work!

[Michael Heidemann]

Short update:
1) Remember window size between sessions - done
2) Remember window position between sessions - done
3) Splitter between preview and listbox - done
4) Remember position of splitter between sessions - done
5) Options for preview quality - wip

[Travis Cobbs]

For what it's worth, if you call SetRegistryAppName() in LDVLib.dll (with, say, "Michael Heidemann/LDFind"), then any LDView-based settings placed in HKCU\Software\<your app name key> should control LDView's rendering for settings where you don't override the default setting via your own code. So most of the settings from LDView's help file would work, then. Settings that you set via code would override anything in the registry. Since you don't call that function (as far as I can tell), LDVLib simply uses default values for all settings that you don't explicitly set via code.

It's not really a good solution, but it would at least allow power users to configure the render settings.

[Michael Heidemann]

Just for clearifying - If I set a value by code this new value will be stored in the section in the registry? Or is this value only valid as long as i use my code?

[Travis Cobbs]

Values you set in code -- via functions like LDVSetUsesSpecular() -- won't be stored in the registry. However, if automatic downloading of unofficial parts is enabled (LDVSetCheckPartsTracker), it will write data into that registry area to record information about the last time it checked the parts tracker for updates to a given unofficial part.

[Michael Heidemann]

Thank you very much for clearifying.

[Travis Cobbs]

As I look more closely at the LDVLib code, I'm now pretty sure that even if you set the pref app name, it won't in fact use settings that are stored there.

[Christian Neumann]

As I look more closely at the LDVLib code, I'm now pretty sure that even if you set the pref app name, it won't in fact use settings that are stored there.

Maybe you can give me a hint what prerequisites are needed to use the ldvlib.dll? For some reason, i'm not able to see anything within the preview panes of Mike's tools, while the same tools do their work on other persons systems (see this thread). That leads me to the idea that my system is missing something the ldvlib.dll needs to run properly.

[Travis Cobbs]

There shouldn't really be any. LDVLib is a dynamic library based upon the LDView source code. Does LDView work on the same machine?

[Michael Heidemann]

Hi Travis, I have send some minutes ago a pm to you, also asking for help for Christian.
The problem seems to be in LDFind and LDStructure. Both do not show the parts like they do on other systems (Philo, mine).
But for curiosity DATHeader works fine and also LDView.
So it's up to me to fix the problems he has, but as I do not have problems on my system, it is difficult to find the problem

[Christian Neumann]

LDView works in both x86/x64 versions. I don't want to spam this thread with my problem, but was hoping for some "install runtime package xyz and it works" :-)

[Michael Heidemann]

@Christian - you do not spam this thread
We need to find out the problem and I need your help in this. Please send to my personal emailaddress (please see on my homepage) a message, so I can send a special build to you that is not for public as it should only help us to identify the problem. I am pretty shure it is my code in LDFind that creates this problems. But I can not see the problem on my system.

I am waiting for your email.
As I am german you can write also in german because I guess your name is also german

[Michael Heidemann]

This problem is now solved. A fixed version will be released soon.