Color Views in Archi

Started by tgfranck, June 06, 2017, 10:06:11 AM

Previous topic - Next topic

Phil Beauvoir

Quote from: tgfranck on June 27, 2017, 12:11:27 PM

I pushed the plugins to which I have made changes to my github:
https://github.com/tgfranck/archifiguredelegates.

Thijs

Hi Thijs,

Your Github repo is not a cloned branch of the main Archi repo, so there's no way to see what code changes there are. Could you change it?

Phil
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tgfranck

Hi Phil,

Thank you. I changed it so my repository now contains an archi branch.

https://github.com/tgfranck/archifiguredelegates

Thijs

Jean-Baptiste Sarrodie

Hi,

That's really good work.

I have still to test it, but have one remark: you should not force the figure delegate provider to be bounded to one figure type, this should be generic and open.

It seems you're not aware of this document, it describe the target we have in mind for Archi and several topics, and what you've done is the first step regarding figures and as such should be added in Archi (after some come review of course).

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Hervé

Thank you very much Thijs  ;D

Thanks to your code, I'm now able to change the views' objects to specialize them.

tgfranck

#34
Cool, you are very welcome!

JB, thanks for the comments. You are right, the figure delegate provider can be simplified. I changed the implementation of the extension point slightly. Now, the extension point asks for a figure and a default delegate. This removes the need for a distinct delegate provider class for every figure.

I have also done some additional testing and it seems things go wrong when adding figures or figure delegates from other plugins. It seems classes from other plugins are not recognized (ClassNotFoundException).

Apparently this can be remedied by either adding the plugin as a dependency to the Archi plugin (not preferred), or by placing the plugin under the bundle-classpath. For Archi, I believe I can do so by adding the plugin to the plugins folder (correct?).

I have made an export of Archi as well as my plugin to try this out. However, it seems like Archi is not recognizing my plugin when I place the JAR in the plugins folder. In fact, Archi is not recognizing any of my plugins. I also tried a very simple plugin with a single menu contribution, which does get recognized when I put it in the plugins folder of the Archi version I downloaded from the web. Do you have any suggestions why this is happening?


I copied my modified plugins for the editor and model into my archi installation plugins folder, and now all my plugins will load. However, the ClassNotFoundException remains. As mentioned, the Figure I am trying to use is contributed by a separate plugin. I made sure that the package containing the figure is exposed. Do you have any suggestions on how to make my Figure visible to the other plugins?


!MESSAGE Cannot register Figure Delegate Provider
!STACK 0
java.lang.ClassNotFoundException: com.thijsfranck.archicolorviews.test.ColorViewLegendFigure cannot be found by com.archimatetool.editor_4.0.2.201706281434
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.archimatetool.editor.diagram.figures.factory.FigureDelegateProviderFactory.registerProviders(FigureDelegateProviderFactory.java:44)
at com.archimatetool.editor.diagram.figures.factory.FigureDelegateProviderFactory.<clinit>(FigureDelegateProviderFactory.java:29)

tgfranck

Hi everyone,

I solved my previous problem. What I needed to do was register my contributing plugin as a 'buddy' to the archi editor plugin. I added a line to the editor plugin manifest as such:


Eclipse-BuddyPolicy: registered


And another line to the plugin manifest of my plugin:


Eclipse-RegisterBuddy: com.archimatetool.editor


By adding these lines to the manifest, the Eclipse class loader is able to discover the classes in the contributing plugin, thus resolving the ClassNotFoundException. Hopefully this will help anyone facing a similar issue!

Phil Beauvoir

#36
I'm not convinced that is the solution. Usually it's a problem that packages have not been added to "Exported Package", or something else. I've never had to use the "buddy" thing.

Edit: but the editor plugin should not know anything about concrete class implementations downstream. It should only know about public Interfaces to those classes.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tgfranck

Hi all,

Hoping you can help me out with this. I am struggling to refresh my views from the code. That is to say, I want to be able to redraw the figures on my view at any time. I know that figures get re-drawn whenever a change is made to the model (e.g. selecting a different shape in the properties menu). However, I am trying to do the same without changing the model itself. I believe it should look something like this:


IObjectUIProvider provider = ObjectUIFactory.INSTANCE.getProvider(viewComponent);
provider.setInstance(viewComponent);
provider.createEditPart().refresh();


However, when I try this, nothing changes in my view. The edit part object contains (among other things) a reference to the figure that should be drawn. Do you know of any way to reference an existing figure/existing edit part? Or should I change my approach? Thank you for your help!

Best regards,
Thijs

tgfranck

Hi Phil,

I did add my packages to the exported packages, but that did not solve my problem.

The problem is occurring at the factory class for my extension point. The type of figure the provider providers delegates for, and the default delegate type are specified by the contributing plugin and loaded by name:


Class.forName(configurationElement.getAttribute("providerFor")));
Class.forName(configurationElement.getAttribute("defaultDelegate")));


Adding a buddy policy is recommended by eclipse in this situation:

https://wiki.eclipse.org/Context_Class_Loader_Enhancements#Class_forName

However, I am certainly open to other suggestions. Did you encounter this problem before and is there a simpler way to solve it?

Phil Beauvoir

When writing extension plugins in Eclipse,the host plugin (in this case, the Archi Editor plugin) should only know about downstream classes via a declared public Interface type. It should not access concrete classes.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tgfranck

Hi everyone,

Just wanted to let you know that I am still doing some work on the plugin. However, I'm currently struggling with an annoying issue. I wrote a post about it on the Eclipse forum here: https://www.eclipse.org/forums/index.php/t/1087739/

If you have any suggestions, please let me know!

Best regards,
Thijs

Phil Beauvoir

#41
Hard to say. Does it work with a simple shape? Is it the way the arrow is being drawn?

Also, I'm not sure of this:

Rectangle clientArea = owner.getClientArea();
container.setBounds(clientArea.getCopy());


should it be getBounds() ?
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tgfranck

#42
Hi Phil,

Yes it does work with a simpler shape, such as a rounded rectangle. At least in that case, using the client area as the bounds for my overlay gets me the result I want. When I use owner.getBounds() instead, my overlay is not drawn on the view at all. I think this is because the getBounds() area is too big for any child object of owner.

Before you ask why I do not just use the setBackgroundColor() method, there are two reasons:

1. We do not want to persist the color changes
2. We want to do more complex things with colors. Primarily, we want to be able to add more than one color to a shape. I have this working (rougly) for rounded rectangles. See the attached screenshot for an example. There are still some problems with it due to the current implementation (most notably the color differences due to overlap of transparent areas). I would like to use polygon shapes for this as well, when I can get the scaling issue resolved.


rheward

#43
I'm enjoying where this is going as I think the feature would be really useful.

This may be off topic, but there could be a cheap workaround for simple highlighting / full fills / font changes etc. I'd be interested in any comments.

1. Duplicate the view you want to add emphasis up.
2. Use the Search filters to find the elements of a particular Property value.
3. Select all those objects - noting that all those objects are highlighted on the new view (so long as 'Link To View' is selected).
4. Now use Edit -> Fill Colour / Font etc etc to set the selected objects accordingly. (This doesn't work, by the way, as you can't get diagram focus).

So it nearly works, apart from the obvious focus problem.