OS/2 port of Eclipse is based on the code of Windows port because of similarity of their APIs. But of course, they are not identical, so there is a number of differences in the behavior of OS/2 and Windows implementations that is not covered by the Eclipse/SWT public API (which is completely identical) and can lead to various side effects. These differences are mentioned here.
| # | Windows | OS/2 | Remarks |
|---|---|---|---|
| 001 | In Windows, if a top level (frame) window is created with the
CW_USEDEFAULT constant as its size and position, it
doesn't receive the WM_SIZE message until it is shown for
the first time or explicitly resized/moved, while
GetWindowRect() (i.e. Shell.getBounds())
already reports these default size and position, but not zeros. This
has one side effect: the Shell widget receives
SWT.Resize/Move events not right after creation but only
after the first open(), setVisible() or
setBounds() call. In turn, this allows to implicitly do
the Shell layout upon the first open()
without an explicit call to layout() since the layout is
done automatically during WM_SIZE message handling. |
Although we can acquire nearly the same behavior in OS/2 by
specifying the FS_SHELLPOSITION flag during the frame
creation, the actual size/position of the window remains zero until it
is shown for the first time. This leads, for example, to the
impossibility to center the Shell widget before a call to
its open() method, which (as we think) breaks the SWT
API. So, we set the default Shell size/position (as told
us by the system through WinQueryTaskSizePos() call)
explicitly after widget creation and use FS_SHELLPOSITION
only to distinguish that the widget is being shown for the first time
and we need to do the "implicit" layout to emulate Windows behavior.
This has the side effect such as the Shell widget
receives SWT.Resize/Move events right after its creation,
not after the first open as in Windows. We don't see any reason to
emulate this thing too because it is logically more correct and either
behavior is not explicitly specified by the SWT API. |
|
| 002 | GC.drawRoundRectangle() and
GC.fillRoundRectangle() for some reason (a bug?) draw
rectangles 1 pixel narrower both in horizontal and vertical than their
nonrounded versions with the same width and height
arguments.Also rectangles with the negative width or height are drawn not with the same width and height as when these arguments are positive. |
Rounded and nonrounded rectangles are drawn with the same width
and height provided they are passed the same width and height
arguments. Rectangles of negative width/height are drawn with the same size as with positive ones. |
See also here. |
| 003 - eliminated | GC.drawFocus() draws the focus rectangle following
the rules of fillRectangle()-- width and height arguments
specify rectangle's width and height but not the position of right and
bottom borders as in drawRectangle(), although the
javadoc says that the latter is used to draw the focus on platforms
that do not support such a notion (so we get different width and
height on that platforms) |
GC.drawFocus() follows the same rules as
drawRectangle(). |
|
| 004 | Iconify / deiconify... different order of appearance of these events... | ||
| 005 | When drawing on a palette-based image using GC its
getForeground() and getBackground() methods
do not always return actual RGB color values from the image's palette
that are used to assign colors to new pixels drawn by GC
methods. Instead, they return exactly the same RGB values as they were
passed before to setForeground()/setBackground() methods.
The difference between these values takes place when an RGB value for
a color specified in the set... method is absent in the
image's palette -- in this case Windows automatically selects the
closest match (which can differ seriously) as the color, but the RGB
value stored in the GC internal data (the device context
data) is the original one (not matched) and it will be used to return
a color when the get... method is called. |
Under OS/2 also the closest match is selected from the image's
palette and used for drawing pixels when drawing on a palette-based
image. But the color returned by GC.getForeground() and
getBackground() methods always contains the actual
(matched) RGB value used for drawing. |
Example. Suppose that we have an image that doesn't have a pure
red (255, 0, 0) in its palette. We create a red Color on
a direct-color Display, a GC on this image,
then call GC.setForeground (red_color) and
GC.drawOval(). The circle is drawn not in red but in the
color closest to red in the image's palette, as expected. In Windows,
a subsequent call to GC.getForeground() will always
return a color with the (255,0,0) RGB value while in OS/2 the RGB
value will be the closest match chosen from the image's palette and
used for drawing. See also the SWT006_01 testcase. |
| 006 | Image.setBackground() doesn't work for direct color
images. |
Image.setBackground() changes the transparent pixel
on direct color images as well as on palette-based. |
|
| 007 | When the system is in 256-color mode, we can still get the image data in its original color depth and palette after the image has been loaded/created. This is true for direct color images also (this probably false for icons only, where we get data converted to 8-bit, regardless of the original). | When the system is in 256-color mode, all bitmaps are converted
and internally stored in 8-bit depth using the current palette,
regardless of their original depth and/or palette. This means it's
impossible to get back the same image data from the system as we
provided creating the bitmap (for example, when calling
Image.getImageData()) -- we always get data in the
converted form. |
This is the unchangeable behavior of OS/2 (we don't know any acceptable solution for this). Taking into account that the usage of 256-color mode is rare in our days we decided to leave things as they are for the present. |
| 008 | Potential problem with icons... (OS/2 supports only 32/16 px and 40/20 px icons...) | ||
| 009 | When the window is not visible setting its maximized state to true
will not actually resize the window to the maximum size (because
windows cannot be maximized when invisible). This leads to the number
of hidden problems such as the Shell's children having
zero size after adding them to a newly created Shell,
setting its layout and maximizing it but before calling the
Shell.open() method. |
When the window is not visible setting its maximized state to true will resize it as if it would be visible. This does not lead to any problems except that we have to keep in mint the compatibility with SWT for other platforms. | |
| 010 | When the SWT.RADIO button is selected and all other
radio buttons in the group are automatically deselected, these
deselected buttons receive the SWT.Selection event
before the selected button. |
Deselected radio buttons receive the SWT.Selection
event after the selected one receives it. |
This seems not to essential. |
[Haven't been started yet -- SWT part must be finished first]