mirror of
https://github.com/gryf/wmaker.git
synced 2025-12-29 09:52:29 +01:00
d4de3d0a45
- new callback in the ConnectionDelegate structure: canResumeSending - replaced setpgid() with setsid() when starting kids, to allow them to survive if wmaker (the parent) dies. - a few cleanups.
182 lines
8.8 KiB
Plaintext
182 lines
8.8 KiB
Plaintext
*** Mon Sep 09 06:58:30 EEST 2002 - Dan
|
|
|
|
New delegate for the WMConnection class
|
|
---------------------------------------
|
|
|
|
ConnectionDelegate structure has a new member: canResumeSending.
|
|
The purpose of this callback is to notify you that you can resume sending
|
|
data over a WMConnection.
|
|
It works in the following manner:
|
|
|
|
WMSendConnectionData() can return 3 values: -1, 0, 1
|
|
|
|
-1 - means that the connection has died. you should stop sending data and
|
|
close the connection ASAP.
|
|
1 - means that the data was succesfully sent
|
|
0 - means that the data (or part of it) was not sent. however, it was saved
|
|
in a queue and the library will try to send it later when possible.
|
|
|
|
if the return value is 1, you can continue to send the next message, and so
|
|
on, until the return value of such a send call will be 0.
|
|
In this case you can continue sending, however, the data will not be sent
|
|
over the connection because the operating system cannot accept any more data
|
|
for the moment. Instead it will be queued inside the library, making your
|
|
program's memory footprint increase. If the ammount of data you need to
|
|
send is limited and not too big, this shouldn't be a problem, because your
|
|
data will be queued and sent when the operating system will notify the
|
|
library that sending is possible again.
|
|
If this is the case you can just ignore the output of WMSendConnectionData()
|
|
and not set a callback for canResumeSending.
|
|
|
|
However, if the ammount of data you have to send is undetermined and you
|
|
also want to keep a small memory footprint for your program (so that it
|
|
won't grow until it uses all your available memory ;) ), you will have to
|
|
stop sending data over the connection as soon as WMSendConnectionData()
|
|
returns with 0. Then you should somehow mark this situation in your program
|
|
to avoid it trying to send anymore data until notified that it can resume.
|
|
(You should have also set a canResumeSending callback when you initialized
|
|
your WMConnection object because else you cannot be notified when to resume.)
|
|
|
|
Now, when you receive such a 0 from the send operation, your last sent data
|
|
is put in a queue inside the library. At a later time when the operating
|
|
system notifies the library that sending is possible again, the library will
|
|
resume to send the data that is saved in the queue. After it will be able to
|
|
send all the data in the queue, the canResumeSending callback will be
|
|
called, letting you know that not only you can resume sending because the
|
|
operating system is again able to send data, but also that the queue was
|
|
completely flushed.
|
|
|
|
From the canResumeSending callback, you should again update the status of
|
|
your program marking that it can send again, and then resume sending the
|
|
data from where you were left.
|
|
|
|
|
|
*** 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.
|
|
|
|
|