The V C++ GUI Framework User Guide:Platform Notes

From EDM2
Revision as of 11:15, 15 January 2017 by Ak120 (Talk | contribs)

Jump to: navigation, search

X Window System

The current X Athena implementation of V uses the Athena widget set with some modified versions of some widgets from the Xaw3d widget set. These modifications can conflict visually with the standard Xaw3d widgets, so applications may not look ideal if libXaw3d is used.

The Motif version was developed with LessTif, and you must use at least LessTif version 0.88.

Compilers

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.

The X Makefile

The Makefile is the main way to build X versions of V. It has comments that should help you to build the X version of V. See the [geninst.htm#XWindows Installation] for more instructions for installing V on a *nix platform. All of the customizations for a given platform have been isolated into one of the configruation files Config.mk in the /v/Configs directory.

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.)

X Resources

V makes limited used of X resources. The main use is to define the basic color schemes for controls and dialogs. The following resources are used:

vDialogBG
The color used for the background of dialogs and command bars.
vStatusBarBG
The color used for the background of the status bar.
vMenuBarBG
The background color of the menu bar and menu drop downs.
vControlBG
The background color for some controls, such as sliders and scroll bars.
vControlFace
The color used for the faces of various controls such as buttons.
vLightControlShadow
The color used for the light shadow on 3D controls.
vDarkControlShadow
The color used for the dark shadow on 3D controls.

By varying just the above X resources, you can really change the visual look of your V app. The /v/srcx directory contains several files of the form vRes* that contain various color schemes. The default color scheme is contained in vResDefault (but you don't need to load it - it is the default). The file vResBlueMtf contains the color scheme similar to Motif. This is the contents of vResDefault:

 *vDialogBG: gray75
 *vStatusBarBG: gray80
 *vMenuBarBG: gray70
 *vControlBG: gray80
 *vControlFace: gray70
 *vLightControlShadow: gray87
 *vDarkControlShadow: gray50
 

To 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.

X Bugs

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.

Microsoft Windows

The current implementation of V for MS-Windows is for Windows WIN32 (Windows 9x and NT). As of V 1.21, official support for Windows 3.1 has been dropped. It is unknown if V actually still works or not on 3.1. We will refer to this version as Vwin in this description. The Windows version of V is available in the standard distribution tar file on the V ftp site. You will need a version of gunzip and tar to extract V. These are available on the ObjectCentral ftp site as well.

Directories

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.

Compilers

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 [geninst.htm#MSWindows 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.

MDI/SDI Models

V for MS-Windows supports both the MS-Windows MDI and SDI models. By default, V uses MDI, and will bring up the main MDI window, and open the first MDI child window. There currently is no way to have a main MDI window with no active MDI child windows - when you exit the last window, the application closes. The menu, command bar, and status bars will change to the ones defined by each child window as each child window is activated.

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.

Icons

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.

DEF File

MS-Windows applications are typically compiled using a .DEF file. You can modify any of the .DEF files included with V sample programs.