QCAD

I would really like to see this in the final release, if not in the next TP. I suspect lots of apps use extended parameters in a way that is incompatible with QCADs interpretation. So I made a mockup of how the property editor might look like. Currently (TP1) it reads "Custom" twice:

Custom properties are grouped by their APPID. QCAD ones are key value pairs, MyMill ones are just positional parameters - So sequence matters: in TP1 records are sorted alphabetically, that will not work with non-named entities. The "add" dialog should sport an additional drop down menu to select the group from known APPIDs.

In script this can be exposed as a method in RDocument to list (maybe even add/delete) APPIDs. The setPropoerty method of drawing entities might be overloaded so it takes two or three parameters. The APPID, the (optional (for QCAD style extended attributes)) key, a (single, typed) value.

Due to the complexity involved with this and the relatively small number of users requiring this feature, we will likely not support XDATA (custom properties) for the first release of QCAD 3.

In Beta handling of extended entity data was removed. If such data is in a file that QCAD handles, it will be lost when saving the file, and QCAD will remain silent on that.

The aCad way of specifying extended entity data is indeed peculiar, and I have been thinking about how to best represent it in a graphical interface. I think, it is a tree with the root node hidden, where the appIDs make up branches, and the typed data makes leaves of the kinds in the spec. Depth is limited to that: the root can only grow branches, the branches can only grow leaves. Leaves preserve order amongst them. This is the simplest model I can come up with.

I just keep adding to this, though I do not expect a quick resolve, especially, as I am beginning to see the complexity of xdata. I wrote down the spirit of the example from the specification, plus the TP of QCAD3 use of xdata as JSON:

{
  "AME_SOL": [
    { code: "1002", value: "{"         }, // Control String
    { code: "1070", value: 0"          }, // Integer
    { code: "1071", value: 1.95059E+06 }, // Long
    { code: "1070", value: 519         }, // Integer
    { code: "1010", value: 2.54717     }, // X
    { code: "1020", value: 2.122642    }, // Y
    { code: "1030", value: 2.049201    }, // Z
    { code: "1005", value: "ECD"       },
    { code: "1005", value: "EE9"       },
    { code: "1005", value: 0           },
    { code: "1040", value: 0.0         }, // Real
    { code: "1040", value: 1.0         }, // Real
    { code: "1000", value: MILD_STEEL  }  // String
  ],
  "QCAD": [
    { code: "1000", value: "MY_KEY"    },
    { code: "1000", value: "MY_VALUE"  },
    { code: "1000", value: "MY_INT"    },
    { code: "1070", value: 0"          },
    { code: "1000", value: "MY_REAL"   },
    { code: "1040", value: 0.0         }
  ]
}

The sample shows mostly static data, but there are some "codes", whose values will be affected by changes to the entity, to which the xdata is attached (1011, 1021, 1031, 1012, 1022, 1032, 1013, 1023, 1033, 1041, 1042). The closing brace at the end is not missing, AutoCAD will insert it. Code 1005, if I understand correctly, references other entities in a drawing. Although it is programmatically easy to tack such an object on to an entity from a QCAD script, a fully conforming implementation would have to translate some codes in certain behaviour, which obviously is quite a burden.

The TP of QCAD3 use of xdata indeed conforms to the specification. That these are alternating key value pairs is of no interest for applications other than QCAD or applications built on top of QCAD. Of course this assumption will only hold for the QCAD group, not for the AME_SOL group, just as the sequence of entries in the AME_SOL table only will be useful to applications that know how it is to be interpreted. But both QCAD and AME_SOL can rely upon the specification, that conforming applications will not make a mess of its peculiar xdata (at least the one in static codes).

Thanks. I appreciate your research into this!

Andrew, you are too kind. I am always a little afraid of leaning too far out of the window. Of course I do this on the agenda of my use case, namely instructing a robot programming application. For completeness what xdata it expects including the above - again as JSON, seen as just another serialization of what the DXF spec prescribes:

{
  "AME_SOL": [
    { code: "1002", value: "{"         }, // Control String
    { code: "1070", value: 0"          }, // Integer
    { code: "1071", value: 1.95059E+06 }, // Long
    { code: "1070", value: 519         }, // Integer
    { code: "1010", value: 2.54717     }, // X
    { code: "1020", value: 2.122642    }, // Y
    { code: "1030", value: 2.049201    }, // Z
    { code: "1005", value: "ECD"       },
    { code: "1005", value: "EE9"       },
    { code: "1005", value: 0           },
    { code: "1040", value: 0.0         }, // Real
    { code: "1040", value: 1.0         }, // Real
    { code: "1000", value: MILD_STEEL  }  // String
  ],
  "QCAD": [
    { code: "1000", value: "MY_KEY"    },
    { code: "1000", value: "MY_VALUE"  },
    { code: "1000", value: "MY_INT"    },
    { code: "1070", value: 0           },
    { code: "1000", value: "MY_REAL"   },
    { code: "1040", value: 0.0         }
  ],
  "MY_MILL" : {
    { code: "1000", value: "MY_FOO: some text" },
    { code: "1000", value: "MY_BAR: 1.250000"  }  
  }
}

It was undoubtedly nice, if qcad 3 final prompted the user with a notice, that xdata will be lost in files saved from qcad, if it encounters a code 1000 on any entity in a file it loads.

Later then, when custom entity data gets real, you might want to limit this message to the more involved types. Here a whitelist of types that are save, when not touched: 1000, 1002, 1004, 1010, 1020, 1030, 1040, 1070, 1071. All others require qcad to follow certain rules to keep them up to date, 1005 might require a hook into entity deletion, 1003 into layer renaming.

The scripting API should stay close to the serialization. Particularly, a qcad script developer should be able to create her own appID and assign xdata of that appID to entities, which may look like any of the above, except maybe the 1005 codes. Maintaining the model, the way an apps xdata is structured, should be a separate task. I suppose for example, that 1010, 1020, 1030 always have to immediately follow one another. That should be left to the app developer. qcad may offer convenience functions to scripters, that implement its preferred way of organizing xdata below its own QCAD appID.

So far, the only difference between this and what TP1 offered, is the addition of quasi low level xdata handling and custom appID creation - As a bonus I imagine the possibility of binding the choice of GUI used for editing xdata to the appID. Scripters would extend the prototype of a basic editor into one, that displays the appropriate controls and keeps the model intact. The property editor would not display "Custom", but instead "QCAD", and any registered editor. The most basic editor I imagine as just a black hole.

You pulled support for xdata from the BETA releases because it wrecked havock. Maybe a separation like that could help, especially if the core constrained itself to the low level stuff.

Peter, spending the evenig building castles in the sky