neuron/iv

view README @ 23:91e22c4a0a0c

mingw+python+interviews works. Creating and destroying windows must be done from the gui thread. Somewhat experimental. So far Window::map is deferred to be called when the gui thread is activated, MWwindow::unmap defers the call that hides the window, and MWwindow::unbind defers the calls to RemoveProp and DestroyWindow. This is done by calling iv_bind_enqueue using a pointer and type args. Then the gui thread will call iv_bind_call with that pointer and type. .
author Michael Hines <michael.hines@yale.edu>
date Thu, 26 Feb 2015 16:01:16 -0500
parents
children
line source
1 Here is the original README for InterViews 3.1. Ignore the installation
2 instructions; to install it, see the file INSTALL instead.
4 This version of interviews has been hacked from the original
5 distribution to be portable to a few more platforms, and to use an
6 autoconfigure script. All of the imake garbage has been removed,
7 including the imake configuration files, the ivmkmf script, and other
8 related things.
10 Do not use this library for new development efforts! Use a more modern
11 one, like gtkmm or Qt or wxwindows. This library is only for legacy
12 code.
14 -------------------------------------------------------------------------------
17 README for InterViews 3.1
20 The iv subdirectory in this directory contains the InterViews 3.1
21 distribution from Stanford University and Silicon Graphics.
22 You should read the release notes in iv/src/man/refman/refman.PS
23 for information about differences between 3.0 and 3.1. You should
24 read the rest of this file for information about how to build,
25 install, and use InterViews.
27 If you have a bug report, please send it to
29 interviews-bugs@interviews.stanford.edu
31 If you have any questions or problems, please post them in the USENET
32 newsgroup
34 comp.windows.interviews
36 If you do not have access to news and you wish to be on the InterViews
37 mailing list which is gatewayed with comp.windows.interviews, send a
38 request to
40 interviews-requests@interviews.stanford.edu
42 The mailing list alias is
44 interviews@interviews.stanford.edu
46 Please post to only the newsgroup or only the mailing list but not
47 both since whatever you post in one will appear in the other too.
50 * What else to get
53 You should have gotten a C++ compiler which accepts revision 2.0 or
54 later of the language. You should have installed the X11R4 or
55 X11R5 distribution from MIT. If you use a vendor's X11 product,
56 the product should be based on R4 or later and the product
57 should include imake, makedepend, and the config files.
59 If imake and makedepend are not in the same place where the other X11
60 binaries are or anywhere else on your system, you can get the sources
61 for imake and makedepend from the X11R4 distribution at several public
62 ftp archives (such as expo.lcs.mit.edu). The X11R4 distribution also
63 contains platform-specific configuration files (*.cf) which you must
64 put in /usr/lib/X11/config or a similar place before building
65 InterViews.
68 * What to do before building InterViews
71 You should check that you have about 50Mb of free space before you
72 unpack the 3.1 tar file. If you have SunOS shared libraries, you can
73 get by with about 35Mb. The InterViews source tree itself occupies
74 only 8Mb, but saying "make World" will add 17Mb to iv and saying "make
75 install" will add another 18Mb.
77 You should read and edit iv/src/config/InterViews/local.def before
78 building InterViews. This file is the place to set parameters which
79 may need to be changed for your site. To find out which parameters
80 you can set, read params.def in the same directory.
82 For example, you might add the lines
84 #undef CCDriver
85 #define CCDriver /usr/CC/sun4/CC
86 #undef DependCCFlags
87 #define DependCCFlags $(CCDEFINES) $(CCINCLUDES) -I/usr/CC/incl
88 #undef SharedCCFlags
89 #define SharedCCFlags -PIC
91 to local.def if you use Sun C++ 2.0. Sun C++ 2.0 will not be able
92 to build libIV.so.3.0 unless you use -PIC instead of -pic.
94 You must decide whether to change the definition of InstalledRoot in
95 local.def before building InterViews since the name will be compiled
96 into InterViews applications. For example, the application "doc" will
97 expect to get its menus from /interviews/lib/all/app-defaults/Doc at
98 startup unless you set InstalledRoot to something else before building
99 InterViews.
101 Other parameters you may also have to set are where to find the X11
102 config files, includes, and libraries. If the X11 config files are
103 not in /usr/lib/X11/config, the X11 includes are not in /usr/include,
104 or the X11 libraries are not in /lib, /usr/lib, or /usr/local/lib,
105 then you should specify their actual locations in local.def. For
106 example, you might add the lines
108 #undef XConfigDir
109 #define XConfigDir /usr/X11R5/lib/X11/config
110 #undef XIncDir
111 #define XIncDir /usr/X11R5/include
112 #undef XLibDir
113 #define XLibDir /usr/X11R5/lib
115 if you are using X11R5 and it is installed in /usr/X11R5. You will
116 also have to override XCONFIGDIR when saying "make World"; see
117 below.
119 You should read the X11 platform-specific .cf file that will be used
120 when you build InterViews. It probably will set a few InterViews
121 parameters like extra compiler flags, extra defines, or extra
122 libraries so you should check that all of these extra flags work with
123 your C++ compiler as well as with your C compiler. If your C++
124 compiler will not accept some of them or it needs some additional
125 flags, you can set the affected InterViews parameters in the
126 corresponding iv-*.cf file before xparams.cf sets them. See iv-sgi.cf
127 and iv-ultrix.cf for examples. The iv-*.cf file is the only other
128 file besides local.def which you should ever need to change. (If you
129 have to change this file, please send us the changes so we can
130 incorporate them in the next release.)
133 * How to build InterViews
136 After you set any necessary parameters in local.def, you can build
137 InterViews with the following commands (but read the rest of this
138 section first!):
140 cd iv
141 setenv CPU `make CPU`
142 make World XCONFIGDIR=<actual location of X11 config files>
144 As the first command shows, you should be in the iv directory (below
145 this README) before starting to build InterViews.
147 The second command assigns the name of your machine's architecture to
148 the environment variable CPU. Saying "make CPU" by itself will print
149 the name that you should assign to CPU (MIPSEL, SUN4, etc.). If you
150 do not set CPU, the Makefiles will not be able to create the
151 appropriate subdirectories in which to put the object code files and
152 you will not be able to build InterViews.
154 The third command builds everything for you. If the X11 config files
155 are not in /usr/lib/X11/config, you must override XCONFIGDIR on the
156 command line as well as set XConfigDir in local.def or "make World"
157 will not work correctly.
159 You may want to redirect the output of "make World" to a file and
160 inspect it later since the build will take more than two hours to
161 complete on a system with the performance of a DECstation 3100 or
162 SPARCstation 1.
164 Once the build concludes, you can find errors in the output quickly by
165 searching for the character ':' (unfortunately, this will not work
166 very well if your C++ compiler driver prints verbose output showing
167 the execution of each phase).
170 * How to install InterViews
173 To install InterViews, say
175 make install
177 in the same directory where you said "make World". This command will
178 create a new subdirectory called installed and install inside this
179 directory everything that you will need to use InterViews. Since
180 "make install" will not try to install anything outside of
181 iv/installed, you can say it without having to become the superuser.
183 The only additional step you may need to take is to create a symbolic
184 link elsewhere that points at iv/installed. If you did not change the
185 definition of InstalledRoot in local.def, then this symbolic link
186 should have the name "/interviews". This link allows InterViews
187 applications to find installed data files at startup time. For
188 example, the application "doc" will not be very functional if it
189 cannot read its menus from /interviews/lib/all/app-defaults/Doc.
191 Once you finish the installation of InterViews, you will no longer
192 need iv/src (the source tree). You can say "make clean" to save disk
193 space by removing all object code files in the source tree. You can
194 even copy iv/installed to another computer and use InterViews on that
195 computer without iv/src having to be present. If you have a symbolic
196 link that points at iv/installed, your PATH can be the same on any
197 computer which contains iv/installed as long as they all have the same
198 name for the symbolic link (like /interviews).
201 * How to use InterViews
204 If /interviews is a symbolic link to iv/installed, you can start using
205 InterViews by putting the following lines in your .cshrc:
207 setenv CPU SUN4 # or MIPSEL or whatever
208 setenv MANPATH $MANPATH:/interviews/man
209 setenv PATH $PATH:/interviews/bin/$CPU
211 Once you have /interviews/bin/$CPU in your PATH, you can use the
212 InterViews script "ivmkmf" to generate Makefiles for your own
213 InterViews applications. You have to write an Imakefile first, but
214 you can do that by copying one of the Imakefiles in iv/src/bin and
215 replacing the filenames with the names of your application's source
216 files. Saying "ivmkmf" will generate a Makefile that contains the
217 appropriate -I and -L flags for using the InterViews includes and
218 libraries when building your application.
221 * How to write an Imakefile
224 The easiest way to write an Imakefile is to start with a copy of a
225 similar Imakefile and modify it. If you use only 3.1 classes, you can
226 copy alert's Imakefile. If you use both 3.1 and 2.6 classes, you can
227 copy doc's Imakefile. If you use only 2.6 classes, you can copy dclock's
228 Imakefile. If you use the Unidraw library, you can copy idraw's
229 Imakefile. Reading the config files to understand how the rules are
230 defined will also help if you need to do anything complicated.
232 Some make variables are reserved for your application's use. You can
233 compile your application with special compiler flags, defines,
234 includes, linker flags, or libraries by setting APP_CCFLAGS,
235 APP_CCDEFINES, APP_CCINCLUDES, APP_CCLDFLAGS, or APP_CCLDLIBS in your
236 Imakefile. You can make your application depend on libraries by
237 setting APP_CCDEPLIBS.
239 You can cause your application to be linked with InterViews libraries
240 bu using one and only one of the macros Use_libInterViews(),
241 Use_libUnidraw(), and Use_libgraphic(). Both libUnidraw and
242 libgraphic depend on libInterViews so saying Use_libUnidraw() or
243 Use_libgraphic() makes saying Use_libInterViews() unnecessary. You
244 cannot say both Use_libUnidraw() and Use_libgraphic() because
245 libUnidraw and libgraphic conflict with each other. All of these
246 macros also add -lXext -lX11 -lm to CCLDLIBS for you.
248 If your application uses classes from the "old" InterViews 2.6,
249 Unidraw, or graphic libraries, you should use the macro Use_2_6() as
250 well as one of the macros Use_libInterViews(), Use_libUnidraw(), or
251 Use_libgraphic(). Many 3.1 classes have the same names as 2.6 classes
252 so the shorter names are reserved for the 3.1 classes and the 2.6
253 classes' names are prefixed with "iv2_6_". The macro Use_2_6() allows
254 you to use the classes' shorter 2.6 names instead of their real names
255 and their shorter include paths (<InterViews/*.h>) instead of their
256 real include paths (<IV-2_6/InterViews/*.h>. If you want to use
257 both 3.1 and 2.6 classes in the same application, you will
258 need to omit Use_2_6() and use the 2.6 classes' real names and
259 include paths.
261 You can use the macro ComplexProgramTarget(dest) to build a program.
262 The parameter specifies the name you want the program to have after
263 it's installed. The make variable $(AOUT), which defaults to "a.out,"
264 specifies the name the program will have when it's built. The make
265 variable $(OBJS), which defaults to "*.o," specifies the list of
266 object code files which must be linked together. You don't have to
267 define either $(AOUT) or $(OBJS) in the Imakefile because the
268 generated Makefile will assign default values to them. You don't have
269 to define the list of object files in $(OBJS) because the Imakefile
270 will generate dependencies between the program and its object code
271 files of the form
273 a.out:
274 $(CC) $(OBJS)
276 a.out: a.o
277 a.out: b.o
278 a.out: c.o
280 which is equivalent to the traditional form
282 a.out: a.o b.o c.o
283 $(CC) $(OBJS)
285 You will define these dependencies automatically when you use the
286 macros MakeObjectFromSrc(file) and MakeObjectFromSrcFlags(file, flags)
287 for each source file in the program. Each source file must have its
288 own rule (hence the macro) because the implicit make rule cannot
289 compile source files which are not in the current directory. However,
290 you won't have to specify the name of the source file again in any
291 other place in the Imakefile.
293 You should surround the Imakefile with the following lines,
295 #ifdef InObjectCodeDir
296 <contents>
297 #else
298 MakeInObjectCodeDir()
299 #endif
301 so that saying "make Makefiles" will create a subdirectory in which to
302 put the object code files. You do not have to use these lines, but if
303 you do not you will not be able to build optimized, debuggable, and
304 non-shared object code files alongside of each other in separate
305 subdirectories. You also will not be able to build object code files
306 for different machine architectures alongside of each other in
307 separate subdirectories. On the SPARCstation, such object code
308 directories will have the names SUN4, SUN4.debug, and SUN4.noshared
309 (the latter two will be created only if you use a special make
310 command, see below).
312 After you finish writing your Imakefile, saying "ivmkmf" will generate
313 the corresponding Makefile. Then you can say "make Makefiles; make
314 depend; make all" to build your program. If you make a new change to
315 the Imakefile, all you have to do is to say "make Makefile"---you
316 don't have to use "ivmkmf" again.
318 Saying "make Makefiles.debug" and/or "make Makefiles.noshared" will
319 create the special object code subdirectories and saying "make
320 depend.debug", "make depend.noshared", "make all.debug", or "make
321 all.noshared" will build in them just like the normal subdirectories.
322 Note that the Makefile will provide the "make *.noshared" targets only
323 if you're on a computer which has shared libraries (currently we
324 support only SunOS shared libraries).
326 If you write a Makefile by hand instead of writing an Imakefile,
327 you'll have to specify everything that make needs to know. For
328 example, you'll have to specify the -I and -L flags needed to use the
329 InterViews includes and libraries when compiling your application.
330 You'll also have to specify any extra flags that your system may need
331 even though you may have to change them when building on a different
332 system (when you use an Imakefile, the platform-specific X11 .cf file
333 specifies these flags for you so they don't have to be in the
334 Imakefile).