1 ** API and ABI modifications since wmaker 0.92.0
5 struct W_DragDestinationInfo: new members added SIZE CHANGE
8 WMGetTextFieldCursorPosition ADDED
9 WC_Matrix REMOVED from enum.
10 WMCreateProgressIndicator REMOVED
11 WMSetProgressIndicatorMinValue REMOVED
12 WMSetProgressIndicatorMaxValue REMOVED
13 WMSetProgressIndicatorValue REMOVED
14 WMGetProgressIndicatorMinValue REMOVED
15 WMGetProgressIndicatorMaxValue REMOVED
16 WMGetProgressIndicatorValue REMOVED
17 typedef struct W_Ruler WMRuler REMOVED
18 typedef struct WMRulerMargins REMOVED
19 WMAppendTextBlock REMOVED
20 WMAppendTextStream REMOVED
22 WMCreateTextBlockWithObject REMOVED
23 WMCreateTextBlockWithPixmap REMOVED
24 WMCreateTextBlockWithText REMOVED
25 WMCreateTextForDocumentType REMOVED
26 WMDestroyTextBlock REMOVED
27 WMFindInTextStream REMOVED
29 WMGetGrabbedRulerMargin REMOVED
30 WMGetReleasedRulerMargin REMOVED
31 WMGetRulerMargins REMOVED
32 WMGetRulerOffset REMOVED
33 WMGetTextBlockProperties REMOVED
34 WMGetTextDefaultColor REMOVED
35 WMGetTextDefaultFont REMOVED
36 WMGetTextEditable REMOVED
37 WMGetTextIgnoresNewline REMOVED
38 WMGetTextInsertType REMOVED
39 WMGetTextObjects REMOVED
40 WMGetTextRulerShown REMOVED
41 WMGetTextSelectedObjects REMOVED
42 WMGetTextSelectedStream REMOVED
43 WMGetTextSelectionColor REMOVED
44 WMGetTextSelectionFont REMOVED
45 WMGetTextSelectionUnderlined REMOVED
46 WMGetTextStream REMOVED
47 WMGetTextUsesMonoFont REMOVED
48 WMIsMarginEqualToMargin REMOVED
50 WMPrependTextBlock REMOVED
51 WMPrependTextStream REMOVED
52 WMRemoveTextBlock REMOVED
53 WMReplaceTextSelection REMOVED
55 WMSetRulerMargins REMOVED
56 WMSetRulerMoveAction REMOVED
57 WMSetRulerOffset REMOVED
58 WMSetRulerReleaseAction REMOVED
59 WMSetTextAlignment REMOVED
60 WMSetTextBackgroundColor REMOVED
61 WMSetTextBackgroundPixmap REMOVED
62 WMSetTextBlockProperties REMOVED
63 WMSetTextDefaultColor REMOVED
64 WMSetTextDefaultFont REMOVED
65 WMSetTextDelegate REMOVED
66 WMSetTextEditable REMOVED
67 WMSetTextForegroundColor REMOVED
68 WMSetTextHasHorizontalScroller REMOVED
69 WMSetTextHasRuler REMOVED
70 WMSetTextHasVerticalScroller REMOVED
71 WMSetTextIgnoresNewline REMOVED
72 WMSetTextIndentNewLines REMOVED
73 WMSetTextRelief REMOVED
74 WMSetTextSelectionColor REMOVED
75 WMSetTextSelectionFont REMOVED
76 WMSetTextSelectionUnderlined REMOVED
77 WMSetTextUsesMonoFont REMOVED
78 WMShowTextRuler REMOVED
88 enum WMConnectionState REMOVED
89 enum WMConnectionTimeoutState REMOVED
90 struct ConnectionDelegate REMOVED
93 wmessage converted from function to wrapper macro
94 wwarning converted from function to wrapper macro
95 wfatal converted from function to wrapper macro
96 wsyserror converted from function to wrapper macro
97 wsyserror REMOVED (use werror instead)
98 werror macro ADDED (replaces wsyserror)
99 wsyserrorwithcode removed
107 WMPushInArray REMOVED
108 WMWritePropListToFile NUMBER OF FUNCTION ARGUMENTS CHANGED
114 WMSetHostCacheEnabled
121 WMCreateConnectionAsServerAtAddress REMOVED
122 WMCreateConnectionToAddress REMOVED
123 WMCreateConnectionToAddressAndNotify REMOVED
124 WMCloseConnection REMOVED
125 WMDestroyConnection REMOVED
126 WMConnection* WMAcceptConnection REMOVED
127 WMGetConnectionAvailableData REMOVED
128 WMSendConnectionData REMOVED
129 WMEnqueueConnectionData REMOVED
130 WMFlushConnection REMOVED
131 WMSetConnectionDelegate REMOVED
132 WMGetConnectionService REMOVED
133 WMGetConnectionProtocol REMOVED
134 WMSetConnectionNonBlocking REMOVED
135 WMSetConnectionCloseOnExec REMOVED
136 WMSetConnectionShutdownOnClose REMOVED
137 WMGetConnectionClientData REMOVED
138 WMSetConnectionClientData REMOVED
139 WMGetConnectionFlags REMOVED
140 WMSetConnectionFlags REMOVED
141 WMGetConnectionSocket REMOVED
142 WMGetConnectionState REMOVED
143 WMGetConnectionTimeoutState REMOVED
144 WMGetConnectionUnsentData REMOVED
145 WMGetConnectionQueuedData REMOVED
146 WMSetConnectionDefaultTimeout REMOVED
147 WMSetConnectionOpenTimeout REMOVED
148 WMSetConnectionSendTimeout REMOVED
156 ----------------------------------------------------
158 *** Thu May 9 18:24:03 CEST 2013 - Christophe
160 Const-correctness API changes for WRaster, WUtils and WINGs
161 -----------------------------------------------------------
163 The 3 libraries have been modified to include appropriate 'const' qualifier
164 to the function parameters that are treated as such. This should provide
165 some hints to the compiler for better optimisation.
166 This change should have no impact on the binary interface, and will not
167 impact existing source code.
169 There is one exception however:
170 WUtil: wusergnusteppath()
171 This function now returns 'const char *' because its result must *not* be
172 modified, so it may generate a const related warning in old code.
175 *** Mon Oct 14 19:42:42 EEST 2002 - Dan
180 To avoid flickering caused by redrawing the widgets on Expose events, a
181 double buffering tehnique was implemented for most of the widgets.
182 This flickering effect has gotten more vizible with the introduction
183 of antialiased fonts. If with normal text one can redraw the text over the
184 old one over and over again without any degradation of the text (new pixels
185 simply overwrite old pixels), with antialiased text the situation is
186 different and text gets quickly corrupted. To avoid this corruption, one
187 needs to first erase the area where the text will go, which can cause the
188 before mentioned flickering.
189 The double buffer is implemented to solve this issue.
191 This is a change that that will be automatically available for any WINGs
192 applications and will require no change in the existing code.
193 However there is an exception from this in case of WMList if you delegate
194 the drawing of items to userspace (read below for the compelte details).
197 *** Mon Oct 14 22:07:42 EEST 2002 - Dan
202 In case of WMList there is the posibility to delegate the drawing of the
203 list items to the application that is linked with WINGs, and this code will
204 not be inside the WINGs library, but in userland. Since we use the double
205 buffering tehnique in this case too (to allow all widgets based on WMList
206 and the ones that draw their list items by themselves to benefit from the
207 double buffering advantage automatically), we no longer pass the window to
208 the user code doing item drawing, but instead pass this pixmap in which we
209 draw before copying to the real window.
211 Since one cannot use XClearWindow() or XClearArea() on pixmaps, but only on
212 windows, if the code drawing list items used to call these functions to clear
213 the item area before drawing it needs to change to using XFillRectangle()
216 With this change it also means that there is no longer any need to do any
217 double buffering in the user code, since it's already done by WINGs.
220 *** Mon Oct 14 19:28:35 EEST 2002 - Dan
225 WMDrawString() and WMDrawImageString() no longer take a GC as argument.
226 Instead WMDrawString() takes a WMColor* as the color for the string to be
227 drawn, while WMDrawImageString() takes 2 WMColor* arguments in place of the
228 old GC: first for text color and second for background color.
230 This change is required to support extending WMFont to allow it to handle
231 antialiased fonts through the XFree86 Xft2 extension.
233 This also has the advantage of hiding low level X11 details and use WINGs
234 internat objects instead.
236 To fix your old code to work with the new WINGs API you need to replace the
237 GC passed to WMDraw***String() in your code with a WMColor*.
238 Most of the old code used to be like this:
240 WMDrawString(screen, window, WMColorGC(color), font, x, y, txt, len);
242 for the new API it should be replaced by:
244 WMDrawString(screen, window, color, font, x, y, txt, len);
246 However if you used a particular GC created by yourself to suit your special
247 needs, you need to pass a color which is the same as the foreground color of
250 For WMDrawImageString(), from:
252 WMDrawImageString(screen, window, gc, font, x, y, txt, len);
256 WMDrawImageString(screen, window, textColor, backColor, font, x, y, txt, len);
258 where textColor and backColor are declared like:
260 WMColor *textColor, *backColor;
262 and have the color of the foreground respective the background of the old gc.
266 *** Wed Oct 9 07:10:04 EEST 2002 - Dan
268 Antialiased font support
269 ------------------------
271 With the addition of Xft2 support in the WINGs library, now WINGs can display
272 antialiased text with TrueType or any scalable fonts.
274 Antialiased text is enabled by default, but can be disabled by adding
276 AntialiasedText = NO; in ~/GNUstep/Defaults/WMGLOBAL
278 This will disable antialiased text for any WINGs based application. If you
279 only want to disable them for a specific application only, like WindowMaker
280 for example, then add the same option in the applications configuration file,
281 in this case ~/GNUstep/Defaults/WindowMaker
283 Note that bitmapped fonts look much better than TrueType when antialiasing is
287 *** Mon Sep 09 06:58:30 EEST 2002 - Dan
289 New delegate for the WMConnection class
290 ---------------------------------------
292 ConnectionDelegate structure has a new member: canResumeSending.
293 The purpose of this callback is to notify you that you can resume sending
294 data over a WMConnection.
295 It works in the following manner:
297 WMSendConnectionData() can return 3 values: -1, 0, 1
299 -1 - means that the connection has died. you should stop sending data and
300 close the connection ASAP.
301 1 - means that the data was succesfully sent
302 0 - means that the data (or part of it) was not sent. however, it was saved
303 in a queue and the library will try to send it later when possible.
305 if the return value is 1, you can continue to send the next message, and so
306 on, until the return value of such a send call will be 0.
307 After it returns 0 you can continue sending, however, the data will not be
308 sent over the connection because the operating system cannot accept any more
309 data for the moment. Instead it will be queued inside the library, making your
310 program's memory footprint increase. If the ammount of data you need to
311 send is limited and not too big, this shouldn't be a problem, because your
312 data will be queued and sent when the operating system will notify the
313 library that sending is possible again.
314 If this is the case you can just ignore the output of WMSendConnectionData()
315 and not set a callback for canResumeSending.
317 However, if the ammount of data you have to send is undetermined and you
318 also want to keep a small memory footprint for your program (so that it
319 won't grow until it uses all your available memory ;) ), you will have to
320 stop sending data over the connection as soon as WMSendConnectionData()
321 returns with 0. Then you should somehow mark this situation in your program
322 to avoid it trying to send anymore data until notified that it can resume.
323 (You should have also set a canResumeSending callback when you initialized
324 your WMConnection object because else you cannot be notified when to resume.)
326 Now, when you receive such a 0 from the send operation, your last sent data
327 is put in a queue inside the library. At a later time when the operating
328 system notifies the library that sending is possible again, the library will
329 resume to send the data that is saved in the queue. After it will be able to
330 send all the data in the queue, the canResumeSending callback will be
331 called, letting you know that not only you can resume sending because the
332 operating system is again able to send data, but also that the queue was
335 From the canResumeSending callback, you should again update the status of
336 your program marking that it can send again, and then resume sending the
337 data from where you were left.
340 *** Thu Oct 04 06:00:09 EEST 2001 -Dan
342 Property lists handling code
343 ----------------------------
345 Code to handle property lists was added to WINGs. It is more robust
346 than the libPropList code, mostly because some conflicting concepts
347 borrowed from UserDefaults (which libPropList use) are no longer used in
348 the WINGs property lists code. These borrowed concepts conflicted with the
349 retain/release mechanism of property lists and could lead in certain cases
350 to segmentation faults when executing libPropList based code. But the worse
351 part was that these libPropList problems were practically unsolvable without
352 removing one of those conflicting concepts and without a complete redesign.
353 The new WINGs property lists code is also better integrated with the other
354 data types from WINGs and is actively maintained.
356 Practically the things that were removed from the WINGs property list
357 implementation compared to the old libPropList implementation, are exactly
358 the UserDefaults borrowed concepts that conflict with the retain/release
360 - The container of a proplist object and the associated functions are gone.
361 - The filename associated with a proplist object and the corresponding
362 functions are gone. Now the saving function needs the filename as a
364 - The synchronization functions are no longer supported. They are part of
365 the UserDefaults and are implemented there.
366 - No functions related to domains/registering were implemented in the WINGs
367 property lists code, because they are also not part of property lists.
368 They are more in connection with UserDefaults and a central point of access
371 The above 2 concepts: container and filename were added to libPropList just
372 to let it support synchronization which was borrowed from UserDefaults.
373 Property lists as defined in the openstep specification are just complex
374 data structures composed of strings, data, arrays, dictionaries and a mix of
375 them and are not associated with any file in particular. UserDefaults on the
376 other hand are property lists read from a specific file and they associate
377 that property list with that file and allow them to be synchronized.
379 Old libPropList based code can still be used by linking against the WINGs
380 library containing the new proplist code with minimal changes which are
381 described in detail in the comments at the top of the WINGs/proplist-compat.h
382 header file (the same file carries the #defines for mapping old libPropList
383 functions to the new WINGs proplist functions).
384 Our recommendation is to move to the new functions WINGs provide because
385 they better integrate with other function naming conventions in WINGs.
386 The proplist-compat.h header file is just a way to have old code up and
387 running with minimal changes so that we can remove the old and unmaintained
388 libPropList from systems while keeping to use old libPropList based code
389 without rewriting it and it should not be used for other purposes.
392 *** Sat Apr 21 09:12:09 EEST 2001 -Dan
397 To allow a correct display of icon images with alpha blending in panels and
398 other places where a WINGs based application may use them the following
401 1. The following functions were renamed:
402 - WMSetApplicationIconImage() --> WMSetApplicationIconPixmap()
403 - WMGetApplicationIconImage() --> WMGetApplicationIconPixmap()
404 - WMSetWindowMiniwindowImage() --> WMSetWindowMiniwindowPixmap()
405 2. The following functions were added:
406 - WMSetApplicationIconImage(WMScreen *scr, RImage *image)
407 - RImage* WMGetApplicationIconImage(WMScreen *scr)
408 - WMPixmap* WMCreateApplicationIconBlendedPixmap(WMScreen *scr, RColor *col)
410 As you can see the old functions that operated on WMPixmap images (which are
411 basically X Pixmaps that lack alpha information) were renamed to ...Pixmap()
412 to make them more suggestive about what they do and to make room for the
413 new functions that operate on RImages (that hold alpha information).
415 Since the corresponding WMGet... functions only retrieve the stored
416 image/pixmap from the application, I'll outline how the WMSet...
419 All WM...IconPixmap() functions operate on WMPixmaps
420 All WM...IconImage() functions operate on RImages
423 - WMSetApplicationIconImage() will set the RImage to be used in panels
424 and will also convert the RImage to a WMPixmap with a threshold of 128
425 and will use that pixmap for the appicon image. If that doesn't satisfy
426 you, you can make a call to WMSetApplicationIconPixmap() on your own to
427 set whatever WMPixmap you see fit for the appicon.
429 - WMSetApplicationIconPixmap() will set the WMPixmap to be used for the
430 appicon and for the panels
433 If you use only one of the above functions, the corresponding image/pixmap
434 will be used everywhere where needed (panels and appicon), but the pixmap
435 version will not be able to handle alpha blending correctly.
437 If you use both WMSetApplicationIconImage() and WMSetApplicationIconPixmap()
438 then the RImage will have priority in panels, and the WMPixmap will only be
439 used for the appicon. This allows you to better control what icon is
440 displayed in the appicon, in case the default conversion of the RImage to a
441 pixmap with a threshold of 128 is not good enough, or in case you want a
442 different icon to be shown in the appicon than in panels.
445 Also this new function was added:
447 - WMCreateApplicationIconBlendedPixmap() will use the RImage set with
448 WMSetApplicationIconImage() if available and will blend it with the color
449 you passed. This will make the image show well on a background of that
450 color. If the RImage was not set it will return NULL. You need to call
451 WMReleasePixmap() on it after you finish with it. Passing a NULL pointer
452 instead of a color will make the RImage be blended with the default color
453 of the WINGs widgets: '#aeaaae' making it suitable to be assigned to any
457 To make your existing code work as before all you need to do is to rename
458 the following functions:
460 - WMSetApplicationIconImage() --> WMSetApplicationIconPixmap()
461 - WMGetApplicationIconImage() --> WMGetApplicationIconPixmap()
462 - WMSetWindowMiniwindowImage() --> WMSetWindowMiniwindowPixmap()
464 But if you want to take advantage of the new abilities to show alpha
465 blended images you need to start using the new functions.