Difference between revisions of "VDCT Bugs and Features Page"
From EPICSWIKI
(Initial version of bugs and features page.) |
|||
Line 28: | Line 28: | ||
=== Major, EPICS V4 related improvements === | === Major, EPICS V4 related improvements === | ||
# Define a | # Define a interface that will allow VDCT to interact with other high-level tools - e.g. so it can query a relational database query for current field values. VDCT can give the link structure and the default value for fields, but the actual value should be able to be over-ridden by database values. | ||
# Allow a simple arithmetic syntax in macro expansion. e.g. if <tt>$(basenum)=10</tt> then <tt>$(basenum:+1)=11</tt>. I am happy for this to be restricted to a single operator and a pure number - arithmetic between two macros is probably too much. OTOH, I find Hex addition is appealing: e.g. if <tt>$(basename)=FF</tt> then <tt>$(basename:+0x3)=102</tt>, with the Hex result being generated because of the hex number being added. (BTW, I am not fussed about the syntax here - an alternative would be to borrow the Bash <tt>$(($(basename)+3))</tt> syntax as an alternative). This may not be V4, but the concept of substitution and macros may be a bigger issue. | # Allow a simple arithmetic syntax in macro expansion. e.g. if <tt>$(basenum)=10</tt> then <tt>$(basenum:+1)=11</tt>. I am happy for this to be restricted to a single operator and a pure number - arithmetic between two macros is probably too much. OTOH, I find Hex addition is appealing: e.g. if <tt>$(basename)=FF</tt> then <tt>$(basename:+0x3)=102</tt>, with the Hex result being generated because of the hex number being added. (BTW, I am not fussed about the syntax here - an alternative would be to borrow the Bash <tt>$(($(basename)+3))</tt> syntax as an alternative). This may not be V4, but the concept of substitution and macros may be a bigger issue. | ||
=== Capfast compatibility === | === Capfast compatibility === | ||
# Enable the Capfast converter to recognise Capfast macros. The are implemented via a horrible method of having a setX property (where X is any character). However, it would be nice if these properties were correctly recognised as macros. | # Enable the Capfast converter to recognise Capfast macros. The are implemented via a horrible method of having a setX property (where X is any character). However, it would be nice if these properties were correctly recognised as macros. | ||
# Enable the Capfast converter to use the Capfast wire position points as hints as to where to place the vdct wires. The wires should at least have about the same number of segments. | # Enable the Capfast converter to use the Capfast wire position points as hints as to where to place the vdct wires. The wires should at least have about the same number of segments.<nowiki>Insert non-formatted text here | ||
=== Wishful thinking enhancements === | === Wishful thinking enhancements === | ||
# More generally, improve the wire positioning algorithm.... This is a big topic and needs thought. However, I don't believe people like the way it is at the moment. I am willing to work on a definition for this. | # More generally, improve the wire positioning algorithm.... This is a big topic and needs thought. However, I don't believe people like the way it is at the moment. I am willing to work on a definition for this. | ||
# Provide an "auto-placement" function, that when reading in non VDCT databases tries to place all records to 1) eliminate the overlap of records and 2) to minimize the crossing of links (auto-routing). | |||
# The merging of the concepts of an off-page input and a macro is confusing. I am not sure whether this is a problem, just thought I'd raise it. | # The merging of the concepts of an off-page input and a macro is confusing. I am not sure whether this is a problem, just thought I'd raise it. | ||
# Deprecate the group concept. I suspect the only people who use groups will want to move onto separate file hierarchies when they move to bigger systems? It seems to be a dead end - a nice idea, but not what I want. (I know this is controversial because some people use groups...) | # Deprecate the group concept. I suspect the only people who use groups will want to move onto separate file hierarchies when they move to bigger systems? It seems to be a dead end - a nice idea, but not what I want. (I know this is controversial because some people use groups...) | ||
# Visualization of the process chain (an EPICS database simulator) | |||
# Show links between groups (display a group as a "meta-record") display external links also in the "group" displays. ''(Editors note: I think this is has really been implemented in hierarchy implementation).''</nowiki> |
Revision as of 13:54, 9 June 2005
- Note:* To edit this page click the "Edit Page" link at the bottom. For more help on editing, look at the DLS wiki page.
Bug fixes
- The addpath command in the dbd file is interpreted as specifying relative paths to be concatenated with the absolute paths specified in the path command. In fact, the definition of addpath in EPICS is that they are just additional paths. (I think the only reason for doing it this way was there wasn’t the syntax to do path “${path}:/new/directory/here”. (Note: The addpath functionality as implemented is potentially useful, but is wrong – it should be implemented as a different command and built into dbExpand).
- When connecting more than one wire to a macro, the macro always reverts to the default orientation. It should be oriented in the natural direction for the majority of the wires.
- Fix problems with undo/redo. Sometimes when you undo a move the objects don’t go back in the same place.
- Dragging multiple objects sometimes ends up with some objects moving a different distance than others. This seems to be related to objects changing their snap point at different times, but if all objects start off snapped to grid, then they should all change their snap point at the same time. This problem also results in horizontal lines being non-horizontal after a move, since the endpoints snap at different times.
- Near-vertical wires shouldn’t get an awkward kink in them when you add a connection anchor. This isn’t intuitive.
- When some fields are marked as not visible as connection points in a template instantiation in a hierarchy, they seem to be hidden under a visible connection point and come to the front when the cursor hovers over them. Then when you add a connector, the connector doesn’t get added to the visible wire and connection point, but to the hidden one.
- Wire anchor connectors that are connected to a template instantiation in a hierarchy don’t get preserved through a save/restore cycle.
- The font used for the name of a template instantiated in a hierarchy is too large, IMHO.
- The SCAN field doesn’t show up as an allowable input variable when trying to connect to a record from a hierarchical port. You can work around this by connecting from another’s record output link to a SCAN field is to make the SCAN visible as a connection anchor, then connecting the hierarchical port, then deleting the temporary connection.
- You can’t add a connection anchor point to a wire connecting a record field and an external port or macro. Currently, this isn't possible because you need to click on the link field in the record to add a connector, but these wires don't have a link field.
Enhancements
Things we can do now because they are minor funtional improvements
- Implement an option to save the current file if the file is changed and you are traversing the hierarchy tree. At the moment you can only elect: to not save then traverse, or to cancel the traverse. We would like to save then traverse.
- Eliminate all the small, fractional grid size steps in wires going to off-page connectors and objects. The best way to do this is to ensure that if an object is snapped to the grid, then all anchors on the object are also are snapped to the grid (i.e. are on one of the horizontal lines of the grid).
- Add an environment variable search path for .vdb files used in the hierarchy so you can store useful modules in a central location.
- Add support for EPICS_DB_INCLUDE_PATH in dbd file expansion.
- Enable more than one delimiter when generating a single capfast-style hierarchy. This may need to be discussed more widely since it may impact the EPICS V3.15 hierarchy. However, it recognises that not everyone has chosen a single hierarchy delimiter (Diamond starts off with a – delimiter and changes it to : after a certain depth, mores the pity).
- Allow drawing borders (just like the borders around mechanical and electrical engineering drawings) which have author, id, name and change blocks. They will consist of lines, rectangles and text blocks, but no records. Once merged, the block should remain as a single block but, ideally, the text should be editable. (/These should be implemented as drawings you can merge in with an existing drawing./ This could possibly be done by adding a more comprehensive functionality to merge drawings. It might be done by allowing access to the include statement, but making included objects largely read-only, so the include statement remains in the .vdb file, instead of getting expanded)
- Allow you to change the size of drawing objects (lines and boxes).
- Allow you to select lines and wire segments by clicking on the line, not just the anchor.
- Add the ability to copy field values to multiple records quickly – possibly by selecting multiple records and then modifying the Inspector so it only displays the intersection set of all the available fields. This may be done as part of the spreadsheet view upgrade.
- Define a interface that will allow VDCT to interact with other high-level tools - e.g. so it can query a relational database query for current field values. VDCT can give the link structure and the default value for fields, but the actual value should be able to be over-ridden by database values.
- Allow a simple arithmetic syntax in macro expansion. e.g. if $(basenum)=10 then $(basenum:+1)=11. I am happy for this to be restricted to a single operator and a pure number - arithmetic between two macros is probably too much. OTOH, I find Hex addition is appealing: e.g. if $(basename)=FF then $(basename:+0x3)=102, with the Hex result being generated because of the hex number being added. (BTW, I am not fussed about the syntax here - an alternative would be to borrow the Bash $(($(basename)+3)) syntax as an alternative). This may not be V4, but the concept of substitution and macros may be a bigger issue.
Capfast compatibility
- Enable the Capfast converter to recognise Capfast macros. The are implemented via a horrible method of having a setX property (where X is any character). However, it would be nice if these properties were correctly recognised as macros.
- Enable the Capfast converter to use the Capfast wire position points as hints as to where to place the vdct wires. The wires should at least have about the same number of segments.Insert non-formatted text here === Wishful thinking enhancements === # More generally, improve the wire positioning algorithm.... This is a big topic and needs thought. However, I don't believe people like the way it is at the moment. I am willing to work on a definition for this. # Provide an "auto-placement" function, that when reading in non VDCT databases tries to place all records to 1) eliminate the overlap of records and 2) to minimize the crossing of links (auto-routing). # The merging of the concepts of an off-page input and a macro is confusing. I am not sure whether this is a problem, just thought I'd raise it. # Deprecate the group concept. I suspect the only people who use groups will want to move onto separate file hierarchies when they move to bigger systems? It seems to be a dead end - a nice idea, but not what I want. (I know this is controversial because some people use groups...) # Visualization of the process chain (an EPICS database simulator) # Show links between groups (display a group as a "meta-record") display external links also in the "group" displays. ''(Editors note: I think this is has really been implemented in hierarchy implementation).''