The Motif version was developed with LessTif, and you must use at least LessTif version 0.88.
The makefile provided with V uses the GNU C++ compiler, g++. V does not use templates or other C++ features that can cause portability problems. The current version has been built and tested using g++ Version 2.8 although it did work back to Version 2.6.3, but not earlier versions. There is no inherent reason that V should not compile with other C++ compilers.
V has successfully been compiled on most current X platforms available, including Linux, SunOS, Solaris, AIX, SGIs, and DEC Alphas. The standard distribution includes a Makefile that can be easily configured for these platforms. The makefile requires GNU make! The secret is to examine Config.mk and add and modify the definitions at the beginning as needed for your platform. (For Linux, this will usually be a no op, since Linux is the default configuration.) Examine the definitions already there, and then add a section with the locations defined as needed for your platform. Then use an ARCH= definition on the make line (or make your platform the default.)
*vDialogBG: gray75 *vStatusBarBG: gray80 *vMenuBarBG: gray70 *vControlBG: gray80 *vControlFace: gray70 *vLightControlShadow: gray87 *vDarkControlShadow: gray50To use one of these, or your own, resource files, you can use the command xrdb -merge vResColorscheme. You can also add the lines to your .Xresources file.
The X program name is the name you supply to the vApp constructor.
The PostScript print driver does not draw shapes with hatched brushes.
The PostScript drawing canvas does not support CopyFromMemoryDC.
Source code uses two naming conventions - .cxx and .cpp. Gnu g++ version 2.6 and later support both file extensions. G++ version 2.5 doesn't like .cpp, so you might have to rename those files to .cxx,
There seems to be problems with colors on X Pseudocolor systems.
The directory structure of V under MS-Windows is similar to the X version. On the distribution, the MS-Windows hierarchy is found under the /v directory. (We will use Unix / notation for files instead of the usual MS-Windows backslash notation. Most MS-Windows compilers handle the / correctly, and / is used throughout the V source files.) When you unzip the archive, a subdirectory /v will be built.
Under /v are /bin/win for the example V MS-Windows binaries, /draw for the VDraw example program, /examp for a simple example program, /includew/v for the V .h header files, /lib/win for the MS-Windows compiled library, /obj/win* for the object files, /srcwin for the MS-Windows version of the source code, /test for the test driver program, and /tutor for the source code to the tutorial included in this reference manual.
For MS-Windows, the V library source files use a .cpp extension. The example programs also use .cpp. The source for most of the example programs is identical for the MS-Windows and X versions! However, the source for the library .cpp and .h files are different for each platform, so you must be careful not to mix the X and MS-Windows versions of source code and header files.
V has been successfully been compiled using Borland C++ 4.5 for Win3.1 and WIN32; Borland C++ 5.02 for WIN32; Watcom 10.6 for Win3.1 and WIN32; the GNU-WIN32 gnu g++ compiler (both with Cygwin and mingw32); and Microsoft VisualC++ under several versions. See the Installation notes for more specific information about the various compilers.
Several Borland .ide files are included on the directory /vwin/bccide. The .ide files assume V is built on drive C:, so you may have to modify it if you want to build V on your own system. If you are using another compiler, then you need to compile every .cpp file found on the /srcwin directory.
Project files for compiling with Watcom C++ are included in the directory v/watcom. Unlike the Borland versions, the object code and libraries are built directly on these watcom directories.
The required changes and makefiles required for the mingw32 compiler will be made available on the Vweb site.
V will automatically append a Window menu item to the main menu. The built in Window menu supports the standard cascade and tile MDI operations, as well as showing a list of MDI children.
You can also get MS-Windows applications to look like the standard SDI model. If you want an SDI app, you control this in the static declaration of the vApp object:
static testApp* tApp = new testApp("Vtest",1);The second parameter controls MDI or SDI. A default parameter is defined by Vas 0 to indicate the MDI model. If you specify a 1, then Vwill take an SDI look. It actually does this by using the MDI code, but maximizing the canvas window, removing the extra buttons from the menu bar, and not adding the Window menu. It is impossible for the user to tell that this is really an MDI application, but Vdoes not strictly enforce this. If you create more than a single vCmdWindow object, unpredictable things will happen under the SDI simulation. It is up to you to not do that.
Since X doesn't have an MDI/SDI equivalent, it is harmless to specify SDI to an X version of your app.
As stated in the main part of this manual, V does not use resource files. This is true for the MS-Windows versions. However, there is one reason you might want to include a .RC file with a V MS-Windows application, and that is to allow you to define the icons used with the application. (These are MS-Windows icons, and are not the same things as vIcons.)
Typical MS-Windows MDI applications use two icons - one for when the whole application is iconized, and one when each child window is iconized. If you don't supply a .RC file, you will get the default MS-Windows icons. The V distribution supplies two default icons of its own, called vapp.ico and vwindow.ico. By including the definitions vAppIcon ICON vapp.ico and vWindowIcon ICON vwindow.ico in the .RC file, V will load and use those icons for the application and each child window respectively. You can substitute whatever two icons you want for your application by specifying different .ico files for the vAppIcon and vWindowIcon names in the .RC file.
MS-Windows applications are typically compiled using a .DEF file. You can modify any of the .DEF files included with V sample programs.