Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Sirius » Sirius capabilities
Sirius capabilities [message #1384681] Fri, 30 May 2014 10:35 Go to next message
Ignacio Arechaga Fernandez is currently offline Ignacio Arechaga Fernandez
Messages: 14
Registered: May 2014
Location: Madrid
Junior Member
Hi all!

I am really excited about Sirius and it's capabilities! Great work!

I need to create an editor and I am doing some research in order to see if Sirius could fit in.

What I got so far is a basic model of what I am going to need and some Sirius model representations.

I will need a "main node" surrounded by (max) 4 other nodes, one of each side of the main node (represented like a square).

So far, I have a container mapping to have all the squared nodes inside.
Under the squared nodes I have each "rounded" node as another container, since I need to display some editable information about them.


Basically I need to reach some targets :


  • Change "rounded" elements from "main node" to another

    index.php/fa/18184/0/

  • Switch "rounded" elements between "main nodes"

    index.php/fa/18174/0/

  • Distinguish if an element is on the left, right, top or bottom of another element

  • Keep steady the main nodes but being able to move circle elements from one main note to another

    Basically, the square nodes need to be in the same position like in a grid.


Is this possible with the latest release? I am working with Sirius 1.0.0 RC1

Many thanks!
Ignacio
  • Attachment: switch.png
    (Size: 14.13KB, Downloaded 152 times)
  • Attachment: AtoB.png
    (Size: 15.30KB, Downloaded 136 times)

[Updated on: Mon, 02 June 2014 08:34]

Report message to a moderator

Re: Sirius capabilities [message #1384835 is a reply to message #1384681] Mon, 02 June 2014 12:42 Go to previous messageGo to next message
Maxime Porhel is currently offline Maxime Porhel
Messages: 100
Registered: July 2009
Senior Member
Le 30/05/2014 19:54, Ignacio Arechaga Fernandez a écrit :
> Hi all!
Hi Ignacio

>
> I am really excited about Sirius and it's capabilities! Great work!
thanks for your feedback!

>
> I need to create an editor and I am doing some research in order to see if Sirius could fit in.
>
> What I got so far is a basic model of what I am going to need and some Sirius model representations.
>
> I will need a "main node" surrounded by (max) 4 other nodes, one of each side of the main node (represented like a square).
>
> So far, I have a container mapping to have all the squared nodes inside.
If you did not need to display some editable information (you next
point), you could have used some bordered node mappings (corresponding
nodes would be placed on the border of your main container).

> Under the squared nodes I have each "rounded" node as another container, since I need to display some editable information about them.
Which kind of information do you need to display ? If its "fits" in the
label + style + eventually border nodes, you should look into the
bordered node solution (placement on the border). If you have to create
some List or Container with sub nodes, it is a proper solution.
>
>
> Basically I need to reach some targets :
>
>
> Change "rounded" elements from "main node" to another
Drag and drop tools could be used for that: when a "rounded" element is
dropped on an other "main node", the tool can do the semantic operation
corresponding to this move (the the model operation children of the
Begin (in RC1 it is still displayed as an Initial Operation) element of
the tool [1].
>
>
> Switch "rounded" elements between "main nodes"
You could define some tools directly in the VSM do the semantic
modification to do this: Double clic tool, a popup menu/operation
action, Selection wizard, Generic tool, ...
>
>
> Distinguish if an element is on the left, right, top or bottom of another element
There is no current element to directly get this information. But this
information could possibly be computed from a java service or you could
develop a specific Sirius or even GMF layout for your use case.


>
> Basically, the square nodes need to be in the same position like in a grid.
The pin/unpin functionality could be used: it will prevent the arrange
all to move your elements but the users will still have the capability
to move/resize it.
Another solution is to provide a set of editpolicy/layout to precisely
control these aspects
>
>
> Is this possible with the latest release? I am working with Sirius 1.0.0 RC1
>
> Many thanks!
> Ignacio
>


Regards,

Maxime

[1]
https://www.eclipse.org/sirius/doc/specifier/general/Model_Operations.html
Re: Sirius capabilities [message #1384849 is a reply to message #1384835] Mon, 02 June 2014 14:06 Go to previous messageGo to next message
Ignacio Arechaga Fernandez is currently offline Ignacio Arechaga Fernandez
Messages: 14
Registered: May 2014
Location: Madrid
Junior Member
Thank you for your reply!

Maxime Porhel wrote on Mon, 02 June 2014 14:42
Le 30/05/2014 19:54, Ignacio Arechaga Fernandez a écrit :
> Hi all!
Hi Ignacio

>
> I am really excited about Sirius and it's capabilities! Great work!
thanks for your feedback!

>
> I need to create an editor and I am doing some research in order to see if Sirius could fit in.
>
> What I got so far is a basic model of what I am going to need and some Sirius model representations.
>
> I will need a "main node" surrounded by (max) 4 other nodes, one of each side of the main node (represented like a square).
>
> So far, I have a container mapping to have all the squared nodes inside.
If you did not need to display some editable information (you next
point), you could have used some bordered node mappings (corresponding
nodes would be placed on the border of your main container).


The central squared node will be only an image, so no editable information needed here.
The information that must be editable is inside the "rounded" ones. First I've tried with the bordered node mappings but I couldn't find a proper way to have it like this.

I've checked and I can only create more bordered nodes inside a bordered node. Is this something that will change in a near future?


Quote:

> Under the squared nodes I have each "rounded" node as another container, since I need to display some editable information about them.
Which kind of information do you need to display ? If its "fits" in the
label + style + eventually border nodes, you should look into the
bordered node solution (placement on the border). If you have to create
some List or Container with sub nodes, it is a proper solution.



The information is going to be text, dates, numbers and enumerations, all of them editable.
Will the bordered node a solution in this case? Or is it better the container node mapping approach?

Quote:

>
>
> Basically I need to reach some targets :
>
>
> Change "rounded" elements from "main node" to another
Drag and drop tools could be used for that: when a "rounded" element is
dropped on an other "main node", the tool can do the semantic operation
corresponding to this move (the the model operation children of the
Begin (in RC1 it is still displayed as an Initial Operation) element of
the tool [1].



Let's say that I have a container A of B elements. B is also a container of C elements.

I have two instances of container A, let's say A1 and A2. Is it possible to move a C element from A1 to A2?

When I move a C element (with the regular mouse pointer), it gets hidden under the B element and I cannot see it around. Some scroll bars are shown in the B node. Does the drag-n-drop tool a different behaviour for this case?

Quote:

>
>
> Switch "rounded" elements between "main nodes"
You could define some tools directly in the VSM do the semantic
modification to do this: Double clic tool, a popup menu/operation
action, Selection wizard, Generic tool, ...
>
>
> Distinguish if an element is on the left, right, top or bottom of another element
There is no current element to directly get this information. But this
information could possibly be computed from a java service or you could
develop a specific Sirius or even GMF layout for your use case.


>
> Basically, the square nodes need to be in the same position like in a grid.
The pin/unpin functionality could be used: it will prevent the arrange
all to move your elements but the users will still have the capability
to move/resize it.
Another solution is to provide a set of edit policy/layout to precisely
control these aspects




My idea is to have like a huge container and display the squared nodes like a grid. Is it possible to predefine those "slots" and fill them with the squared nodes? No squared node should be able to move around. We will also have different types of users, so a edit policy must be set for this cases. I was wondering only about the element position. Any idea for doing this?

Quote:

>
>
> Is this possible with the latest release? I am working with Sirius 1.0.0 RC1
>
> Many thanks!
> Ignacio
>


Regards,

Maxime

[1]
https://www.eclipse.org/sirius/doc/specifier/general/Model_Operations.html


Best regards,
Ignacio

[Updated on: Mon, 02 June 2014 14:17]

Report message to a moderator

Re: Sirius capabilities [message #1384856 is a reply to message #1384849] Mon, 02 June 2014 14:24 Go to previous messageGo to next message
Maxime Porhel is currently offline Maxime Porhel
Messages: 100
Registered: July 2009
Senior Member
Le 02/06/2014 16:06, Ignacio Arechaga Fernandez a écrit :
> Thank you for your reply!
>
> Maxime Porhel wrote on Mon, 02 June 2014 14:42
>> Le 30/05/2014 19:54, Ignacio Arechaga Fernandez a écrit :
>> > Hi all!
>> Hi Ignacio
>>
>> >
>> > I am really excited about Sirius and it's capabilities! Great work!
>> thanks for your feedback!
>>
>> >
>> > I need to create an editor and I am doing some research in order to
>> see if Sirius could fit in.
>> >
>> > What I got so far is a basic model of what I am going to need and
>> some Sirius model representations.
>> >
>> > I will need a "main node" surrounded by (max) 4 other nodes, one of
>> each side of the main node (represented like a square).
>> >
>> > So far, I have a container mapping to have all the squared nodes
>> inside.
>> If you did not need to display some editable information (you next
>> point), you could have used some bordered node mappings (corresponding
>> nodes would be placed on the border of your main container).
>
>
> The central squared node will be only an image, so no editable
> information needed here.
> The information that must be editable is inside the "rounded" ones.
> First I've tried with the bordered node mappings but I couldn't find a
> proper way to have it like this.
Bordered node are placed on the border of their parent but their is
currently no element in the VSM to attach them to a specific side or
location.

>
> I've checked and I can only create more bordered nodes inside a bordered
> node. Is this something that will change in a near future?
There are no planned change about this.
A border node is a node mapping, it can only have bordered node children.

>
>
> Quote:
>> > Under the squared nodes I have each "rounded" node as another
>> container, since I need to display some editable information about them.
>> Which kind of information do you need to display ? If its "fits" in
>> the label + style + eventually border nodes, you should look into the
>> bordered node solution (placement on the border). If you have to
>> create some List or Container with sub nodes, it is a proper solution.
>
>
> The information is going to be text, dates and numbers, all of them
> editable.
> Will the bordered node a solution in this case? Or is it better the
> container node mapping approach?
A (bordered) node mapping will produce a Node with a label (on the
border or in the node), if all the information to display fits in a
label, note that the direct edit tool can do more than just set the name
of an element (see EcoreTools and the specific edit label on references
which enable to set the name, the cardinality, ...).

In your case, it looks like you need a List or a Container with several
children elements. Si the container mapping looks like the good approach.

>
> Quote:
>> >
>> >
>> > Basically I need to reach some targets :
>> >
>> >
>> > Change "rounded" elements from "main node" to another
>> Drag and drop tools could be used for that: when a "rounded" element
>> is dropped on an other "main node", the tool can do the semantic
>> operation corresponding to this move (the the model operation children
>> of the Begin (in RC1 it is still displayed as an Initial Operation)
>> element of the tool [1].
>
>
> Let's say that I have a container A of B elements. B is also a container
> of C elements.
>
> I have two instances of container A, let's say A1 and A2. Is it possible
> to move a C element from A1 to A2?
Yes with a drag and drop tool.

> When I move a C element (with the regular mouse pointer), it gets hidden
> under the B element and I cannot see it around. Some scroll bars are
> shown in the B node. Does the drag-n-drop tool a different behaviour for
> this case?
If there is a specified DnD tool, You will have a specific feedback when
the dragged element is "dropable" in the element under you mouse and
after the drop, the C element will be place in its new B parent.

>
> Quote:
>> >
>> >
>> > Switch "rounded" elements between "main nodes"
>> You could define some tools directly in the VSM do the semantic
>> modification to do this: Double clic tool, a popup menu/operation
>> action, Selection wizard, Generic tool, ...
>> >
>> >
>> > Distinguish if an element is on the left, right, top or bottom of
>> another element
>> There is no current element to directly get this information. But this
>> information could possibly be computed from a java service or you
>> could develop a specific Sirius or even GMF layout for your use case.
>>
>>
>> >
>> > Basically, the square nodes need to be in the same position like in
>> a grid.
>> The pin/unpin functionality could be used: it will prevent the arrange
>> all to move your elements but the users will still have the capability
>> to move/resize it.
>> Another solution is to provide a set of edit policy/layout to
>> precisely control these aspects
>
>
> My idea is to have like a huge container and display the squared nodes
> like a grid. Is it possible to predefine those "slots" and fill them
> with the squared nodes? No squared node should be able to move around.
> We will also have different types of users, so a edit policy must be set
> for this cases. I was wondering only about the element position. Any
> idea for doing this?
It seems you will have to provide a specific layout (see GMF or Sirius
layout extension points) to define this grid and place the elements on
it (eventually it would require some additonal figures and locators).

>
> Quote:
>> >
>> >
>> > Is this possible with the latest release? I am working with Sirius
>> 1.0.0 RC1
>> >
>> > Many thanks!
>> > Ignacio
>> >
>>
>>
>> Regards,
>>
>> Maxime
>>
>> [1]
>> https://www.eclipse.org/sirius/doc/specifier/general/Model_Operations.html
>>
>
>
> Best regards,
> Ignacio
>

Regards,

Maxime
Re: Sirius capabilities [message #1384987 is a reply to message #1384856] Tue, 03 June 2014 13:33 Go to previous messageGo to next message
Ignacio Arechaga Fernandez is currently offline Ignacio Arechaga Fernandez
Messages: 14
Registered: May 2014
Location: Madrid
Junior Member
Thank for your replies Maxime.

I need to have a drag and drop tool but it won't be used just inside Sirius.

I mean... I have to drag some element outside the Sirius editor and drop it into a container.
I wonder if this could be possible by adding some lower lever code to handle de conversion from one editor to Sirius.

[Updated on: Tue, 03 June 2014 13:42]

Report message to a moderator

Re: Sirius capabilities [message #1384996 is a reply to message #1384987] Tue, 03 June 2014 14:09 Go to previous message
Maxime Porhel is currently offline Maxime Porhel
Messages: 100
Registered: July 2009
Senior Member
Hi,

Le 03/06/2014 15:33, Ignacio Arechaga Fernandez a écrit :
> Thank for your replies Maxime.
>
> I need to have a drag and drop tool but I won't be used just inside Sirius.
>
> I mean... I have to drag some element outside the Sirius editor and drop
> it into a container. I wonder if this could be possible by adding some
> lower lever code to handle de conversion from one editor to Sirius.
>
See Container Drop Description in [1], you can select the "Both" or
"Model" drag sources, then you can drop elements from outside the
diagram. Then you will have to analyze the element variable (model
operation or java services) to get the semantic element to concretely
drop on the diagram.

The doc indicates its a Container tool, but drop is possible on
Containers, Nodes and Diagrams.

Regards,

Maxime

[1]
https://www.eclipse.org/sirius/doc/specifier/diagrams/Diagrams.html#container_tools
Previous Topic:Representing nodes from imported model
Next Topic:Question about incompatibilities
Goto Forum:
  


Current Time: Fri Oct 24 16:57:17 GMT 2014

Powered by FUDForum. Page generated in 0.10997 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software