This section is a catch-all for other behind-the-scenes changes that may affect your application. Those changes include:
Fixed various focus subtleties, and simplified focus assignment code. The subtleties are for example the assignment of the focus to a child window of a composite, when the focus were to move to the composite. This is useful for mega widgets which need to force the focus on a specific child window when they get the focus.
FXDict and FXMetaClass now deploy a faster, inlined hashing function. This should translate into slightly faster application startup times.
Modified FXMALLOC(), FXCALLOC(), FXMEMDUP() and FXRESIZE() to ensure that they return NULL when the requested size is zero. This change was made because it's not the guaranteed behavior from the stock malloc(), calloc() and realloc() implementations on all systems. These macros now set the pointer to NULL and return TRUE when a zero-sized allocation is requested. If a non-zero size allocation is requested, these macros will either return TRUE or FALSE to indicate whether the operation succeeded or failed.
Changed various math functions inside FOX to be able to take advantage of single precision transcendental functions which are now part of the C99 standard math library. If the FOX library is compiled with the __USE_ISOC99 preprocessor symbol defined, these new functions, such as sinf() and sqrtf(), are assumed to be available; otherwise, identically-named macros are defined to call the older double precision versions ,such as sin() and sqrt(). The single precision functions are usually faster, possibly substantially faster for some architectures. Note that on Linux systems, the __USE_ISOC99 symbol will be defined for you if you define either _GNU_SOURCE or _ISOC99_SOURCE.
The position adjustment code for FXPopup, FXTopWindow and FXToolTip no longer assumes that the root window starts at (0, 0). This means that the root window may now extend in all directions. This change was made in support of multi-head configurations.
Previously, FOX's delayed layout algorithm was implemented as a part of the regular GUI update process. In other words, whenever a window was given the opportunity to update itself it would first check to see if its layout had been marked "dirty" (i.e. was invalid) and, if so, it would call its layout() member function to reconcile the layout.
Delayed layout is still a good thing, for reasons outlined in the FOX documentation on that topic. But on further examination, it was decided that the GUI update cycle is probably not the best place to handle this task. Since a complete GUI update cycle requires a traversal of the entire widget tree, you want to avoid doing anything that would cause the GUI update to have to start over. In the previous implementation of delayed layout, however, any action that invalidated the layout would cause the GUI update to start over. If this occurred only after the GUI update had progressed pretty "deeply" into the widget tree, it could result in a lot of extra work being done. In some pathological cases, the application would never actually complete the GUI update and would continue to eat up CPU time when it appeared otherwise idle.
To avoid the problems associated with tying layout reconciliation down to FOX's GUI update process, the deferred layout algorithm is now implemented using a simple chore. A call to recalc() does still mark a window's layout as "dirty", but it no longer resets the GUI update mechanism. Instead, the recalc() function for a top-level shell window just sets up a chore to reconcile that window's layout once, during idle time. As a result, layout changes are faster and less CPU intensive.
As a result of this change, windows no longer attempt to reconcile their layouts during GUI update. This change has some non-obvious implications for FOX application developers, especially those porting applications from FOX 1.0 to FOX 1.2. Previously, if you made a change that invalidated the GUI layout and wanted to force the application the reconcile the layout immediately, the standard solution was to call the application's forceRefresh() member function. The forceRefresh() function still causes the GUI update to be run immediately, but since layout is no longer tied into the GUI update process, this is no longer the way to force an immediate layout reconciliation. Instead, the solution is to call a window's layout() function, which forces a layout of that window and all its child windows. To force a layout of all your application's windows, use:
getApp()->getRootWindow()->layout(); |
In a related change, layout due to resizing of window has been optimized. Previously, layout occurred immediately while the user was resizing a window (such as the main window, or a dialog box). For especially complicated windows, the layout system could fall behind as the window's dimensions changed faster than the layout could be updated. In FOX 1.2, window resizing takes advantage of delayed layout techniques to postpone placement of the widgets until it has caught up with the event stream. As a result, it is no longer possible for the layout engine to fall behind, and resizing of complex GUIs on slow machines occurs much faster.