New state created via CTRL+click appears offset from cursor position

[vikash1703]

When using the CTRL (Command on macOS) + click shortcut to create a new state during a transition drag in the ECC editor, the newly created state does not appear at the cursor release location. Instead, it is placed slightly offset above or below the expected position.

Steps to reproduce:

Start dragging a transition between two states

Press CTRL (Command on macOS) and click on an empty area of the canvas

Release the mouse and observe the new state position

Expected behavior:
The new state should appear exactly at the cursor click/release location.

Actual behavior:
The state appears offset from the intended cursor position.

Environment:
macOS

This behavior is reproducible across multiple attempts and may be related to coordinate or placement handling.

[azoitl]

@vikash1703 thx for reporting this problem. As this is a clear issue in our current implementation please directly create an issue from it.

[vikash1703]

Thanks for the confirmation. I’ve created a formal issue in the tracker with detailed reproduction steps. I’m unable to add labels from my side — could you please add them if appropriate?

[vikash1703]

Hi @azoitl I’ve started exploring the codebase for this issue and trying to understand where the offset behavior might be coming from. Could you please suggest which part of the code or module I should focus on for this fix? Also, I’d appreciate any guidance on what I should work on next to improve my chances for GSoC selection.

[azoitl]

As most of the work for the planned GSoC project you are interested in will happen in the org.eclipse.fordiac.ide.fbtypeeditor.ecc plugin. For the specific problem you identified the starting point will be the CreateECStateCommand class. This class is in charge of creating a state at a given position. So most probably the position given to it is wrong.

Regarding the GSOC question. What we hope for in an applicant is that they will interact with us in an open collaborative environment, i.e., create issues, provide PRs, participate in discussions. Another thing that is important that you have a rough understanding of what you will face during GSoC. So if you can already identify concrete topics to work on and put these into your proposal this would be amazing. I hope this helps.

[vikash1703]

Hi @azoitl Thanks for the guidance! I’ve started exploring the CreateECStateCommand class and tracing how the state position is calculated. I’ll try to identify the root cause and propose a fix. I’m also drafting a few concrete improvement topics for the ECC editor to include in my GSoC proposal and will share them soon for feedback.

[vikash1703]

Hi @azoitl
I have imported the 4diac IDE plugin projects into Eclipse Committer, but I’m facing an issue with breakpoints. In the original 4diac IDE, I was unable to set breakpoints on Java classes properly, even though the syntax highlighting works.

I want to run the plugin in debug mode so that I can step through the code. Could you please guide me on the correct way to launch the plugin in debug mode—should I continue using 4diac IDE or is Eclipse Committer the recommended environment for debugging?

Any guidance on setting up breakpoints and running the plugin in debug mode would be greatly appreciated.

Thank you,
Vikash

[azoitl]

Hi @vikash1703,
have you checked an followed our building and running 4diac IDE from source guideline: https://eclipse.dev/4diac/doc/development/building4diac.html

There are several important steps, like checking if all required pluings are installed, what projects to import, how to correctly set up the target platform to have the correct dependencies and how to start 4diac IDE the first time from the product file so that everything is correctly setup.

[vikash1703]

Hi @azoitl

I am trying to set up 4diac IDE from source on my MacBook Air M4 (aarch64) using Eclipse Modeling Tools. I have followed the official guide (link
) carefully, including:

Installing all required plugins

Importing all the projects into Eclipse

Trying to set the target platform from org.eclipse.fordiac.ide.product.target

However, when I try to “Set as Active Target Platform”, I get the following errors:

Internal error resolving target definition:

Profile TARGET_DEFINITION:resource:/org.eclipse.fordiac.ide/product/org.eclipse.fordiac.ide.product.target
is not current. Expected timestamp 1771389244684 but was 1771389242336.

Product defining plug-in not found when trying to synchronize the product:

The product's defining plug-in could not be found.

I have tried:

Cleaning the workspace

Re-importing the projects

Running mvn clean install -DskipTests -Dosgi.os=macosx -Dosgi.ws=cocoa -Dosgi.arch=aarch64 -Dtycho.mode=maven

