mirror of
https://github.com/gryf/wmaker.git
synced 2025-12-24 15:12:32 +01:00
130 lines
6.2 KiB
Plaintext
130 lines
6.2 KiB
Plaintext
|
|
*** Thu Oct 04 06:00:09 EEST 2001 -Dan
|
|
|
|
Property lists handling code
|
|
----------------------------
|
|
|
|
Code to handle property lists was added to WINGs. It is more robust
|
|
than the libPropList code, mostly because some conflicting concepts
|
|
borrowed from UserDefaults (which libPropList use) are no longer used in
|
|
the WINGs property lists code. These borrowed concepts conflicted with the
|
|
retain/release mechanism of property lists and could lead in certain cases
|
|
to segmentation faults when executing libPropList based code. But the worse
|
|
part was that these libPropList problems were practically unsolvable without
|
|
removing one of those conflicting concepts and without a complete redesign.
|
|
The new WINGs property lists code is also better integrated with the other
|
|
data types from WINGs and is actively maintained.
|
|
|
|
Practically the things that were removed from the WINGs property list
|
|
implementation compared to the old libPropList implementation, are exactly
|
|
the UserDefaults borrowed concepts that conflict with the retain/release
|
|
mechanism:
|
|
- The container of a proplist object and the associated functions are gone.
|
|
- The filename associated with a proplist object and the corresponding
|
|
functions are gone. Now the saving function needs the filename as a
|
|
parameter.
|
|
- The synchronization functions are no longer supported. They are part of
|
|
the UserDefaults and are implemented there.
|
|
- No functions related to domains/registering were implemented in the WINGs
|
|
property lists code, because they are also not part of property lists.
|
|
They are more in connection with UserDefaults and a central point of access
|
|
for domains.
|
|
|
|
The above 2 concepts: container and filename were added to libPropList just
|
|
to let it support synchronization which was borrowed from UserDefaults.
|
|
Property lists as defined in the openstep specification are just complex
|
|
data structures composed of strings, data, arrays, dictionaries and a mix of
|
|
them and are not associated with any file in particular. UserDefaults on the
|
|
other hand are property lists read from a specific file and they associate
|
|
that property list with that file and allow them to be synchronized.
|
|
|
|
Old libPropList based code can still be used by linking against the WINGs
|
|
library containing the new proplist code with minimal changes which are
|
|
described in detail in the comments at the top of the WINGs/proplist-compat.h
|
|
header file (the same file carries the #defines for mapping old libPropList
|
|
functions to the new WINGs proplist functions).
|
|
Our recommendation is to move to the new functions WINGs provide because
|
|
they better integrate with other function naming conventions in WINGs.
|
|
The proplist-compat.h header file is just a way to have old code up and
|
|
running with minimal changes so that we can remove the old and unmaintained
|
|
libPropList from systems while keeping to use old libPropList based code
|
|
without rewriting it and it should not be used for other purposes.
|
|
|
|
|
|
*** Sat Apr 21 09:12:09 EEST 2001 -Dan
|
|
|
|
API change
|
|
----------
|
|
|
|
To allow a correct display of icon images with alpha blending in panels and
|
|
other places where a WINGs based application may use them the following
|
|
changes took place:
|
|
|
|
1. The following functions were renamed:
|
|
- WMSetApplicationIconImage() --> WMSetApplicationIconPixmap()
|
|
- WMGetApplicationIconImage() --> WMGetApplicationIconPixmap()
|
|
- WMSetWindowMiniwindowImage() --> WMSetWindowMiniwindowPixmap()
|
|
2. The following functions were added:
|
|
- WMSetApplicationIconImage(WMScreen *scr, RImage *image)
|
|
- RImage* WMGetApplicationIconImage(WMScreen *scr)
|
|
- WMPixmap* WMCreateApplicationIconBlendedPixmap(WMScreen *scr, RColor *col)
|
|
|
|
As you can see the old functions that operated on WMPixmap images (which are
|
|
basically X Pixmaps that lack alpha information) were renamed to ...Pixmap()
|
|
to make them more suggestive about what they do and to make room for the
|
|
new functions that operate on RImages (that hold alpha information).
|
|
|
|
Since the corresponding WMGet... functions only retrieve the stored
|
|
image/pixmap from the application, I'll outline how the WMSet...
|
|
functions operate:
|
|
|
|
All WM...IconPixmap() functions operate on WMPixmaps
|
|
All WM...IconImage() functions operate on RImages
|
|
|
|
|
|
- WMSetApplicationIconImage() will set the RImage to be used in panels
|
|
and will also convert the RImage to a WMPixmap with a threshold of 128
|
|
and will use that pixmap for the appicon image. If that doesn't satisfy
|
|
you, you can make a call to WMSetApplicationIconPixmap() on your own to
|
|
set whatever WMPixmap you see fit for the appicon.
|
|
|
|
- WMSetApplicationIconPixmap() will set the WMPixmap to be used for the
|
|
appicon and for the panels
|
|
|
|
|
|
If you use only one of the above functions, the corresponding image/pixmap
|
|
will be used everywhere where needed (panels and appicon), but the pixmap
|
|
version will not be able to handle alpha blending correctly.
|
|
|
|
If you use both WMSetApplicationIconImage() and WMSetApplicationIconPixmap()
|
|
then the RImage will have priority in panels, and the WMPixmap will only be
|
|
used for the appicon. This allows you to better control what icon is
|
|
displayed in the appicon, in case the default conversion of the RImage to a
|
|
pixmap with a threshold of 128 is not good enough, or in case you want a
|
|
different icon to be shown in the appicon than in panels.
|
|
|
|
|
|
Also this new function was added:
|
|
|
|
- WMCreateApplicationIconBlendedPixmap() will use the RImage set with
|
|
WMSetApplicationIconImage() if available and will blend it with the color
|
|
you passed. This will make the image show well on a background of that
|
|
color. If the RImage was not set it will return NULL. You need to call
|
|
WMReleasePixmap() on it after you finish with it. Passing a NULL pointer
|
|
instead of a color will make the RImage be blended with the default color
|
|
of the WINGs widgets: '#aeaaae' making it suitable to be assigned to any
|
|
WINGs widget.
|
|
|
|
|
|
To make your existing code work as before all you need to do is to rename
|
|
the following functions:
|
|
|
|
- WMSetApplicationIconImage() --> WMSetApplicationIconPixmap()
|
|
- WMGetApplicationIconImage() --> WMGetApplicationIconPixmap()
|
|
- WMSetWindowMiniwindowImage() --> WMSetWindowMiniwindowPixmap()
|
|
|
|
But if you want to take advantage of the new abilities to show alpha
|
|
blended images you need to start using the new functions.
|
|
|
|
|