Remove obsolete symbols from overviews and install notes

Don't mention Windows 95, OS/2 and SGI.

Closes https://github.com/wxWidgets/wxWidgets/pull/135
This commit is contained in:
Catalin 2015-11-28 23:46:07 +02:00 committed by Vadim Zeitlin
parent 4e49638a6c
commit 2c84f37054
9 changed files with 4 additions and 419 deletions

View File

@ -164,7 +164,7 @@ the border.
If you don't specify a border style for a wxTextCtrl in rich edit mode, If you don't specify a border style for a wxTextCtrl in rich edit mode,
wxWidgets now gives the control themed borders automatically, where previously wxWidgets now gives the control themed borders automatically, where previously
they would take the Windows 95-style sunken border. Other native controls such they would take the sunken border style. Other native controls such
as wxTextCtrl in non-rich edit mode, and wxComboBox already paint themed as wxTextCtrl in non-rich edit mode, and wxComboBox already paint themed
borders where appropriate. To use themed borders on other windows, such as borders where appropriate. To use themed borders on other windows, such as
wxPanel, pass the @c wxBORDER_THEME style, or (apart from wxPanel) pass no wxPanel, pass the @c wxBORDER_THEME style, or (apart from wxPanel) pass no

View File

@ -28,9 +28,7 @@ wxFontEnumerator and wxFontMapper. wxFont encoding support is reflected by a
@beginDefList @beginDefList
@itemdef{wxFONTENCODING_SYSTEM, @itemdef{wxFONTENCODING_SYSTEM,
The default encoding of the underlying The default encoding of the underlying operating system.}
operating system (notice that this might be a "foreign" encoding for foreign
versions of Windows 9x/NT).}
@itemdef{wxFONTENCODING_DEFAULT, @itemdef{wxFONTENCODING_DEFAULT,
The applications default encoding as returned by wxFont::GetDefaultEncoding. The applications default encoding as returned by wxFont::GetDefaultEncoding.
On program startup, the applications default encoding is the same as On program startup, the applications default encoding is the same as

View File

@ -32,23 +32,6 @@ The following is a summary of the toolbar classes and their differences:
@li wxToolBarBase: This is a base class with pure virtual functions, and should @li wxToolBarBase: This is a base class with pure virtual functions, and should
not be used directly. not be used directly.
@li wxToolBarSimple: A simple toolbar class written entirely with generic
wxWidgets functionality. A simple 3D effect for buttons is possible, but it
is not consistent with the Windows look and feel. This toolbar can scroll,
and you can have arbitrary numbers of rows and columns.
@li wxToolBarMSW: This class implements an old-style Windows toolbar, only on
Windows. There are small, three-dimensional buttons, which do not
(currently) reflect the current Windows colour settings: the buttons are
grey. This is the default wxToolBar on 16-bit windows.
@li wxToolBar95: Uses the native Windows 95 toolbar class. It dynamically
adjusts it's background and button colours according to user colour
settings. CreateTools must be called after the tools have been added. No
absolute positioning is supported but you can specify the number of rows,
and add tool separators with @c AddSeparator. Tooltips are supported.
@c OnRightClick is not supported. This is the default wxToolBar on Windows
95, Windows NT 4 and above. With the style wxTB_FLAT, the flat toolbar look
is used, with a border that is highlighted when the cursor moves over the
buttons.
A toolbar might appear as a single row of images under the menubar, or it might A toolbar might appear as a single row of images under the menubar, or it might
be in a separate frame layout in several rows and columns. The class handles be in a separate frame layout in several rows and columns. The class handles
@ -71,11 +54,7 @@ give it.
@section overview_toolbar_library Using the Toolbar Library @section overview_toolbar_library Using the Toolbar Library
Include @c "wx/toolbar.h", or if using a class directly, one of: Include @c "wx/toolbar.h"
- @c "wx/msw/tbarmsw.h" for wxToolBarMSW
- @c "wx/msw/tbar95.h" for wxToolBar95
- @c "wx/tbarsmpl.h" for wxToolBarSimple
An example of using a toolbar is given in the "toolbar" sample. An example of using a toolbar is given in the "toolbar" sample.

View File

@ -126,8 +126,7 @@ Since wxWidgets 3.0 Unicode support is always enabled and while building the
library without it is still possible, it is not recommended any longer and will library without it is still possible, it is not recommended any longer and will
cease to be supported in the near future. This means that internally only cease to be supported in the near future. This means that internally only
Unicode strings are used and that, under Microsoft Windows, Unicode system API Unicode strings are used and that, under Microsoft Windows, Unicode system API
is used which means that wxWidgets programs require the Microsoft Layer for is used.
Unicode to run on Windows 95/98/ME.
However, unlike the Unicode build mode of the previous versions of wxWidgets, this However, unlike the Unicode build mode of the previous versions of wxWidgets, this
support is mostly transparent: you can still continue to work with the @b narrow support is mostly transparent: you can still continue to work with the @b narrow

View File

@ -145,61 +145,6 @@ make install
ldconfig ldconfig
exit exit
* Building wxGTK on OS/2
------------------------
Please send comments and question about the OS/2 installation
to Stefan Neis <Stefan.Neis@t-online.de> and patches to
the wxWidgets mailing list.
In the following list, the version numbers indicate the configuration that
was actually used by myself, newer version should cause no problems and
even older ones are expected to work most of the time.
You'll need OS/2 Warp (4.51) or eCS(1.0), X-Free86/2 (3.3.6 or newer),
GTK+ (1.2.5 or newer), emx (0.9d fix 4), a Unix like shell (pdksh-5.2.14 or
ash), Autoconf (2.57), GNU file utilities (3.13), GNU text utilities (1.19),
GNU shell utilites (1.12), m4 (1.4), sed (2.05), grep (2.0), Awk (3.0.3),
GNU Make (3.75).
Preferably, you should have Posix/2 installed and C(PLUS)_INCLUDE_PATH and
LIBRARY_PATH set up accordingly, however, wxGTK will even work without it.
Presence of Posix/2 will be auto-detected.
Open an OS/2 prompt and switch to the directory above.
Set MAKESHELL or MAKE_SHELL (which one is needed depends on the version of
make) to a Unix like shell, e.g.
SET MAKESHELL=ash
If you have a really deficient version of GNU make, it might even be
necessary to set SHELL or even COMSPEC to a unix like shell as well.
Depending on your installation you might want to also set INSTALL, for me
it tends to try to use the system's tcpip\pcomos\install.exe which causes
problems, e.g.
SET INSTALL=<path_to_src_directory>/install-sh -c
Notice that the delivered configure scripts are fully OS/2 aware, so you
can simply run
ash -c "configure --with-gtk=1"
and make and possibly make install as described above.
* Building wxGTK on SGI
-----------------------
Using the SGI native compilers, it is recommended that you
also set CFLAGS and CXXFLAGS before running configure. These
should be set to :
CFLAGS="-mips3 -n32"
CXXFLAGS="-mips3 -n32"
This is essential if you want to use the resultant binaries
on any other machine than the one it was compiled on. If you
have a 64bit machine (Octane) you should also do this to ensure
you don't accidently build the libraries as 64bit (which is
untested).
The SGI native compiler support has only been tested on Irix 6.5.
* Building wxGTK on Cygwin * Building wxGTK on Cygwin
-------------------------- --------------------------
@ -326,11 +271,6 @@ drastically reduced by removing features from wxWidgets that
are not used in your program. The most relevant such features are not used in your program. The most relevant such features
are are
--with-odbc Enables ODBC code. This is disabled
by default because iODBC is under the
L-GPL license which is less liberal than
wxWindows licence.
--without-libpng Disables PNG image format code. --without-libpng Disables PNG image format code.
--without-libjpeg Disables JPEG image format code. --without-libjpeg Disables JPEG image format code.

View File

@ -171,66 +171,6 @@ make install
ldconfig ldconfig
exit exit
* Building wxMotif on OS/2
--------------------------
Please send comments and question about the OS/2 installation
to Stefan Neis <Stefan.Neis@t-online.de> and patches to
the wxWidgets mailing list.
In the following list, the version numbers indicate the configuration that
was actually used by myself, newer version should cause no problems and
even older ones are expected to work most of the time.
You'll need OS/2 Warp (4.51) or eCS(1.0), X-Free86/2 (3.3.6 or newer),
Lesstif (0.92.7 or newer), emx (0.9d fix 4), a Unix like shell (pdksh-5.2.14
or ash), Autoconf (2.57), GNU file utilities (3.13), GNU text utilities (1.19),
GNU shell utilites (1.12), m4 (1.4), sed (2.05), grep (2.0), Awk (3.0.3),
GNU Make (3.75).
Preferably, you should have Posix/2 installed and C(PLUS)_INCLUDE_PATH and
LIBRARY_PATH set up accordingly, however, wxGTK will even work without it.
Presence of Posix/2 will be auto-detected.
Open an OS/2 prompt and switch to the directory above.
Set MAKESHELL or MAKE_SHELL (which one is needed depends on the version of
make) to a Unix like shell, e.g.
SET MAKESHELL=ash
If you have a really deficient version of GNU make, it might even be
necessary to set SHELL or even COMSPEC to a unix like shell as well.
Depending on your installation you might want to also set INSTALL, for me
it tends to try to use the system's tcpip\pcomos\install.exe which causes
problems, e.g.
SET INSTALL=<path_to_src_directory>/install-sh -c
Notice that the delivered configure scripts are fully OS/2 aware, so you
can simply run
ash -c "configure --with-motif"
and make and possibly make install as described above.
To verify Lesstif installation, configure will try to compile a
sample program that requires X headers/libraries to be either
available via C_INCLUDE_PATH and LIBRARY_PATH or you need to
explicitly set CFLAGS prior to running configure.
* Building wxMotif on SGI
-------------------------
Using the SGI native compilers, it is recommended that you
also set CFLAGS and CXXFLAGS before running configure. These
should be set to :
CFLAGS="-mips3 -n32"
CXXFLAGS="-mips3 -n32"
This is essential if you want to use the resultant binaries
on any other machine than the one it was compiled on. If you
have a 64bit machine (Octane) you should also do this to ensure
you don't accidently build the libraries as 64bit (which is
untested).
The SGI native compiler support has only been tested on Irix 6.5.
* Building wxMotif on Cygwin * Building wxMotif on Cygwin
---------------------------- ----------------------------
@ -368,8 +308,6 @@ are
--without-libjpeg Disables JPEG image format code. --without-libjpeg Disables JPEG image format code.
--without-odbc Disables ODBC code.
--without-libtiff Disables TIFF image format code. --without-libtiff Disables TIFF image format code.
--without-expat Disable XML classes based on Expat parser. --without-expat Disable XML classes based on Expat parser.

