-
Notifications
You must be signed in to change notification settings - Fork 4
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
ToolBar: use new Renderers #171
base: master
Are you sure you want to change the base?
Conversation
#167 should be applied before |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/widgets/ControlRenderer.java
Outdated
Show resolved
Hide resolved
A consequence of parameterizing |
7b2670c
to
fa8625e
Compare
it is an implementation detail of the super class
fa8625e
to
5ed1abb
Compare
@HeikoKlare Should we have delegating methods like in |
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. |
…e hints expecially in DefaultToolBarRenderer.computeSize it is not obvious whether computeLayout changes the passed Point object.
I mean: what do you prefer: Maybe related to #174. |
No description provided.