source: trunk/doc/diff.html@ 24

Last change on this file since 24 was 9, checked in by lpino, 18 years ago
  • Initial commit
File size: 10.2 KB
RevLine 
[9]1<?xml version="1.0" encoding="UTF-8"?>
2<?xml-stylesheet type="text/css"
3href="eclipseos2-xxe.css"
4?>
5<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
6"xhtml1-strict.dtd">
7<html>
8 <head>
9 <link href="eclipseos2.css" rel="stylesheet" type="text/css" />
10
11 <title>Eclipse for OS/2 Transitional Project Notes</title>
12 </head>
13
14 <body>
15 <h1>Known differences between Windows and OS/2 ports of Eclipse</h1>
16
17 <p>OS/2 port of Eclipse is based on the code of Windows port because of
18 similarity of their APIs. But of course, they are not identical, so there
19 is a number of differences in the behavior of OS/2 and Windows
20 implementations that is not covered by the Eclipse/SWT public API (which
21 is completely identical) and can lead to various side effects. These
22 differences are mentioned here.</p>
23
24 <h2>SWT differences</h2>
25
26 <table>
27 <thead>
28 <tr>
29 <th>#</th>
30
31 <th>Windows</th>
32
33 <th>OS/2</th>
34
35 <th>Remarks</th>
36 </tr>
37 </thead>
38
39 <tr>
40 <td>001</td>
41
42 <td>In Windows, if a top level (frame) window is created with the
43 <code>CW_USEDEFAULT</code> constant as its size and position, it
44 doesn't receive the <code>WM_SIZE</code> message until it is shown for
45 the first time or explicitly resized/moved, while
46 <code>GetWindowRect()</code> (i.e. <code>Shell.getBounds()</code>)
47 already reports these default size and position, but not zeros. This
48 has one side effect: the <code>Shell</code> widget receives
49 <code>SWT.Resize/Move</code> events not right after creation but only
50 after the first <code>open()</code>, <code>setVisible()</code> or
51 <code>setBounds()</code> call. In turn, this allows to implicitly do
52 the <code>Shell</code> layout upon the first <code>open()</code>
53 without an explicit call to <code>layout()</code> since the layout is
54 done automatically during <code>WM_SIZE</code> message handling.</td>
55
56 <td>Although we can acquire nearly the same behavior in OS/2 by
57 specifying the <code>FS_SHELLPOSITION</code> flag during the frame
58 creation, the actual size/position of the window remains zero until it
59 is shown for the first time. This leads, for example, to the
60 impossibility to center the <code>Shell</code> widget before a call to
61 its <code>open()</code> method, which (as we think) breaks the SWT
62 API. So, we set the default <code>Shell</code> size/position (as told
63 us by the system through <code>WinQueryTaskSizePos()</code> call)
64 explicitly after widget creation and use <code>FS_SHELLPOSITION</code>
65 only to distinguish that the widget is being shown for the first time
66 and we need to do the "implicit" layout to emulate Windows behavior.
67 This has the side effect such as the <code>Shell</code> widget
68 receives <code>SWT.Resize/Move</code> events right after its creation,
69 not after the first open as in Windows. We don't see any reason to
70 emulate this thing too because it is logically more correct and either
71 behavior is not explicitly specified by the SWT API.</td>
72
73 <td></td>
74 </tr>
75
76 <tr>
77 <td>002</td>
78
79 <td><code>GC.drawRoundRectangle()</code> and
80 <code>GC.fillRoundRectangle()</code> for some reason (a bug?) draw
81 rectangles 1 pixel narrower both in horizontal and vertical than their
82 nonrounded versions with the same width and height
83 arguments.<br /><br />Also rectangles with the negative width or
84 height are drawn not with the same width and height as when these
85 arguments are positive.</td>
86
87 <td>Rounded and nonrounded rectangles are drawn with the same width
88 and height provided they are passed the same width and height
89 arguments.<br /><br />Rectangles of negative width/height are drawn
90 with the same size as with positive ones.</td>
91
92 <td>See also <a href="swt003.html#GraphicPrimitives">here</a>.</td>
93 </tr>
94
95 <tr>
96 <td><a name="003">003</a> - eliminated</td>
97
98 <td><code>GC.drawFocus()</code> draws the focus rectangle following
99 the rules of <code>fillRectangle()</code>-- width and height arguments
100 specify rectangle's width and height but not the position of right and
101 bottom borders as in <code>drawRectangle()</code>, although the
102 javadoc says that the latter is used to draw the focus on platforms
103 that do not support such a notion (so we get different width and
104 height on that platforms)</td>
105
106 <td><code>GC.drawFocus()</code> follows the same rules as
107 <code>drawRectangle()</code>.</td>
108
109 <td></td>
110 </tr>
111
112 <tr>
113 <td>004</td>
114
115 <td></td>
116
117 <td>Iconify / deiconify... different order of appearance of these
118 events...</td>
119
120 <td></td>
121 </tr>
122
123 <tr>
124 <td>005</td>
125
126 <td>When drawing on a palette-based image using <code>GC</code> its
127 <code>getForeground()</code> and <code>getBackground()</code> methods
128 do not always return actual RGB color values from the image's palette
129 that are used to assign colors to new pixels drawn by <code>GC</code>
130 methods. Instead, they return exactly the same RGB values as they were
131 passed before to <code>setForeground()/setBackground()</code> methods.
132 The difference between these values takes place when an RGB value for
133 a color specified in the <code>set...</code> method is absent in the
134 image's palette -- in this case Windows automatically selects the
135 closest match (which can differ seriously) as the color, but the RGB
136 value stored in the <code>GC</code> internal data (the device context
137 data) is the original one (not matched) and it will be used to return
138 a color when the <code>get...</code> method is called.</td>
139
140 <td>Under OS/2 also the closest match is selected from the image's
141 palette and used for drawing pixels when drawing on a palette-based
142 image. But the color returned by <code>GC.getForeground()</code> and
143 <code>getBackground()</code> methods always contains the actual
144 (matched) RGB value used for drawing.</td>
145
146 <td>Example. Suppose that we have an image that doesn't have a pure
147 red (255, 0, 0) in its palette. We create a red <code>Color</code> on
148 a direct-color <code>Display</code>, a <code>GC</code> on this image,
149 then call <code>GC.setForeground (red_color)</code> and
150 <code>GC.drawOval()</code>. The circle is drawn not in red but in the
151 color closest to red in the image's palette, as expected. In Windows,
152 a subsequent call to <code>GC.getForeground()</code> will always
153 return a color with the (255,0,0) RGB value while in OS/2 the RGB
154 value will be the closest match chosen from the image's palette and
155 used for drawing. See also the <code>SWT006_01</code> testcase.</td>
156 </tr>
157
158 <tr>
159 <td>006</td>
160
161 <td><code>Image.setBackground()</code> doesn't work for direct color
162 images.</td>
163
164 <td><code>Image.setBackground()</code> changes the transparent pixel
165 on direct color images as well as on palette-based.</td>
166
167 <td></td>
168 </tr>
169
170 <tr>
171 <td><a name="007">007</a></td>
172
173 <td>When the system is in 256-color mode, we can still get the image
174 data in its original color depth and palette after the image has been
175 loaded/created. This is true for direct color images also (this
176 probably false for icons only, where we get data converted to 8-bit,
177 regardless of the original).</td>
178
179 <td>When the system is in 256-color mode, all bitmaps are converted
180 and internally stored in 8-bit depth using the current palette,
181 regardless of their original depth and/or palette. This means it's
182 impossible to get back the same image data from the system as we
183 provided creating the bitmap (for example, when calling
184 <code>Image.getImageData()</code>) -- we always get data in the
185 converted form.</td>
186
187 <td>This is the unchangeable behavior of OS/2 (we don't know any
188 acceptable solution for this). Taking into account that the usage of
189 256-color mode is rare in our days we decided to leave things as they
190 are for the present.</td>
191 </tr>
192
193 <tr>
194 <td>008</td>
195
196 <td></td>
197
198 <td>Potential problem with icons... (OS/2 supports only 32/16 px and
199 40/20 px icons...)</td>
200
201 <td></td>
202 </tr>
203
204 <tr>
205 <td>009</td>
206
207 <td>When the window is not visible setting its maximized state to true
208 will not actually resize the window to the maximum size (because
209 windows cannot be maximized when invisible). This leads to the number
210 of hidden problems such as the <code>Shell</code>'s children having
211 zero size after adding them to a newly created <code>Shell</code>,
212 setting its layout and maximizing it but before calling the
213 <code>Shell.open()</code> method.</td>
214
215 <td>When the window is not visible setting its maximized state to true
216 will resize it as if it would be visible. This does not lead to any
217 problems except that we have to keep in mint the compatibility with
218 SWT for other platforms.</td>
219
220 <td></td>
221 </tr>
222
223 <tr>
224 <td>010</td>
225
226 <td>When the <code>SWT.RADIO</code> button is selected and all other
227 radio buttons in the group are automatically deselected, these
228 deselected buttons receive the <code>SWT.Selection</code> event
229 <b>before</b> the selected button.</td>
230
231 <td>Deselected radio buttons receive the <code>SWT.Selection</code>
232 event <b>after</b> the selected one receives it.</td>
233
234 <td>This seems not to essential.</td>
235 </tr>
236 </table>
237
238 <h2>Other differences</h2>
239
240 <p>[Haven't been started yet -- SWT part must be finished first]</p>
241 </body>
242</html>
Note: See TracBrowser for help on using the repository browser.