-
Notifications
You must be signed in to change notification settings - Fork 56
Diagram Widget Discussion
Diagrams are information-rich graphical representations that are typically views of an underlying model. Diagrams differ from mathematical graphs in several important respects:
- Diagram nodes tend to display a collection of information (e.g. a label and selected information about the underlying model element being displayed)
- Diagram links (depending on what is being represented) may connect nodes to other links or links to links in addition to the traditional node-to-node connection.
- There may be different types of diagram links (depending on what each represents) and, graphically, the links may be decorated to indicate these type differences.
- Diagram links may also display information about the links: a label for the link as a whole, a label for each end, and information about each end such as multiplicity constraints.
Diagrams are actually visual languages, typically with a formal grammar and semantics. Some common examples of diagrams are UML, Entity-Relationship Diagrams, and Business Process Model and Notation.
This effort is aimed at adding diagram capabilities to Fyne. In doing so, it is important to understand some ways in which diagrams differ from a typical widget layout:
- The container of the diagram typically does not constrain the layout of the contained nodes and links. It is a window into viewing the diagram, typically with scrollbars, zoom, and pan to view the underlying diagram.
- The layout of the nodes is determined by the author, with the author positioning diagram elements to facilitate human understanding of the displayed information. The author determines the elements that will be displayed and their positioning in the diagram. Automatic algorithms may be used to assist in selecting the scope of content and provide an initial layout, but these are invoked by the author as a matter of convenience.
- The authoring of a diagram is typically an interactive exercise, involving drag-and-drop for placing existing content in the diagram, tool selections for creating new content, and interactive placement and movement of the diagram elements.
The scope of work is a single widget (the Diagram widget) that is the container of the diagram itself. The diagram will comprise Node and Link widgets, each of which may contain any of the standard fyne widgets. In other words, data entry can be via Entry widgts, text display by either Label widgets or Text canvas objects. To the greatest extent possible we want to re-use the existing fyne architectural components.
Consistent with this philosophy, the remainder of an application will be comprised of standard fyne components.
The work that needs to be done breaks down into several categories
- The structure and organization of the Diagram, Node, and Link widgets and their associated layout and rendering components. Charles Daniels has already implemented an initial version of these.
- Decorations for links. While nodes tend to be boxed-together displays of text and icons, links tend to be lines. To be useful, decorations such as arrowheads, diamonds, circles often need to be added to the ends of the lines and sometimes in the middle as well (think of the triangle placed in the middle of a UML generalization relation). Textual annotations need to be added as well, both at the ends and in the middle. All of these present layout challenges: as the line rotates and scales, these decorations must move appropriately.
- Connection regions for connecting links to nodes and to other links. How are these connection areas defined? How can rules for connections (i.e. the grammar of the graphical language) be enforced?
- Drag-and-drop behavior: How to define the expected behavior when out-of-diagram elements are dragged into the diagram? What hooks (callbacks) need to be provided to invoke these behaviors?
- Selection Behavior: How to select elements in the diagram (one or many). What changes when an element is selected (e.g. do resize handles appear)?
- Movement and resizing of nodes: what graphical "handles" need to be provided? When do they appear? How do we define the behavior associated with moving each one?
- Connecting links to other elements: How does one "select" the end of a link and connect it to another element? How and when are the allowed connection regions on the target element displayed? When are the grammar-checking rules invoked?
- Editing the lines in the links: adding/removing breakpoints and moving those breakpoints around.
- Deletion semantics: Removing the display of an underlying model element from the diagram vs. actually deleting the underlying model element.
- Zoom and pan of the diagram in the Diagram widget.
- Useful layout and routing algorithms to aid in diagram layout.
See the Diagram Widget Interactive Behavioral Styles discussion
- Simple data binding to widgets embedded in nodes or links is available out of the box with fyne. Diagrams often require more complex mappings, displaying derived information. The mechanisms necessary to support more complex data relationships need to be explored.
There's a lot of work to be done. The game plan is to get something useful up and running with a structure that is expected to remain stable over time. Adding capabilities will then be (hopefully) backwards compatible. The test case for this work will be a relatively simple Concept Representation Language (CRL) editor (A Concept Representation Language (CRL)). A rudimentary editor for the language with a go-based back end and a browser-based interface is here. The initial effort is simply to port this editor to fyne and retire the browser-based interface.
Initial priorities are:
- Getting the initial node widget up and running. The basic widget sub-structure is largely complete based on Charles' work. Some rudimentary work on handles and connection regions is required (the present implementation has a single connection region that is the perimeter of the node).
- Adding more decoration capabilities to links. At present there is just an arrowhead, and it doesn't rotate with the line. Addressing the rotation, adding other decoration types, and adding a mid-point decoration capability are the current focus.
- Implementing basic link editing
- Implementing bindings to the underlying go representations of the language and the diagram.