|
| 1 | +(updated on oct. 13, 2021) |
| 2 | + |
| 3 | +# QueryBrowser |
| 4 | + |
| 5 | +## Result list |
| 6 | + |
| 7 | +bottom list is currently sorted by "kind of entities" and is "read-only" |
| 8 | + |
| 9 | +- we want also a hierarchical tree of entities: |
| 10 | +``` |
| 11 | + > package1 |
| 12 | + > class11 |
| 13 | + > class12 |
| 14 | + method121 |
| 15 | + method122 |
| 16 | + > package2 |
| 17 | +``` |
| 18 | +(note: with workspace browser, this part could be detached from the QueryBrowser to become a simple EntityListPresenter ...) |
| 19 | + |
| 20 | +# Durden workspace |
| 21 | + |
| 22 | +(Santi's stuff) |
| 23 | +It allows to group several tools in one window. |
| 24 | + |
| 25 | +It is a MiBrowser, so it listens and writes on bus(es) |
| 26 | + |
| 27 | +It has an "internal bus" that it's children browsers listen and write |
| 28 | + |
| 29 | +The workspace make the bridge between external bus(es) and its internal bus: |
| 30 | +- takes incoming entities on external bus and send them on internal bus, |
| 31 | +- takes entities on internal bus to propagate them on external bus(es). |
| 32 | +- propagation on internal bus is automatic, |
| 33 | +- propagation to external bus(es) is on demand |
| 34 | + |
| 35 | +# Property Browser |
| 36 | + |
| 37 | +A tool to define properties. A property has: |
| 38 | +- a name |
| 39 | +- a boolean query to decide if an entity has this property or not |
| 40 | +- a color (optional?) |
| 41 | + |
| 42 | +Note: Property is a kind of "virtual tag", or a tag computed on the fly but not stored in the model |
| 43 | + |
| 44 | +The query will be taken from the Query Browser, for example: |
| 45 | +Property: name="someName", color=red, query=Q1 |
| 46 | + |
| 47 | +So we need a mechanism to share queries between different tools. |
| 48 | +This tool can ask the QueryBrowser, what are the queries available and allow to select one of the query to create a property from it |
| 49 | + |
| 50 | +# TagBrowser |
| 51 | + |
| 52 | +Possibility to define tags from properties |
| 53 | + |
| 54 | +# Hierarchical Map with properties |
| 55 | + |
| 56 | +Displays incoming entities in a hierarchicalView https://github.com/ObjectProfile/HierarchicalVisualizations |
| 57 | + |
| 58 | +Has a list of properties (taken from PropertyBrowser) |
| 59 | + |
| 60 | +For each displayed entity, if it matches one property query, will give the color of the property to the entity. |
| 61 | + |
| 62 | +If an entity match several queries, 2 options: |
| 63 | +- give a specific color (black, gray, red) |
| 64 | +- choose the first one |
| 65 | + |
| 66 | +# Distribution Map |
| 67 | + |
| 68 | +We want a distribution map browser |
| 69 | + |
| 70 | +Probably based on the prototype in https://github.com/NicolasAnquetil/HierarchicalVisualizations, not on the telescope one |
| 71 | + |
| 72 | +Will work somehow like the **Hierarchical Map with properties** for the properties, but the Distribution map wants exaclty 2 levels of entities: Containers and members |
| 73 | +So we need to force this: |
| 74 | +- entities coming from the bus should be of that form => user responsible for selectyng the right entities with the proper query |
| 75 | +- entities coming from the bu are the containers and the tool accept one query that will produce members for each of these incoming container |
| 76 | + |
| 77 | +# Favorites Browser |
| 78 | + |
| 79 | +A tool to record some favorites "things" that the user like: |
| 80 | +- launching a browser |
| 81 | +- running a favorite query and automatically propagate the result on the bus(es) |
| 82 | +locations) |
| 83 | +- running a Property ??? |
| 84 | + |
| 85 | +# System complexity |
| 86 | + |
| 87 | +Recreate the system complexity browser (3 metrics displayed with width, height, and color) |
| 88 | +Entites are displayed in a tree |
| 89 | + |
| 90 | +Possibly accept colored properties (with only 2 metrics with width and height) |
| 91 | + |
| 92 | +Starting at a given level, containement is not shown as a tree, but as a HierarchicalVisualization |
| 93 | + |
| 94 | +# Double Dispatch buses |
| 95 | + |
| 96 | +When a tool wants to send an entity on a bus, it should ask this entity what bus to use. |
| 97 | +Their will be buses specialiazed for all types of entities (including a generic bus "specialized" for MooseEntity) |
| 98 | + |
| 99 | +And when a tool is expecting entities of a special type, it should ask the class of this entity what bus can carry it and then ask the application for available buses of this type. |
| 100 | + |
| 101 | +We will still be able to have several buses for the same type (see issue: (https://github.com/moosetechnology/MooseIDE/issues/320)[https://github.com/moosetechnology/MooseIDE/issues/320] |
| 102 | + |
| 103 | +# Propagation strategy buses |
| 104 | + |
| 105 | +We could have at least 3 kind of buses: |
| 106 | + |
| 107 | +- push bus: when data is written on the bus, it immediately transmits it to all tools attached to it |
| 108 | +- delayed bus: when data is written on the bus, it stores it and only transmits when there is an explicit "flush" from the producer (allow to work with the "Propagate" button of the tools) |
| 109 | +- pull buses, bus stores data and does not transmit it unless explicitly asked by a receiver tool |
| 110 | + |
| 111 | +The last 2 are a bit similar: one is a flush from the producer to all consumers the other is a flush from the consumer only to itself. |
| 112 | + |
| 113 | +This will allow to have: |
| 114 | +- an internal bus for MooseWorkspace that transmit data immediately to all tools in the workspace (*push* internal bus) ; |
| 115 | +- bus for separate tools that tranmit only on request (*delayed bus* + Propagate button) ; and |
| 116 | +- a bus for some specific cases where we want to share data on demand: |
| 117 | + - to share queries (not their result, but the query itself), |
| 118 | + - share the properties defined in **Property Browser** |
| 119 | + - for santi to share is configurations |
| 120 | + |
| 121 | + |
0 commit comments