-
-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature proposal] Enhanced Visualizer / Virtual Views #17
Comments
Yes, why not, if it's possible. The only thing I would point out is to manage user expectations. The next thing you'll find is users asking "if only we could edit the nodes, if only we could add elements to the view" etc.... ;-) |
That's clearly possible and seem even easy. I've found this thread explaining how to create/use zest ViewFilter classes and providing some good examples of CompositeLayoutAlgorithm. Regarding the filter part, I've found how to reuse ViewPoint classes so this is achievable without code duplication. Regarding user expectations, I'm sure this will create some demands. In fact, as we can already show (and thus edit) element properties from Visualizer, I guess the first ones will be: "how can I create a view from a Visualizer output ?" and "Can we implement an auto-layout function inside views ?". FYI, one year ago I worked on a piece of software (using Prolog and GraphViz) to automagically layout archimate view only from list of relations. After some (a lot of in fact) work I achieve this kind of things: Zest is able to do the same with more flexibility (GraphViz needs a lot of work to achieve this result). In fact, all the "magic" is in combining the right layout algorithm with the right viewpoint. |
Sounds good to me, if you are able to investigate this. |
That was the idea ;-) |
Some updates on the "viewpoint filter" topic... I was able to implement it quite easily (but did only for some viewpoints) through a ViewpointZestFilter called from ZestView (see commit details but don't pay attention -yet- to tests done with LayoutAlgorithm). If you want to have a look ;-) |
OK, I see how that's working. |
I'm now working on a patch for the Visualizer to use real ArchiMate figures instead of simple label provider. I've followed these instructions and I've added a getFigure(Object element) method to the label provide. I'm using com.archimatetool.editor.diagramcreate.ArchimateDiagramModelFactory .DiagramModelArchimateObject(IArchimateElement element) to create a DiagramModelArchimateObject that can be passed to a SomethingFigure (ApplicationComponentFigure in my test) constructor. This almost works (I do see a figure on the ZestView) but I'm facing 2 issues:
I wonder if you could help me a little bit: do you know if after its creation I have some methods to call to set an "enable" state and make label appear (maybe just a setLabel() somewhere) ? Or could you point me to some source file which does this kind of thing. |
I'm not sure how those figures will work outside of that drawing context as they are linked to EditParts that dictate when the figure needs updating. The set of figures really are designed only to work well in that context. If the figure has setEnabled(false) it will show dashed outline and ligter fill color. |
Ok, so I will check EditParts code. To be honest, I was amazed to see the figure appear with only 4 lines of code (even if there's no label inside and they are disabled). I can move them as normal label providers and tooltips work ! Only limitations are those already listed and the fact that I cannot resize them, so if the label is too long it will certainly be cut. |
I've succeeded in using figures (only application layer implemented at the moment). Only remaining issues are:
Before going further, I just would like to be sure that if I succeed this patch will be accepted (together with the filters)... @Phillipus ? To help you decide, here is a screenshot: You'll note that thanks to the filter I see only applications and data, not this: |
@jbsarrodie - I think this was a really good idea. The visualizer sets this tool apart from other modelling tools. It seems the momentum behind this feature stalled. Is it still something worth considering in a future release? |
@tjsiefring A big part of underlying work (viewpoint/direction/concept filters) has been added into Archi, but you're right that using real ArchiMate figures is still not done. TBH I forgot this, maybe time to work on it again for Archi 5.0 ;-) |
Any idea on Archi 5.0 ;-) release with those features ?! |
We're working on Archi 4.7. Archi 5 is longer away. Here's the roadmap - https://www.archimatetool.com/roadmap/ |
I think the Visualizer is one Archi's features that make it different of other modelling tools. This allow navigating through model elements in a very different and more interactive way than traditional views.
To be even more effective and attractive, I think we could:
In fact, with all these enhancements, we could create a new concept: the "virtual view". A "virtual view" could be seen as a saved Visualizer context (selected object, rendering configuration). Of course the rendering would never be as good as a manually created view, but this could help managing big models.
To create these features, I've found two main examples on internet:
The text was updated successfully, but these errors were encountered: