1
*** Mon Oct 14 19:42:42 EEST 2002 - Dan
6
To avoid flickering caused by redrawing the widgets on Expose events, a
7
double buffering tehnique was implemented for most of the widgets.
8
This flickering effect has gotten more vizible with the introduction
9
of antialiased fonts. If with normal text one can redraw the text over the
10
old one over and over again without any degradation of the text (new pixels
11
simply overwrite old pixels), with antialiased text the situation is
12
different and text gets quickly corrupted. To avoid this corruption, one
13
needs to first erase the area where the text will go, which can cause the
14
before mentioned flickering.
15
The double buffer is implemented to solve this issue.
17
This is a change that that will be automatically available for any WINGs
18
applications and will require no change in the existing code.
19
However there is an exception from this in case of WMList if you delegate
20
the drawing of items to userspace (read below for the compelte details).
23
*** Mon Oct 14 22:07:42 EEST 2002 - Dan
28
In case of WMList there is the posibility to delegate the drawing of the
29
list items to the application that is linked with WINGs, and this code will
30
not be inside the WINGs library, but in userland. Since we use the double
31
buffering tehnique in this case too (to allow all widgets based on WMList
32
and the ones that draw their list items by themselves to benefit from the
33
double buffering advantage automatically), we no longer pass the window to
34
the user code doing item drawing, but instead pass this pixmap in which we
35
draw before copying to the real window.
37
Since one cannot use XClearWindow() or XClearArea() on pixmaps, but only on
38
windows, if the code drawing list items used to call these functions to clear
39
the item area before drawing it needs to change to using XFillRectangle()
42
With this change it also means that there is no longer any need to do any
43
double buffering in the user code, since it's already done by WINGs.
46
*** Mon Oct 14 19:28:35 EEST 2002 - Dan
51
WMDrawString() and WMDrawImageString() no longer take a GC as argument.
52
Instead WMDrawString() takes a WMColor* as the color for the string to be
53
drawn, while WMDrawImageString() takes 2 WMColor* arguments in place of the
54
old GC: first for text color and second for background color.
56
This change is required to support extending WMFont to allow it to handle
57
antialiased fonts through the XFree86 Xft2 extension.
59
This also has the advantage of hiding low level X11 details and use WINGs
60
internat objects instead.
62
To fix your old code to work with the new WINGs API you need to replace the
63
GC passed to WMDraw***String() in your code with a WMColor*.
64
Most of the old code used to be like this:
66
WMDrawString(screen, window, WMColorGC(color), font, x, y, txt, len);
68
for the new API it should be replaced by:
70
WMDrawString(screen, window, color, font, x, y, txt, len);
72
However if you used a particular GC created by yourself to suit your special
73
needs, you need to pass a color which is the same as the foreground color of
76
For WMDrawImageString(), from:
78
WMDrawImageString(screen, window, gc, font, x, y, txt, len);
82
WMDrawImageString(screen, window, textColor, backColor, font, x, y, txt, len);
84
where textColor and backColor are declared like:
86
WMColor *textColor, *backColor;
88
and have the color of the foreground respective the background of the old gc.
92
*** Wed Oct 9 07:10:04 EEST 2002 - Dan
94
Antialiased font support
95
------------------------
97
With the addition of Xft2 support in the WINGs library, now WINGs can display
98
antialiased text with TrueType or any scalable fonts.
100
Antialiased text is enabled by default, but can be disabled by adding
102
AntialiasedText = NO; in ~/GNUstep/Defaults/WMGLOBAL
104
This will disable antialiased text for any WINGs based application. If you
105
only want to disable them for a specific application only, like WindowMaker
106
for example, then add the same option in the applications configuration file,
107
in this case ~/GNUstep/Defaults/WindowMaker
109
Note that bitmapped fonts look much better than TrueType when antialiasing is
113
*** Mon Sep 09 06:58:30 EEST 2002 - Dan
115
New delegate for the WMConnection class
116
---------------------------------------
118
ConnectionDelegate structure has a new member: canResumeSending.
119
The purpose of this callback is to notify you that you can resume sending
120
data over a WMConnection.
121
It works in the following manner:
123
WMSendConnectionData() can return 3 values: -1, 0, 1
125
-1 - means that the connection has died. you should stop sending data and
126
close the connection ASAP.
127
1 - means that the data was succesfully sent
128
0 - means that the data (or part of it) was not sent. however, it was saved
129
in a queue and the library will try to send it later when possible.
131
if the return value is 1, you can continue to send the next message, and so
132
on, until the return value of such a send call will be 0.
133
After it returns 0 you can continue sending, however, the data will not be
134
sent over the connection because the operating system cannot accept any more
135
data for the moment. Instead it will be queued inside the library, making your
136
program's memory footprint increase. If the ammount of data you need to
137
send is limited and not too big, this shouldn't be a problem, because your
138
data will be queued and sent when the operating system will notify the
139
library that sending is possible again.
140
If this is the case you can just ignore the output of WMSendConnectionData()
141
and not set a callback for canResumeSending.
143
However, if the ammount of data you have to send is undetermined and you
144
also want to keep a small memory footprint for your program (so that it
145
won't grow until it uses all your available memory ;) ), you will have to
146
stop sending data over the connection as soon as WMSendConnectionData()
147
returns with 0. Then you should somehow mark this situation in your program
148
to avoid it trying to send anymore data until notified that it can resume.
149
(You should have also set a canResumeSending callback when you initialized
150
your WMConnection object because else you cannot be notified when to resume.)
152
Now, when you receive such a 0 from the send operation, your last sent data
153
is put in a queue inside the library. At a later time when the operating
154
system notifies the library that sending is possible again, the library will
155
resume to send the data that is saved in the queue. After it will be able to
156
send all the data in the queue, the canResumeSending callback will be
157
called, letting you know that not only you can resume sending because the
158
operating system is again able to send data, but also that the queue was
161
From the canResumeSending callback, you should again update the status of
162
your program marking that it can send again, and then resume sending the
163
data from where you were left.
166
*** Thu Oct 04 06:00:09 EEST 2001 -Dan
168
Property lists handling code
169
----------------------------
171
Code to handle property lists was added to WINGs. It is more robust
172
than the libPropList code, mostly because some conflicting concepts
173
borrowed from UserDefaults (which libPropList use) are no longer used in
174
the WINGs property lists code. These borrowed concepts conflicted with the
175
retain/release mechanism of property lists and could lead in certain cases
176
to segmentation faults when executing libPropList based code. But the worse
177
part was that these libPropList problems were practically unsolvable without
178
removing one of those conflicting concepts and without a complete redesign.
179
The new WINGs property lists code is also better integrated with the other
180
data types from WINGs and is actively maintained.
182
Practically the things that were removed from the WINGs property list
183
implementation compared to the old libPropList implementation, are exactly
184
the UserDefaults borrowed concepts that conflict with the retain/release
186
- The container of a proplist object and the associated functions are gone.
187
- The filename associated with a proplist object and the corresponding
188
functions are gone. Now the saving function needs the filename as a
190
- The synchronization functions are no longer supported. They are part of
191
the UserDefaults and are implemented there.
192
- No functions related to domains/registering were implemented in the WINGs
193
property lists code, because they are also not part of property lists.
194
They are more in connection with UserDefaults and a central point of access
197
The above 2 concepts: container and filename were added to libPropList just
198
to let it support synchronization which was borrowed from UserDefaults.
199
Property lists as defined in the openstep specification are just complex
200
data structures composed of strings, data, arrays, dictionaries and a mix of
201
them and are not associated with any file in particular. UserDefaults on the
202
other hand are property lists read from a specific file and they associate
203
that property list with that file and allow them to be synchronized.
205
Old libPropList based code can still be used by linking against the WINGs
206
library containing the new proplist code with minimal changes which are
207
described in detail in the comments at the top of the WINGs/proplist-compat.h
208
header file (the same file carries the #defines for mapping old libPropList
209
functions to the new WINGs proplist functions).
210
Our recommendation is to move to the new functions WINGs provide because
211
they better integrate with other function naming conventions in WINGs.
212
The proplist-compat.h header file is just a way to have old code up and
213
running with minimal changes so that we can remove the old and unmaintained
214
libPropList from systems while keeping to use old libPropList based code
215
without rewriting it and it should not be used for other purposes.
218
*** Sat Apr 21 09:12:09 EEST 2001 -Dan
223
To allow a correct display of icon images with alpha blending in panels and
224
other places where a WINGs based application may use them the following
227
1. The following functions were renamed:
228
- WMSetApplicationIconImage() --> WMSetApplicationIconPixmap()
229
- WMGetApplicationIconImage() --> WMGetApplicationIconPixmap()
230
- WMSetWindowMiniwindowImage() --> WMSetWindowMiniwindowPixmap()
231
2. The following functions were added:
232
- WMSetApplicationIconImage(WMScreen *scr, RImage *image)
233
- RImage* WMGetApplicationIconImage(WMScreen *scr)
234
- WMPixmap* WMCreateApplicationIconBlendedPixmap(WMScreen *scr, RColor *col)
236
As you can see the old functions that operated on WMPixmap images (which are
237
basically X Pixmaps that lack alpha information) were renamed to ...Pixmap()
238
to make them more suggestive about what they do and to make room for the
239
new functions that operate on RImages (that hold alpha information).
241
Since the corresponding WMGet... functions only retrieve the stored
242
image/pixmap from the application, I'll outline how the WMSet...
245
All WM...IconPixmap() functions operate on WMPixmaps
246
All WM...IconImage() functions operate on RImages
249
- WMSetApplicationIconImage() will set the RImage to be used in panels
250
and will also convert the RImage to a WMPixmap with a threshold of 128
251
and will use that pixmap for the appicon image. If that doesn't satisfy
252
you, you can make a call to WMSetApplicationIconPixmap() on your own to
253
set whatever WMPixmap you see fit for the appicon.
255
- WMSetApplicationIconPixmap() will set the WMPixmap to be used for the
256
appicon and for the panels
259
If you use only one of the above functions, the corresponding image/pixmap
260
will be used everywhere where needed (panels and appicon), but the pixmap
261
version will not be able to handle alpha blending correctly.
263
If you use both WMSetApplicationIconImage() and WMSetApplicationIconPixmap()
264
then the RImage will have priority in panels, and the WMPixmap will only be
265
used for the appicon. This allows you to better control what icon is
266
displayed in the appicon, in case the default conversion of the RImage to a
267
pixmap with a threshold of 128 is not good enough, or in case you want a
268
different icon to be shown in the appicon than in panels.
271
Also this new function was added:
273
- WMCreateApplicationIconBlendedPixmap() will use the RImage set with
274
WMSetApplicationIconImage() if available and will blend it with the color
275
you passed. This will make the image show well on a background of that
276
color. If the RImage was not set it will return NULL. You need to call
277
WMReleasePixmap() on it after you finish with it. Passing a NULL pointer
278
instead of a color will make the RImage be blended with the default color
279
of the WINGs widgets: '#aeaaae' making it suitable to be assigned to any
283
To make your existing code work as before all you need to do is to rename
284
the following functions:
286
- WMSetApplicationIconImage() --> WMSetApplicationIconPixmap()
287
- WMGetApplicationIconImage() --> WMGetApplicationIconPixmap()
288
- WMSetWindowMiniwindowImage() --> WMSetWindowMiniwindowPixmap()
290
But if you want to take advantage of the new abilities to show alpha
291
blended images you need to start using the new functions.
added
removed
WINGs/NEWS
