Hi Willy, hi all,
thanks again for your detailed notes.
Most of them I tried to handle for the
current version which is online right now:
(2020-04-08, 11:52)Willy Tschager Wrote: * The installation under win was smooth but you should add a note to the wiki in case the install.bat is stored in the program folder it has to be run with admin privileges.
Done.
(2020-04-08, 11:52)Willy Tschager Wrote: * I'm still confused that something like the Workspace is positioned on the left border and not the items section I work with every day
Modified positioning. My first intention was to guide the new user from left to right in the tool bar, but you are right: most users will be used to have items left.
(2020-04-08, 11:52)Willy Tschager Wrote: * After setting workspace for the first time it should be automatically saved (to <user>\Appdata)at the closing of the dialog.
LDInspector now asks for configuration saving if it was started without configuration. At the moment the save dialog uses the "current directory" and not <user>\Appdata because I like the idea of having something portable. If LDInspector is "installed" on a portable medium like an USB stick, the configuration should go there in my oppinion.
(2020-04-08, 11:52)Willy Tschager Wrote: * I do not like the fact that my file is overwritten right away and that no backup is created. I would prefer a Save button, which saves all the modification at the very end.
I completely rewrote the concept of writing to files. The red buttons now do not overwrite the file, all changes are in memory until you activate "Save" button on the Item pane. This is much better, but I still don't like the current behavior of LDInspector to close or refresh without notice or confirmation if there is unsaved data. This needs some more work...
(2020-04-08, 11:52)Willy Tschager Wrote: * I don't like the order how the checks are presented. A mirrored part to me is secondary, while a correct header is key.
The mirror check is moved downwards and mirrors of the same part only take one line per sub-model, so output flooding as with LS60 in your example should be cured.
(2020-04-08, 11:52)Willy Tschager Wrote: * 0 FILE 364 - Harbour Scene - Warehouse - String.ldr has (among other things a license issue) The quickfix confirmed that a licences has been added but didn't show up in Source. I had to load another subfile and then reload the String to get rid of the error in the OMR-check
* My .mpd will never be OMRized because of: "error: file contains sub-parts, but filename does not end with .mpd"
* Does not update .mpd content after unofficial files have been imported
Double checked these three, but could not reproduce it with my current version.
(2020-04-08, 11:52)Willy Tschager Wrote: * FIlename of imported unofficial files is wrong.
* Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
I rewrote most of the code for filename checking and filename generating. Hopefully it is better starting with the current version!
(2020-04-08, 11:52)Willy Tschager Wrote: * Does not check for: 0 ROTATION CENTER 0 0 0 1 "Custom", 0 ROTATION CONFIG 0 0
I added a quick check for "unexpected" metas, but it only showed that I didn't understand the LDraw file format, yet.
So the current version does some checks, but the checks are not valid at the moment - instead they prove invalid file reading by the LDInspector LDraw parser. Especially unexpected meta lines before the description meta, but also even before the author meta breakes LDInspector edit code:
Code:
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
This breakes because LDInspector requires the first non-file-meta to be the description at the moment, so "!LEOCAD" is taken as description by accident. Even worse, the name tag is not written back correctly because my understand until last week
was that the header lines are always fixed. My only source of LDraw models is LDCad, which generates only very nice files.
Additionally, reading the article
https://forums.ldraw.org/thread-23904.html makes me thinking of re-writing the case-sensitivity of my parser.
I know, the file format is "grown historically", but making a difference between "0 FILE" and "0 File" depending on existence of other metas does not make me feel happy.
This leads to another substantial question: at the moment, LDInspector does only minimal change, i.e. writing a file will keep as many original lines as possible. Even correctly parsed files are not completely rebuild from the parsed structure but original source code will be inserted - for example to avoid floating point precision loss and to keep intentional formatting or comments. But with all those "special quirks" (with my understanding of last week) at least the meta handling has to be re-done. Even if all LDraw software would produce such nice files as LDCad does - "old files" should work with LDInspector, too. I would like to do the header parsing again, but at the moment I feel that I still don't understand all meta considerations.
Long story short: I will test some more officially released OMR files, but Willy's hint to un-OMR-ized 364 was extremely helpful.
So if you have non-LDCad-files that should be "ok" or have still known issues and that break LDInspector in some way, they most likely will be very helpful, too.
Thanks for all your feedback helping me on my way towards LDInspector 0.3...
I have to admit: my statement was misleading. For OMR-models, the names have to be in the way described in your link, and hopefully the name check detects this correctly. On the Edit pane the "inline unofficial parts" is not OMR compliant as well as the "inline unofficial parts" on the OMR-check page, at least if it is not followed by the name-compliance-check. My idea was that inlining is separated from naming - inlining just does inlining, the name-check afterwards does (should do) the renaming to OMR-compliance.