| Re: [elk-dev] ELK Refactoring |
On 11/01/16 13:41, Miro Spönemann wrote: > I updated and merged the PR and replied to some comments in your branch > (we should rather switch back to GitHub comments, though). Definitely. I expect the pull requests will become smaller from now on. ;) >> 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. True. I guess we will have to think about which UI components we contribute at some point anyway. It seems to me that quite a few users want layout to stay hidden. > The project depends on gmf.tooling.runtime, which is not in the target > platform. Should we add it? Can't hurt. I'll change the Oomph setup accordingly. > 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. Your second point seems to me to be a good reason. Cheers, Christoph Daniel
Attachment:
signature.asc
Description: OpenPGP digital signature