1Future posibilities
2
3  * FUTURE -- remove the directory menu popup ????
4
5  * Resource setting for the background stipple pattern of the iconbox,
6    defaulting to the normal stipple pattern, if the iconbox resource
7    is currently set to None or XtUnspecifiedPixmap.
8
9  * figure out a Print Function. (external commands) Anyone?
10
11  * Add seperate color resources for the label part within IconLabel widget.
12    Currently it uses the same color as the icons background or transparency
13    color.
14
15  * BUG -- Xpm's may show a incorrect color count due to the funny handling
16    of colors by the Xpm Library. (See Version 4.4 changes)
17
18------------------------------------------------------------------------------
19
20Version 5.1
21
22  * Imakefile modified according to suggestions from Richard Lloyd
23    <R.K.Lloyd@csc.liv.ac.uk>. This includes the default library directory
24    location BROWSERDIR.
25
26  * New RC substition variable     %D   initial startup directory
27    and the appropriate changes to the system RC files.
28    This was suggested by Michael Meissner <meissner@cygnus.com>
29
30  * Two people suggested the addition of "sys/types.h" in misc.c for
31    different machines neededing different types in "sys/stat.h"
32        Jim Spath <jspath@mail.bcpl.lib.md.us>
33        Peter Klingebiel <klin@mlap-bb.uni-paderborn.de>
34
35
36Version 5.0
37
38  * A new widget ``IconLabel'' was created to solve a number of problems
39    this program has with using the Xaw Label Widget. This new widget
40    features...
41        1/ Pixmaps displayed correctly on ALL monocrome displays.
42        2/ Shaped Windows for pixmaps with the None color
43        3/ Labels centered under the displayed bitmap or pixmap
44        4/ A info pointer for fast information lookup on icon selections
45           and menu actions, and the information line.
46
47  * Modification of the fix started in release 4.4 (see below)
48    This problem is just getting more complex as time goes on.
49
50  * Renaming of some functions and resources to better suit the programs
51    current methods and goals, which have changed to some extent.
52
53  * Ability to add and remove the Stipple Pattern in the iconbox as required
54    including the color resources involved.
55
56  * Addition of display options. Eg: labels on/off, solid background
57    and shaped windows as desired.
58
59  * Limit tests for dir_list[], so that it doesn't overflow the stack
60    and crash the program. -- Michael Weller <eowmob@exp-math.uni-essen.de>
61
62  * Addition of a menu option to hide the UNIX hidden `dot' files.
63    This option overrides the other options such as directory and others.
64    and will hide icons which are hidden! -- Should it do this?
65
66  * New menu from the main button box at the top (Main Menu).
67    For General program control, and a directory jump table.
68    This also contains a QUIT item as this menu replaces the old
69    QUIT button.
70
71  * Allow "global" menu to popup anywhere within the icon display area
72    This allows that menu to be available even on a empty display without
73    any icons or file symbols being shown.  Special thanks to Michael
74    Weller <eowmob@exp-math.uni-essen.de> who provided a fix to make this
75    work correctly.
76
77  * Add a new menu command  seleted()  which pops up a notice and aborts
78    if the action is not being performed on a selected file. This is only
79    useful in the global menu where a file may not be pointed to by the
80    user.  (DONE, but waiting for global popup of "global" menu)
81
82------------------------------------------------------------------------------
83
84Version 4.4
85
86  * Kludge Fix for the cause of XFreeColor Bug.  (long)
87
88    The cause of this problem is that the pixel we allocated for the
89    transparent `None' color is included in the returned pixels array but
90    was not allocated by the Xpixmap library (we supplied it). Thus when
91    we later free the "pixels used by the pixmap" the `None' color being
92    free'd when it should have been.
93
94    This is not a bug according to the Xpixmap librarys author...
95
96    `` This has been discussed on the list (xpm-talk) some time ago and
97       I've explained that the returned list is not the list of allocated
98       pixels but the list of *used* pixels as the documentation states
99       clearly. I've been pushed to change this and I was about to do so,
100       when I realized that the code related to the old XpmInfo stuff
101       relies on this and changing the behavior of the lib would break old
102       code. So I left the code unchanged and then to have the list of
103       allocated pixels you need to compute it yourself by removing from
104       the returned list the pixels you had allocated yourself.  '' --
105       Arnaud Le Hors <lehors@x.org>
106
107    Of course if the None color is used more than once in the xpixmap it
108    will be included in the returned pixels array more then once, and to
109    top it all off there is no real way to determine just which pixels
110    were added because they represent the `None' color or if they were
111    added because the pixmap actually really uses that color (or one very
112    close to it).
113
114    The result it difficult to determine just what colors need to be
115    free'd when we are finished with a specific pixmap. And of course you
116    only need to even bother if you use a Color Symbols table AND want to
117    free the pixmap completely later. Both of which are in themselves
118    pretty rare and thus not of real concern to Arnaud Le Hors.
119
120    The only solutions to this is either...
121      1/ Remove all occurances of the given `None' pixel value we suppled
122	 from the returned pixels array, regardless of if the color is a
123	 real color used by the pixmap.  Which of course results in the
124	 transparent pixel being allocated again and again if the pixmap
125         REALLY uses that particular color (You never free it).
126      2/ Forget using a Color Symbols table entirely and either use shaped
127	 windows or have the `None' color represented by pixel 0 which
128	 could be white or black (or some other color) depending on how
129	 your X server works. (The original problem again!)
130      3/ Get Arnaud to allocate the given pixel if it is used, however
131         many times it is needed. Of course the X server protocal does
132         provide an easy way to do this. this makes the returned pixels
133         array both the colors used by the pixmap and the colors allocated,
134         no matter what happens.
135      4/ Get Arnaud to provide some mechism to return the actual pixels
136	 returned, either in the pixels array itself or in another seperate
137         pixel array returned in the attributes structure.
138
139    Obviously the last two are out, and of the first two the first is the
140    lesser of two evilsu. What X server would make of over allocating pixels
141    is something I'll have to explore sometime.
142
143    See images.c immediately after the XpmReadPixmapFile() call for the
144    actual code to remove the transparent pixels from those returned.
145
146
147Version 4.3
148
149  WARNING: the ``icon_transparent'' color below discovered a bug in the X
150  pixmap library which causes xbmbrowser to bomb with ``XFreeColor'' X
151  server errors when changing directory.  See next release above.
152
153  * Double Clicking was found to crash the program. Seems that the second
154    click happens before the widgets have properly settled. Solution
155    is to stop double clicks via resources, and and code to insure that
156    such an event will just abort and not crash the program.
157
158  * Small Imakefile problem with linux (m4 does not remove extra spaces)
159    changed the Imakefile to avoid problem.
160
161  * Some systems required the "ctype.h" include file in "user-menu.c"
162
163  * Added a new color resource to application ``icon_transparent'' to
164    allow the setting of what color the ``None'' X pixmap tranparent color
165    should set to. Before this whatever color pixel 0 happened to be set
166    to was used for the transparent color.
167                                   Detlef Schmier <detlef@mfr.dec.com>
168
169  * added reading of the mask bitmap of read Xpixmap files. This is in
170    preperation to the next release of XbmBrowser which will replace
171    the label widget with a custom designed widget to fix labels problems
172    on some monocrome displays and to allow the display of masked pixmaps
173    in shaped windows (option) and file labels (option).
174
175  * On monocrome displays, the label widget can tell the difference between
176    a pixmap which has the colors assigned to it, and a bitmap which
177    needs to be assigned the foreground and background colors. As such
178    on some monocrome displays (such as NCDs and Linix machines) pixmaps
179    are inverted when displayed by the label widget.  :-(
180
181    I KLUDGED a fix by inverting the pixmap (1 bit depth) before using
182    the label widget on such displays. This is a temporary measure until
183    a custom widget can be created to replace this use of the label widget.
184    Thanks to everyone who told me of this long running problem
185    IT IS NOW FIXED  yes!  :-)
186
187
188Version 4.2
189
190  * Change in the loading of the file symbols due to the library function
191    XCreatePixmapFromBitmapData() inverting the symbols on displays which
192    have the black and white pixels (0 and 1) inverted (NCD xterminals).
193    See version 4.3 above for the reason for this.
194
195  * Bad load of Pixmaps (no bitmap assigned) for Text files.  Fixed.
196
197  * Bug fix for directory listings when number of sub-directories changes
198    The default columns used in widget being updated BEFORE the new list
199    had been added  -- solution and patch by   Heiko Schroeder  -- Thanks
200
201  * Addition of a Full Rescan button on the main window.
202
203  * Symlink test macro for SVR4 by John Polstra <jdp@polstra.com>
204
205
206Version 4.1
207
208  * Bug fixes and suggestions made by the current list of Beta Testers.
209
210  * Changed file symbol bitmap to pixmaps of correct depth to attempt
211    to fix a problem with xbmbrowser on Linix and other systems. This
212    also makes files symbols standout over normal bitmaps on color displays.
213
214  * Added a shorthand "-cf" option for "-config"
215
216
217Version 4.0   Changes by Anthony Thyssen
218
219  * New RC file format which allows better control of user menu actions
220
221  * Seperate user menus for major file types
222
223  * Expanded Default User Menu (assuming pbmplus is available)
224
225  * Rescursive Scan of directories option.
226    This was suggested by Steve Kinzler <kinzler@cs.indiana.edu> to
227    allow better handling of his own faces library.
228
229  * Don't recurse into sym-linked directories (show them as links instead)
230
231
232Version 3.3 (internal)   Changes by Anthony Thyssen
233
234  * Provide symbol icons to the non-displayed files and directories.
235
236  * Deletion of the Help Button and Help File to be replaced with..
237
238  * A Options Menu to interactivly turn Program options on and off.
239
240  * Resources and Command Line Options to control initial setting of
241    the options menu.
242
243
244------------------------------------------------------------------------------
245Ashley Roll releases control of XbmBrowser to Anthony Thyssen
246------------------------------------------------------------------------------
247
248Verson 3.2   Changes by  Ashley Roll and Anthony Thyssen
249
250  * Pixmaps now free their colors correctly when deleted or xbmbrowser
251    changes directory.
252
253  * Current directory text widget, move cursour to end and append '/'
254    automatically, to allow easier modification by the user.
255
256  * Color Resources added which matchs the AIcons Library Colormap.
257
258  * Now checks if the file it is trying to load is a binary file and ignores
259    it if it is. This was done because the procedures that load and create a
260    Pixmap from a file had a nasty habit of crashing when given a binary file.
261
262
263Verson 3.1   Changes by  Ashley Roll
264
265  * Minor corrections from users on the network.
266
267
268Verson 3.0   Changes by  Anthony Thyssen
269
270  * Complete rewrite of data structures and routines for reading and
271    displaying the icons from a directory.
272
273  * Addition of X Pixmaps and color
274
275  * File type enumeration (Bad, Dir, File (unknown), Xbm, Xpm, BadXpm...)
276
277  * Minor changes to get_files() in misc.c for determining file type
278    and recording the last modified time.
279
280  * Change to method used to display icon details when pointer inside
281    a displayed icon. Avoid scanning the data structure for the icons name
282    by setting the name into the widget used.
283      Their should be a way of attaching a general pointer to any widget.
284    You would think that givening a structure pointer instead of a string
285    for a widgets label would work but it doesn't. XtSetValues it seems
286    makes a new copy of any string passed to it for use by the widget.
287
288  * Made two global strings for information labels for information on the
289    number of bitmaps, pixmaps, unknown files and directories present in
290    the current directory to be displayed. Very handy.
291
292  * Removed the Scan directory completely method for a rescan changes
293    method. This method is equivelent to the original if the old file_list
294    is destroyed before it is called.
295
296
297------------------------------------------------------------------------------
298Original Coding to Version 2.3    Ashley Roll    A.Roll@cit.gu.edu.au
299
300Original Idea   Anthony Thyssen     anthony@cit.gu.edu.au
301
302
303