[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] RFC: Updating CoolBar API
|
At this point the behaviour is not to ignore the height value, but to
actually resize the item to that height as if setSize had been called.
Yes, I think ignoring the height would be okay, but then the change becomes
a breaking one (the one I suggested wasn't).
I suppose it's possible that we would support a vertical CoolBar (ack!) in
the future, and then get/setPreferredWidth would be inappropriate. Then I
presume the height argument of setPreferredWidth would be used, and the
width argument ignored? It seems like a weird API to me where one of the
arguments is always ignored, depending on the orientation of the widget.
Don't forget what "preferred size" is in this case. When you click on the
gripper for the item, it will cycle through various size changes: minimum
(showing only the gripper), preferred (which is usually just enough to show
the control), and maximum (all other items in the row are minimized). I
can't imagine a situation where the _height_ of a control might be less
than its preferred height, or furthermore how the user might go about
resizing it to its preferred height.
Pat
Steve_Northover@xxxxxxx
Sent by: To: platform-swt-dev@xxxxxxxxxxx
platform-swt-dev-admin@e cc:
clipse.org Subject: Re: [platform-swt-dev] RFC: Updating CoolBar API
17/12/2001 10:36 AM
Please respond to
platform-swt-dev
>> - mark setPreferredSize(Point), setPreferredSize(int, int), and
>> getPreferredSize() as deprecated
>> - add new API: setPreferredWidth(int), getPreferredWidth().
Is there a problem with ignoring the height value? The only reason I'm
asking is that
this value may be honoured on a future platform. Also, leaving the API
alone means
that no one will be broken and that we don't need to deprecate.
Patrick_Dubroy@xxxxxxx
Sent by: To:
platform-swt-dev-admin@eclips platform-swt-dev@xxxxxxxxxxx
e.org cc:
Subject:
[platform-swt-dev] RFC: Updating CoolBar
12/14/01 11:42 AM API
Please respond to
platform-swt-dev
The SWT team would like to propose some changes to the CoolBar and CoolItem
API, as summarized below. Any developers that might be affected by these
changes should make their concerns known as soon as possible. Please note
that two of the proposed changes are breaking changes, in that the
documented behaviour of the API will change.
Interested developers: please reply to this post with a vote of "+1" or "
-1". If you disagree with the proposed changes, please indicate why.
CoolBar
--
In the current CoolBar API, certain methods are documented to manipulate
the items with regard to the order that the items were added. The API in
question are: getItems, getItemOrder, getWrapIndices, setWrapIndices, and
setItemLayout. In the current implementation (both win32 and emulated),
only getItemOrder functions to the spec. Since "in the order the items were
added" is inconsistent with rest of the SWT API, we propose that this
behaviour be changed. This will result in two changes which are BREAKING
CHANGES to the API contract, but will make the API more consistent and
bring it in line with the rest of the SWT API.
Proposed changes:
- update javadoc for getItems, getItemOrder, getWrapIndices,
setWrapIndices, removing "in the order those items were added".
*NOTE* The following two changes are BREAKING CHANGES:
- change the item ordering behaviour in setItemLayout to match the rest of
the API, ie. the indices refer to the current position of the items, NOT
the order they were added.
- change the behaviour of getItemOrder to return { 0, 1, 2, ..., n-1 } for
a CoolBar with n items.
- the changes to setItemLayout and getItemOrder would make getItemOrder a
non-useful API. Therefore mark getItemOrder as deprecated.
CoolItem
--
The current API in CoolItem for setting what Windows refers to as "ideal
width" is setPreferredSize(int width, int height). The height argument is
illogical since there is no such thing as a "preferred height". The
current implementation will resize the control to the given height as if
setSize had been called.
Proposed changes:
- mark setPreferredSize(Point), setPreferredSize(int, int), and
getPreferredSize() as deprecated
- add new API: setPreferredWidth(int), getPreferredWidth().
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
