We are happy to release Xsemble 3.4.0. There are some future looking internal changes in this release. This release can therefore be considered as a bridge release to migrate old Xsemble projects so that they will be compatible with future releases. Users of previous release are strongly advised to install and move to this release.
Functionality-wise, there are improvements in the parameterization, health check and the burn dialog. Out of them, the parameterization improvements are important, as they enable project reuse.
These changes are explained below in detail.
Migrating Existing Xsemble Projects
All you need to do is to open your projects with the Assembler’s Workbench provided with this release. The project gets internally migrated and you get a dialog which informs you that the migration is done.
If you save the project, the changes become persistent. As the dialog warns, do not save in case you plan to open the project with a previous release of Xsemble. (But there is usually no reason to do so.)
Parameterization was introduced in Xsemble 2.5. This release enhances it in two respects:
- Global parameters may now be defined, and they may be referred in the node parameters and layer parameters by adding a dollar sign (‘$’) as a prefix. (See the following dialog to see how the global parameter ‘WARNAME’ is then referred as ‘$WARNAME’ in the definition of layer parameters below.
- The parameters for the entire project tree are defined and stored only in the top level project. There is no use of defining those within any child project, because those values will not be considered (unless you have plans to use the child project itself as a top level project). As seen in the following dialog, a helpful hint is included to remind users about this.
The second point can help you create reusable projects, to be used as child projects in any number of main projects. Any layer or node parameters in these projects would be set up in the top level project. This means that different projects that include these projects may set them up differently, and achieve different results based on the values of these parameters.
This elevates the reusability concept from the component level to the project level. Expect reusable projects to start coming up as a result of this improvement.
Health Check Enhancements
We have added checks to identify implementations that may not be ready to be used. Since long, Xsemble has the functionality to mark the status of component implementations. The implementation status is supposed to be set manually by the user, to indicate that the implementation is ready to use. Unless this status is set, the component implementation is flagged as not ready.
Identifying the anomalies in the readiness of implementation is important, especially before you burn or before you consider a repository of components ready. This check is therefore added to both the health check dialogs, in the Developer’s Workbench (at the repository level) and the Assembler’s Workbench (at the project level). The diagram below shows the dialog in the Assembler’s Workbench.
Compact Burn Dialog
With parameterization for the entire project happening at the top level project, the burn dialog needed to be redesigned. We managed to make it much sleeker than in version 3.2.
There are many other minor improvements in the UI, notably:
- The node dialog boxes no more have the parameters table. Instead, only the parameters that the component expects to be set are listed.
- Reminder dialog is added to set the implementation status correctly when you click the OK button on the component implementation dialog.
- Text changes for consistency of terminology have happened in a few places.