Inconsistencies in new Container figure

[ptziegler]

This is an umbrella issue to keep track of the odd behavior that can be observed when working with the Container figure.

• Because borders are not drawn, the call to setBorder() should be ignored. Otherwise the insets of the border are still used when performing the layout, leading to "ghost" edges.

• Because the background is not drawn, the call to setOpaque() should be ignored.

Not necessarily wrong, but still weird:

• When the layout is set via the constructor, it seems weird to change it later on. Should the call to setLayoutManager() also be ignored?

[azoitl]

I found the following additional topics to be considered for ignoring:

1. Tooltip
2. Cursor
3. Getting or requesting fokus
4. Any Mouse, key, or fokus event

[azoitl]

Not necessarily wrong, but still weird:

• When the layout is set via the constructor, it seems weird to change it later on. Should the call to setLayoutManager() also be ignored?

I mainly added the layout to the constructor to save a line when using Container. In order to reuse existing setLayoutManager() infrastructure I made the setLayoutManager() final.

I think ignoring a call to setLayoutManager() would feel awkward to me.

[ptziegler]

I mainly added the layout to the constructor to save a line when using Container. In order to reuse existing setLayoutManager() infrastructure I made the setLayoutManager() final.

I think ignoring a call to setLayoutManager() would feel awkward to me.

I don't mind either way. But after looking at it again, I see the layout manager being passed as a constructor argument, which isn't done for any other figure. So I automatically assign it some special meaning, which makes it seem weird that it can easily be replaced.

[azoitl]

I mainly added the layout to the constructor to save a line when using Container. In order to reuse existing setLayoutManager() infrastructure I made the setLayoutManager() final.
I think ignoring a call to setLayoutManager() would feel awkward to me.

I don't mind either way. But after looking at it again, I see the layout manager being passed as a constructor argument, which isn't done for any other figure. So I automatically assign it some special meaning, which makes it seem weird that it can easily be replaced.

My thoughts where that a Container can only be used to layout children so using it without LayoutManager makes no sense. This is different to other figures. On the other hand one may want to change the LayoutManager based on some user action (e.g. flipping from row to column layout). Removing the container and adding a new one seems odd for this.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.