View File

@ -71,12 +71,6 @@ Unfortunately we don't have makefiles for any other compilers yet.
Please contact us if you would like to help us with creating one for the Please contact us if you would like to help us with creating one for the
compiler you use. compiler you use.
Note that you can use the wxUniversal classes, wxMSW and MicroWindows (from
Century Software) to build a different variant of wxUniversal than that
documented here. Please see docs/univ/readme.txt for further information.
Note that this port is not up-to-date and probably needs work
to compile.
Note that by default, wxUniv under MSW uses PostScript printing, Note that by default, wxUniv under MSW uses PostScript printing,
not Windows printing. To change to Windows printing, set not Windows printing. To change to Windows printing, set
wxUSE_POSTSCRIPT_ARCHITECTURE_IN_MSW to 0 in include/wx/univ/setup.h wxUSE_POSTSCRIPT_ARCHITECTURE_IN_MSW to 0 in include/wx/univ/setup.h

View File

@ -157,66 +157,6 @@ make install
ldconfig ldconfig
exit exit
* Building wxX11 on OS/2
------------------------
Please send comments and question about the OS/2 installation
to Stefan Neis <Stefan.Neis@t-online.de> and patches to
the wxWidgets mailing list.
In the following list, the version numbers indicate the configuration that
was actually used by myself, newer version should cause no problems and
even older ones are expected to work most of the time.
You'll need OS/2 Warp (4.51) or eCS(1.0), X-Free86/2 (3.3.6 or newer),
emx (0.9d fix 4), flex (2.5.4), yacc (1.8) or bison (1.25),
a Unix like shell (pdksh-5.2.14 or ash), Autoconf (2.57), GNU file
utilities (3.13), GNU text utilities (1.19), GNU shell utilites (1.12),
m4 (1.4), sed (2.05), grep (2.0), Awk (3.0.3), GNU Make (3.75).
Preferably, you should have Posix/2 installed and C(PLUS)_INCLUDE_PATH and
LIBRARY_PATH set up accordingly, however, wxGTK will even work without it.
Presence of Posix/2 will be auto-detected.
Open an OS/2 prompt and switch to the directory above.
Set MAKESHELL (and depending on your installation also INSTALL, for me
it tends to try to use the system's tcpip\pcomos\install.exe which causes
problems...) to a Unix like shell, e.g.
SET MAKESHELL=ash
Be warned that depending on the precise version of your make, the
variable that needs to be set might be MAKE_SHELL instead of MAKESHELL.
If you have a really deficient version of GNU make, it might even be
necessary to set SHELL or even COMSPEC to a unix like shell as well.
Notice that the delivered configure scripts are fully OS/2 aware, so you
can simply run
ash -c "configure --with-x11"
and make and possibly make install as described above.
To verify X11 installation, configure will try to compile a
sample program that requires X headers/libraries to be either
available via C_INCLUDE_PATH and LIBRARY_PATH or you need to
explicitly set CFLAGS prior to running configure.
* Building wxX11 on SGI
-----------------------
Using the SGI native compilers, it is recommended that you
also set CFLAGS and CXXFLAGS before running configure. These
should be set to :
CFLAGS="-mips3 -n32"
CXXFLAGS="-mips3 -n32"
This is essential if you want to use the resultant binaries
on any other machine than the one it was compiled on. If you
have a 64bit machine (Octane) you should also do this to ensure
you don't accidently build the libraries as 64bit (which is
untested).
The SGI native compiler support has only been tested on Irix 6.5.
* Building wxX11 on Cygwin * Building wxX11 on Cygwin
-------------------------- --------------------------
@ -347,8 +287,6 @@ are
--without-libjpeg Disables JPEG image format code. --without-libjpeg Disables JPEG image format code.
{ --without-odbc Disables ODBC code. Not yet. }
--without-expat Disable XML classes based on Expat parser. --without-expat Disable XML classes based on Expat parser.
--disable-resources Disables the use of *.wxr type --disable-resources Disables the use of *.wxr type

