ToolBar: use new Renderers

[tmssngr]

No description provided.

[github-actions]

Test Results

   341 files  ±0     341 suites  ±0   2m 46s ⏱️ +9s
 3 955 tests ±0   3 671 ✅ ±0  284 💤 ±0  0 ❌ ±0 
11 693 runs  ±0  10 808 ✅ ±0  885 💤 ±0  0 ❌ ±0 

Results for commit ea87dad. ± Comparison against base commit 9f93921.

♻️ This comment has been updated with latest results.

[tmssngr]

#167 should be applied before

[DieterMai]

The usage of "control" instead of (Tool)"bar" in unfortunate and obfuscates the meaning a bit
control.getItem(i) -> A control does not have items. What is returned?
toolbar.getItem(i) -> Obvious: the items from the toolbar

[fedejeanne]

The usage of "control" instead of (Tool)"bar" in unfortunate and obfuscates the meaning a bit control.getItem(i) -> A control does not have items. What is returned? toolbar.getItem(i) -> Obvious: the items from the toolbar

A consequence of parameterizing ControlRenderer <...>. I agree that the name of the field is now a bit "too general" but I prefer that over having each subclass declare its own field since in my experience, parameterization ends up avoiding subtle bugs.

[tmssngr]

@HeikoKlare Should we have delegating methods like in ButtonRenderer to access properties, or should they be called directly like in the ToolBarRenderer? Note, for the ButtonRenderer at least getImage() would be required.

[HeikoKlare]

I am not completely sure what you mean by "delegating methods". Are you referring to accessors? In general, I don't like direct access to fields from other classes, as you then need to take access and changes to those values into account when considering the contract of your class (in particular its invariants). So providing explicit accessors to state and what is allowed to be queried or changes is usually beneficial.

[tmssngr]

I am not completely sure what you mean by "delegating methods". Are you referring to accessors?

I mean: what do you prefer: DefaultButtonRenderer.computeDefaultSize() accessing ButtonRenderer.getText() accessing Button.getText(), or DefaultToolBarRenderer.render() accessing ToolBar.getItem() (one less indirection)?

Maybe related to #174.