Re: [elk-dev] ELK Refactoring

[Miro Spönemann <miro.spoenemann@xxxxxxxxx>]

On 08.01.2016, at 12:52, Christoph Daniel Schulze <cds@xxxxxxxxxxxxxxxxxxxxxx> wrote:

I finished going through the pull request. Since your pull request was

too large to be displayed by GitHub, I added my comments in the code and
pushed them to a new branch:

 http://tinyurl.com/hn8mayk

I updated and merged the PR and replied to some comments in your branch (we should rather switch back to GitHub comments, though).

All in all, things seem a lot easier now. Did you remove the
SelectionInfoAction because people are supposed to configure layout
through LayoutConfigurators now anyway where they have direct access to
all classes?

That’s one reason. Other reasons: some of the information displayed there is no longer available after the refactoring, and the feature is just for development so it should not be part of the main UI.

On 08/01/16 09:46, Miro Spönemann wrote:

Could you share the projects of the mindmap editor? Maybe not in the
repository, a zip download would be enough for me.

Sure, here you go:

 http://informatik.uni-kiel.de/~cds/mindmap.zip

The project depends on gmf.tooling.runtime, which is not in the target platform. Should we add it?

How much is there to be customized, really? I guess I would like to see
a concrete set of proposals to think about.

Potential places for customization:
— IDiagramLayoutManager
— ILayoutConfigurationStore
— LayoutConfigurationManager
— IGraphLayoutEngine
— Some parts of DiagramLayoutEngine
— LayoutPropertySource

My idea: instead of registering an IDiagramLayoutManager directly
through the extension point, you register some Setup class that is able
to create a Guice Injector. That one is cached in
the LayoutManagersService and used to create instances of the classes
mentioned above.

I'm not sure I see the benefit there, but then again I so far haven't
messed with injection much. That may be something to talk about in
person sometime.

Currently you can only adapt IDiagramLayoutManager and ILayoutConfigurationStore, where the former acts as a provider for the latter. If we later decide to add more customization points we cannot use the same provider concept because that would break existing implementations of IDiagramLayoutManager, so we would need yet another extension point. The benefit of DI is that all customized classes are registered through a Guice Module, so 

 1. we have a consistent concept for all customization points,

 2. it’s no problem to add more customization points later.

My expectation is that by making customization easier the long-term effect will be more flexibility and thus more users, since a tool is more likely to be discarded if it cannot be adapted for the needs of an application.

Miro

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail