| ID: | 2494 |
| From: | ge...@igor2.repo.hu |
| Date: | Sat, 1 Dec 2018 15:13:44 +0100 (CET) |
| Subject: | [pcb-rnd] IO upgrade: better incompatibility indication (major improvement) |
Hi all, as I mentioned in the other mail, the drc dialog upgrade also brought us a new, generic "list of board views/locations" infrastructure - both how we store/load/save/copy them and how we display them on the GUI. (FYI, shorthand term is "view list".) This enabled me (spending only 2 hours development time) to finally implement a feature I was planning since late 2016: better io save incompatibility indication! When you save a native pcb-rnd board in an alien format, we rarely can say the save file 100% accurately captures all details the original design has. Most often the save code knows what exactly can not be done in the target format and notifies the core.^1 (Note: save incompatibility does NOT render your in-memory data unusable^2. If you don't want to lose details, just make sure you also save it in native format (even after saving to alien format, but before exiting).) We used to indicate such incompatibilities by priting long log messages. Now we indicate them by opening a view list, a very similar dialog box to the new DRC dialog. After all, these are just errors the user may need to fix to make the output alien file usable. There's a config node^3 to enable/disable the dialog - some users hate popups. When disabled, the code reverts to the old logging. There's another config node^4 to set which dialog mode should be used: the full featured "list" mode or the simplified "simple" mode. Until we have the tree widget in lesstif, lesstif users need to set this to simple to make the dialog useful. Because one of our selling points is advanced file format support, I consider this a major improvement. For non-pcb-rnd users, we are now not just a converter between formats, but also a viewer for conversion compatibility issues! Best regards, Igor2 Footnotes: ^1: this is normal: different EDA tools have different model of the world and there's usually no 1:1 translation. All we can try is do our best to find closely matching features and warn the user about potential problems. With the new data model, we are rather good on the load side: our model is mostly a superset of what other EDAs can represent, so we can load most of the files withot data loss. However, when saving to a weaker alien format, we have to sacrifice some details. ^2: we store the Master Version of any data in memory. The cosest disk representation is our native format, lihata board. Unless there's an unreported bug, the lihata board format is 100% compatible with the in-memory version. But don't forget: it's still a translation, between raw C pointers and binary numers and lihata text. When you save in an alien format, a different conversion is made, to a different, weaker format that often can capture less than 100% of the in-memory details. However, such a conversion won't affect the source, that is, saving a less capable file will not downgrade the in-memory representation. So if you save your rich board into a poor format, then save it again in native format, you didn't lose any data on the second save. The only way to lose data is saving in a poor format, then discard the in-memory data and load it again from the poor format. ^3: editor/io_incomp_popup ^4: editor/io_incomp_style
Reply subtree:
2494 [pcb-rnd] IO upgrade: better incompatibility indication (major improvement) from ge...@igor2.repo.hu