But I still cannot activate the target platform.

Can you please guide me on how to fix this issue on my MacBook Air M4?

[vikash1703]

[vikash1703]

I tried but someware i am facing problem

[vikash1703]

@azoitl
I’ve tried setting up 4diac IDE, but I’m still facing issues. Could you connect on Zoom and help me with the setup?

[azoitl]

sure. could you reach out to me via e-mail.

[vikash1703]

Hi @azoitl

I have downloaded the Siemens tool and am currently exploring its features. I am checking what can be added to ECC, including different themes and color options.

Also, I have created a pull request for the documentation.

Best regards,
Vikash

[azoitl]

Not sure if Siemens is the right measure. Feel free to think of any tool that seems appropriate. E.g., Draw.net, UML state chart editors, game engine editors, ...

We are looking for the innovative ideas.

[vikash1703]

Hi @azoitl

I have made progress on the state and transition creation task within the ECC Editor. Here is the current status:

Fixed (State Offset): I successfully fixed the state placement offset. By using translateToRelative(location) in the ECCEditorEditDomain, new states are now placed accurately under the cursor instead of being shifted.

Stuck (Transition Drag): I am using the default transition creation logic, but I'm facing a visual lag. The transition line stays "stuck" or frozen during the drag phase.

Question regarding Root Cause:
Since I'm using the default transition logic, I suspect the lag is coming from the default Feedback Layer or the SplineConnection calculations which might be too heavy for rapid mouse movements on the UI thread.

Could you suggest if there is a specific class in the default ECC transition logic (like TransitionNodeEditPolicy) that I should look into to optimize this visual lag?

[vikash1703]

Hi @azoitl

I am refactoring the ECC Editor to use the same "Solid Basis" approach you implemented in PR #1986. My goal is to fix follow the PR approach

So far, I’ve updated:

Commands: CreateECStateCommand and CreateTransitionCommand (using absolute positions).

Visuals: refreshVisuals and AbsoluteBendpoint.

Since PR #1986 focused on 3 files for FB insertion, I wanted to ask:
For a complete ECC conversion, should I focus only on these areas, or are there specific ECC classes (like Transition Routers/Anchors) that also need to be converted to avoid dashed-line/offset issues?

Thanks for your guidance!

Best,
Vikash

[azoitl]

@vikash1703 please consider small PRs for any fixes. What is the smallest thing that will bring an improvement or fix. This helps us to do the code review and makes tracking changes and their impact much easier.

[vikash1703]

@azoitl,

I have studied PR #1986 as you suggested. From what I understand, you refactored the FB insertion logic to handle coordinate translation at the Tool level (using translateToRelative) rather than at the EditPart or Policy level. This provides a 'Solid Basis' by ensuring the model always receives absolute coordinates, which significantly reduces the UI lag during placement.

My question is: Should I follow the exact same process for the ECC Editor? >
Specifically, I plan to:

Move the coordinate translation to the ECCPanningSelectionTool.

Refactor CreateECStateCommand and CreateTransitionCommand to accept and store these absolute positions directly, bypassing the old toScreenPoint() logic.

Please let me know if this alignment with PR #1986 is what you are looking for in the first small PR.

[azoitl]

For me that would already be to big. Just improving the CreateECStateCommand, by for example moving the coordinate translation out of the command and providing the correct position to it would be better. It could even be a to or four stage process.

1. clean CreateECStateCommand to not have any screen specific data inside and be generic on IEC 61499 coordinates
2. correct the position in TransitionStateCreationTool
3. correct the position in ECCXYLayoutEditPolicy
4. correct the position in NewStateAction

[vikash1703]

Hi @azoitl,

As suggested, I’m planning to start with Stage 1 by cleaning the CreateECStateCommand to remove all screen-specific logic and make it generic for IEC 61499 coordinates.

I wanted to confirm with you before proceeding: would you like me to go ahead and start implementing this change as the first small PR?

Thanks for your guidance!

Best regards,
Vikash