"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "WindowMaker-0.92.0/WINGs/NEWS" of archive WindowMaker-0.92.0.tar.gz:

    1 *** Mon Oct 14 19:42:42 EEST 2002 - Dan
    2 
    3 Double buffering
    4 ----------------
    5 
    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.
   16 
   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).
   21 
   22 
   23 *** Mon Oct 14 22:07:42 EEST 2002 - Dan
   24 
   25 WMList change
   26 -------------
   27 
   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.
   36 
   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()
   40 instead.
   41 
   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.
   44 
   45 
   46 *** Mon Oct 14 19:28:35 EEST 2002 - Dan
   47 
   48 API change
   49 ----------
   50 
   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.
   55 
   56 This change is required to support extending WMFont to allow it to handle
   57 antialiased fonts through the XFree86 Xft2 extension.
   58 
   59 This also has the advantage of hiding low level X11 details and use WINGs
   60 internat objects instead.
   61 
   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:
   65 
   66 WMDrawString(screen, window, WMColorGC(color), font, x, y, txt, len);
   67 
   68 for the new API it should be replaced by:
   69 
   70 WMDrawString(screen, window, color, font, x, y, txt, len);
   71 
   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
   74 that gc.
   75 
   76 For WMDrawImageString(), from:
   77 
   78 WMDrawImageString(screen, window, gc, font, x, y, txt, len);
   79 
   80 becomes
   81 
   82 WMDrawImageString(screen, window, textColor, backColor, font, x, y, txt, len);
   83 
   84 where textColor and backColor are declared like:
   85 
   86 WMColor *textColor, *backColor;
   87 
   88 and have the color of the foreground respective the background of the old gc.
   89 
   90 
   91 
   92 *** Wed Oct  9 07:10:04 EEST 2002 - Dan
   93 
   94 Antialiased font support
   95 ------------------------
   96 
   97 With the addition of Xft2 support in the WINGs library, now WINGs can display
   98 antialiased text with TrueType or any scalable fonts.
   99 
  100 Antialiased text is enabled by default, but can be disabled by adding
  101 
  102 AntialiasedText = NO; in ~/GNUstep/Defaults/WMGLOBAL
  103 
  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
  108 
  109 Note that bitmapped fonts look much better than TrueType when antialiasing is
  110 disabled.
  111 
  112 
  113 *** Mon Sep 09 06:58:30 EEST 2002 - Dan
  114 
  115 New delegate for the WMConnection class
  116 ---------------------------------------
  117 
  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:
  122 
  123 WMSendConnectionData() can return 3 values: -1, 0, 1
  124 
  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.
  130 
  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.
  142 
  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.)
  151 
  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
  159 completely flushed.
  160 
  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.
  164 
  165 
  166 *** Thu Oct 04 06:00:09 EEST 2001 -Dan
  167 
  168 Property lists handling code
  169 ----------------------------
  170 
  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.
  181 
  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
  185 mechanism:
  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
  189   parameter.
  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
  195   for domains.
  196 
  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.
  204 
  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.
  216 
  217 
  218 *** Sat Apr 21 09:12:09 EEST 2001 -Dan
  219 
  220 API change
  221 ----------
  222 
  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
  225 changes took place:
  226 
  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)
  235 
  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).
  240 
  241 Since the corresponding WMGet... functions only retrieve the stored
  242 image/pixmap from the application, I'll outline how the WMSet...
  243 functions operate:
  244 
  245 All WM...IconPixmap() functions operate on WMPixmaps
  246 All WM...IconImage() functions operate on RImages
  247 
  248 
  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. 
  254 
  255 - WMSetApplicationIconPixmap() will set the WMPixmap to be used for the
  256     appicon and for the panels 
  257 
  258 
  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.
  262 
  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.
  269 
  270 
  271 Also this new function was added:
  272 
  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
  280     WINGs widget.
  281 
  282 
  283 To make your existing code work as before all you need to do is to rename
  284 the following functions:
  285 
  286    - WMSetApplicationIconImage()  --> WMSetApplicationIconPixmap()
  287    - WMGetApplicationIconImage()  --> WMGetApplicationIconPixmap()
  288    - WMSetWindowMiniwindowImage() --> WMSetWindowMiniwindowPixmap()
  289 
  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.
  292 
  293