View File

@ -1,201 +0,0 @@
Nano-X port
===========
What is it?
===========
The Nano-X port is based on the wxX11 code, and therefore shares
almost all of wxX11's code, including the use of the wxUniversal
widget set. Nano-X is the X-like API of the overall Microwindows
project, which also has a WIN32 API.
The Microwindows web site is at
http://microwindows.org/
Nano-X is intended to work on devices with very small amounts
of memory. wxWidgets is quite a large library, so if your
memory is measured in KB instead of MB you will need to use
an alternative library, such as FLTK. However, with memory
capacity increasing all the time, wxWidgets could become
an appropriate embedded GUI solution for many projects.
Also, it's possible to think of ways to cut wxWidgets
further down to size, such as disabling advanced controls
or rewriting utility functions. See the section on code size
below.
An alternative to using Nano-X is to use the standard
wxX11 port with Tiny-X, which (as I understand it)
maintains the Xlib API while being sufficiently cut
down to run on small devices, such as the iPAQ.
The Familiar Linux Distribution contains Tiny-X. See:
http://handhelds.org/mailman/listinfo/familiar
Building wxNano-X
=================
Building is as per the instructions for wxX11 (see readme.txt,
install.txt) but passing --enable-nanox to configure. You also need
to export the MICROWIN variable, setting it to the top-level of the
Microwindows hierarchy. Remember that MICROWIN needs to be defined
both at configuration time and at subsequent make time, so you
may find it convenient to put it in your .bash_profile or similar
file.
Typically, various features in wxWidgets will be switched off to
conserve space. The sample script below calls configure with typical
options for Nano-X.
Before compiling wxNano-X, you will also need to edit your
Microwindows 'config' file to match the values hard-coded into
configure:
ERASEMOVE=N (otherwise moving windows will look messy)
X11=Y
OPTIMIZE=N
DEBUG=Y
VERBOSE=Y
Compile Microwindows by typing 'make' from within the Microwindows src
directory.
Port notes
==========
Nano-X has a different API from Xlib, although there
are many similarities. Instead of changing the wxWidgets
code to reflect Nano-X conventions, a compatibility
layer has been added, in the form of these files:
include/wx/x11/nanox/X11/Xlib.h ; Xlib compatibility
include/wx/x11/privx.h ; Useful macros
src/x11/nanox.c ; Xlib compatibility
There is also an XtoNX.h compatibility header file
in Microwindows, which we augment with our Xlib.h
and nanox.c.
Unfortunately it is not always possible, or economical,
to provide a complete Xlib emulation, so there are
still wxUSE_NANOX preprocessor directives in the code
for awkward cases. It may be possible to eliminate
some, but probably not all, of these in future.
Port Status
===========
The port is in a very early stage: so far it links
and a window pops up, but that's about it. (The
wxX11 port using straight X11 is much more advanced.)
Things to do:
- implement some incomplete compatibility functions
in src/x11/nanox.c
- implement the colour database
- add mask capability, without which controls won't
display properly
- add further configuration options for disabling
code not normally needed in an embedded device
- optimization and code size reduction
- figuring out why libstdc++-libc is linked to
binaries -- is this done for any C++ program?
Code Size
=========
Allow about 2.5 MB for a shared wxWidgets library, with the
dynamically linked minimal sample taking about 24KB. If statically
linked, minimal takes up just over 1MB when stripped. This 1MB
includes all of wxWidgets used in the minimal sample including some of
the wxUniversal widgets. As application complexity increases,
the amount of wxWidgets code pulled into statically linked
executables increases, but for large applications, the overhead
of wxWidgets becomes less significant.
Sample sizes:
-------------
Statically-linked minimal (release): 1,024,272 bytes
Statically-linked widgets (release): 1,171,568 bytes
Shared lib, stripped (debug): 2,486,716 bytes
Shared-lib minimal (debug), stripped: 23,896 bytes
Shared lib, stripped (release): 2,315,5004 bytes
Shared-lib minimal (release), stripped: 23,896 bytes
(note: the -O flag was not passed to the minimal
makefile, for some reason)
Strategies for reducing code size
---------------------------------
- Look at the .o files compiled in a build and check
for particularly large files, or files you wouldn't
expect to be there in an embedded build.
- Disable options for features that aren't necessary,
for example: image handlers (BMP, JPEG etc.),
wxVariant, wxWizard, wxListCtrl, src/univ/themes/gtk.c.
- Add options to configure.in/setup.h where necessary,
for finer-grained configuration.
- Rewrite functions or classes for alternative stripped-down
functionality.
- Remove unnecessary functionality or obsolete code from
wxWidgets.
- Factor out wxWidgets code to reduce repetition.
- Add inlining, remove unnecessary empty functions.
- Separate code out into individual files so that all of
a .o file doesn't get pulled in, just because an app
references something else in that file. For example,
advanced event types could be separated out.
This assumes that the linker isn't clever enough to
eliminate redundant functions. The fact that the
minimal and widgets samples are very close in size
is evidence that gcc is not doing a good job here.
- Experiment with compiler options.
- Commercially supported compilers may have better
code generation and/or linker optimisation than the
one you're currently using.
Sample script for building wxNano-X
===================================
This script assumes that you will invoke it
from a build directory under the wxWidgets
top level. So you might type:
% cd wx2
% mkdir nano-x
% cd nano-x
% makewxnanox
If you need to restart compilation without
reconfiguring, just type 'make' from the same
directory.
-----------------------------:x----------------------
#!/bin/sh
# makewxnanox
export MICROWIN=/home/julians/microwindows/microwindows-0.89pre8
#DEBUGFLAGS="--enable-debug --enable-debug_cntxt --disable-optimise"
DEBUGFLAGS="--disable-debug --disable-debug_cntxt --enable-optimise"
export CONFIGCMD="./configure $DEBUGFLAGS --enable-shared --enable-gui --with-x11 --enable-nanox --enable-log --with-threads --without-sockets --without-odbc --without-libjpeg --without-libtiff --without-png --without-regex --enable-no_exceptions --disable-protocols --disable-ipc --disable-dialupman --disable-apple_ieee --disable-fraction --disable-dynlib --disable-dynamicloader --disable-geometry --disable-fontmap --disable-std_iostreams --disable-filesystem --disable-fs_inet --disable-fs_zip --disable-zipstream --disable-snglinst --disable-mimetype --disable-url --disable-html --disable-constraints --disable-printarch --disable-mdi --disable-postscript --disable-PS-normalized --disable-afmfonts --disable-prologio --disable-resources --disable-dnd --disable-metafile --disable-treelayout --disable-grid --disable-propsheet --disable-splines --disable-joystick --disable-pcx --disable-iff --disable-pnm --disable-tabdialog --disable-newgrid"
echo $CONFIGCMD
if [ ! -f ./configure ]; then
CONFIGCMD=".$CONFIGCMD"
fi
echo Invoking $CONFIGCMD
rm -f *.cache
$CONFIGCMD
make
-----------------------------:x----------------------