Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 350683

Summary: [SysML Block Definition Diagram] Difficult to create a port on a block as a graphical symbol.
Product: [Modeling] Papyrus Reporter: Alain Le Guennec <alain.leguennec>
Component: CoreAssignee: Yann Tanguy <yann.tanguy>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3 CC: eclipse-bugzilla, Patrick.Tessier
Version: 0.8.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on: 348530, 352550, 353507    
Bug Blocks:    
Attachments:
Description Flags
patch to fix the bug
none
Alternate patch none

Description Alain Le Guennec CLA 2011-06-29 06:58:17 EDT
It is quite hard to add a port *on the border* of a block in BDDs.
The pb is that the port creation seems to be intercepted by the block compartments, unless the port is created right on the border line of the block or on the block header.
If the compartment allows for ports (like the "properties" compartment), then unless the user clicked exactly on the border, the port will be added as a new item in the compartment and not as a new symbol on the border of the block.

It would be much easier if there was a kind of virtual margin around the border that would not be intercepted by the nested compartments.

Moreover, when the user does manage to target the border line, the port's graphical symbol is not added where the user clicked, but always on the top-left of the block rectangle. And if several ports are added, they are all put on top of each others.
Comment 1 Patrick Tessier CLA 2011-08-04 10:45:20 EDT
Created attachment 200921 [details]
patch to fix the bug

patch to fix the bug
Comment 2 Patrick Tessier CLA 2011-08-04 10:46:24 EDT
I send you a proposition to fix the bug.
Comment 3 Yann Tanguy CLA 2011-08-05 04:52:55 EDT
(In reply to comment #0)
> Moreover, when the user does manage to target the border line, the port's
> graphical symbol is not added where the user clicked, but always on the top-left
> of the block rectangle. And if several ports are added, they are all put on top
> of each others.

Addressed in Bug#352350.
Comment 4 Yann Tanguy CLA 2011-08-05 06:39:47 EDT
(In reply to comment #2)
> I send you a proposition to fix the bug.

Thanks Patrick, your patch will save me a lot of time. Just need to fix precise positioning in the related CreationEditPolicy / Locator and it should work without trouble.
Comment 5 Yann Tanguy CLA 2011-08-05 07:20:31 EDT
(In reply to comment #4)
> (In reply to comment #2)
> > I send you a proposition to fix the bug.

Problems with this solution:
- it modifies all existing diagram appearance as the stored Block size and location is related to the BorderedContainerFigure and the visible Block figure is reduced in this rectangle.
- it has a strange behavior (from a user point of view) which is that the Block is not (visually) created where and with the size given by the user (I mean the BorderContainerFigure is correct but its invisible for users).
Comment 6 Yann Tanguy CLA 2011-08-05 11:22:39 EDT
Created attachment 200996 [details]
Alternate patch

Solution trying to avoid any change in current figure location computation.
Comment 7 Yann Tanguy CLA 2011-08-05 11:31:18 EDT
(In reply to comment #2)
> I send you a proposition to fix the bug.

Patrick, maybe we can manage this issue simply by modifying figure detection in "findFigureAt()" method.
This implementation normally look for the figure in the borderItemContainerFigure first, then in the main figure, I propose (in case the previous search fails) to also look if the given position is located in a Rectangle larger than the MainFigure.

This should be enough to activate the correct edit part. Can you review and test this patch ?
Comment 8 Yann Tanguy CLA 2011-08-09 04:25:05 EDT
https://bugs.eclipse.org/bugs/attachment.cgi?id=200996 applied.
r5203 in 0.8.x
r5204 in trunk.
Comment 9 Yann Tanguy CLA 2011-08-09 13:21:39 EDT
(In reply to comment #8)
Slight modification, the selection area is dispatched on each side of the figure border (in and out). 
> r5211 in 0.8.x
> r5212 in trunk.
Comment 10 Yann Tanguy CLA 2011-08-11 09:44:43 EDT
(In reply to comment #9)
The selectable area around figure would require deeper modification to support the case were the figure in located inside a compartment, only the inside area is kept:
	r5221 in 0.8.x
	r5222 in trunk.