[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [sirius-dev] Questions for Sirius plans.
|
Le 08/10/2014 14:49, Alexander Strakh a écrit :
Hi,
Hi.
I am trying to use Sirius to create viewers for EMF models with several
similar properties.
I discovered some features, which I can't implement by sirius. This
features not specific only for my project, they can be useful for
another Sirius users and can be described as natural for diagram user
interface.
1) Possibility to paint container and bordered nodes by specifying Java
code in workspace
You can provide your own EditPart implementation with custom figure
painting using the standard GMF extension points.
As for delegating the figure painting to code Java defined in the
running workspace, to my knowledge there is no reliable way to do this.
I know that Acceleo for example had a similar need and used some dark
OSGi magic to make it work, but even that is not possible anymore in
recent versions of Eclipse due to changes in Equinox (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=419205 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=271761).
2) Possibility to calculate and determine bordered node location in case
of custom container shape. It can be implemented by specify Java code in
workspace.
While I agree it would be very nice, Sirius has lots of complex (and
subtle) logic to place the bordered nodes, and that code would very
probably break in the presence of non-rectangular shapes. If we could
find a way to do this (minus the "Java code in workspace part") with no
risk of regression, I'd be all for it, but at first glance it seems very
complex and risky.
For the "Java code in workspace" part, see my answer above.
3) Possibility to automatically changing bordered node angle after
changing placement side on container.
This is already possible with custom edit parts. You can find an example
here:
https://github.com/ObeoNetwork/UML-Designer/tree/master/plugins/org.obeonetwork.gmf.runtime.diagram.ui.extension/src/org/obeonetwork/gmf/runtime/diagram/ui/extension/rotatable
4) Possibility to specify algorithm to layout containers on pano by
external java code.
There are extension points you can use to provide your own layout
algorithms. Their documentation is not yet integrated in Sirius,
although we hope to re-integrate it into the soon to be released 2.0.0.
In the meantime you can find it at
http://docs.obeonetwork.com/obeodesigner/6.2/viewpoint/developer/general/extensions-provide_custom_arrange-all.html
(you will need to adapt the namespaces, this doc is for a version of
Sirius from before it was open sourced and renamed).
5) Possibility to specify algorythm to route connections by external
java code.
If you mean "routing" in the sense Draw2D's ConnectionRouter, to my
knowledge GMF (on which we are based) is mostly hard-coded to know only
about 3 types of routers, oblique, rectilinear and tree (see
org.eclipse.gmf.runtime.draw2d.ui.internal.figures.ConnectionLayerEx).
You can however modify programaticaly the GMF model which represents the
connections and add/remove/mode intermediate bendpoints to follow an
arbitrary path on the diagram.
6) Expand/collapse feature for containers.
You can open a feature request for this. For now it may be possible to
simulate something like this with actions to programmatically hide or
reveal the top-level children inside a container. It would not have the
same behavior as a real expand/collapse (as I understand it), but
depending on your use case it may be enough.
Does have Sirius team plans for implementing features like in list
above?
Can I send some patches to resolve features above?
You can open individual tickets in the Sirius bugzilla where we can
discuss discuss further and decide how to proceed (for example
contributions from you or sponsored work).
Regards,
--
Pierre-Charles David (Obeo) - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
