Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix BIRT-designer, replaced XYLayout and XYLayoutEditPolicy (#1665) #1678

Merged
merged 5 commits into from
May 12, 2024

Conversation

speckyspooky
Copy link
Contributor

Fix BIRT-designer, switch from XYLayout to AbstractConstraintLayout and switch from XYLayoutEditPolicy to ConstrainedLayoutEditPolicy (#1665)

switch from XYLayoutEditPolicy to ConstrainedLayoutEditPolicy (eclipse-birt#1665)
@speckyspooky speckyspooky added the BugFix Change to correct issues label May 9, 2024
@speckyspooky speckyspooky added this to the 4.16 milestone May 9, 2024
@speckyspooky
Copy link
Contributor Author

@merks
Hi Ed,
according to the hints of ptziegler I changed the according classes and replaced the XYLayout & XYLayoutEditPolicy.
I have added the missing methods from the original classes to the child class (= missing methods).
Please take a look and let me know what your opinion is because it is abstract from my side to be so deep on the designer-ui-level.

@@ -49,7 +49,7 @@ public Object getConstraint(IFigure child) {
*/
@Override
public void layout(IFigure container) {
List children = container.getChildren();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest using List<? extends IFigure> instead, to avoid the explicit cast in line 55.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.


/**
* Constructor
*
* @param layout
*/
public TableXYLayoutEditPolicy(XYLayout layout) {
public TableXYLayoutEditPolicy(AbstractConstraintLayout layout) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the layout is not used internally, does it make sense to keep it as a constructor argument?

I also wonder if it makes sense to keep the class name, when it no longer extends the XYLayoutEditPolicy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, my first topic was to get it runable :o)
(Now we can talk about improvements.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yea, you are completely right, I removed the parameter.

@speckyspooky speckyspooky self-assigned this May 9, 2024
@merks
Copy link
Contributor

merks commented May 9, 2024

@speckyspooky

I appreciate that you are being proactive about improving the code!

@ptziegler

I appreciate very much that you as a GEF expert are helping review the changes!

(I'm traveling this week so it's harder to keep up.)

@speckyspooky speckyspooky requested a review from merks May 9, 2024 17:11
Copy link
Contributor

@merks merks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@speckyspooky

I find it difficult to review changes when there are a bunch of stacked commits. Generally it would be better, in my opinion, if you need to modify a PR's commit, that you amend it and force push it so that a PR has a single commit. I think some of the intermediate states here don't even compile and/or are not functionally complete/correct so it kind of pollutes the history with unless/misleading intermediate states.

But I don't want to hold things up with fussiness because the final changes do look correct and do appear to function well to eliminate the logged warnings.

@merks
Copy link
Contributor

merks commented May 12, 2024

It's a bit ironic that a contribution intended purely to make contribution easier (a contribution that has no impact on existing functionality neither in the code nor in the existing Oomph project setup) languishes for a week. I expect everyone is very busy with other things just like me so I do understand, but, if I were average-Jane user, I would be a little more annoyed with every passing day.

Sorry comment intended on a different issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BugFix Change to correct issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants