Convert contributors documentation to markdown.
The conversion is very superficial and there are probably many problems in the Markdown rendering, but this is the first step towards making these documents more readable when viewing them online. git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76690 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
parent
4ce8a5ed00
commit
e96b28181c
@ -1,5 +1,5 @@
|
||||
wxWidgets naming conventions
|
||||
============================
|
||||
wxWidgets naming conventions
|
||||
============================
|
||||
|
||||
Being a cross platform development library, it is naturally desirable
|
||||
(at least to me ;) for wxWidgets to be exploited in a fully cross
|
||||
@ -25,19 +25,19 @@ obvious slot for new ports to slip into.
|
||||
|
||||
For UNIX libraries, the canonical library name shall be of the form:
|
||||
|
||||
libwx_$(toolkit)$(widgetset)$(debug)-$(version)-$(host).$(lib_extension)
|
||||
libwx_$(toolkit)$(widgetset)$(debug)-$(version)-$(host).$(lib_extension)
|
||||
|
||||
For MSW (native hosted only) libraries the library name should be of
|
||||
the form:
|
||||
|
||||
wx$(toolkit)$(widgetset)$(version)$(unicode)$(debug).$(lib_extension)
|
||||
wx$(toolkit)$(widgetset)$(version)$(unicode)$(debug).$(lib_extension)
|
||||
|
||||
|
||||
Where:
|
||||
|
||||
--------------------------------------------------------------------
|
||||
|
||||
$toolkit must currently be one of the following:
|
||||
`$toolkit` must currently be one of the following:
|
||||
|
||||
msw
|
||||
gtk
|
||||
@ -47,7 +47,7 @@ $toolkit must currently be one of the following:
|
||||
|
||||
--------------------------------------------------------------------
|
||||
|
||||
$widgetset may be one of:
|
||||
`$widgetset` may be one of:
|
||||
|
||||
univ
|
||||
|
||||
@ -55,10 +55,10 @@ or empty if the widget set is the same as the toolkit.
|
||||
|
||||
--------------------------------------------------------------------
|
||||
|
||||
$version is a string encoding the full version (major, minor, release)
|
||||
`$version` is a string encoding the full version (major, minor, release)
|
||||
for MSW, or just the major and minor number for UNIX.
|
||||
|
||||
eg. for wxWidgets 2.3.2, $version = 232 for MSW or 2.3 for UNIX.
|
||||
eg. for wxWidgets 2.3.2, `$version` = 232 for MSW or 2.3 for UNIX.
|
||||
|
||||
The rationale for this is that under UNIX-like systems it is desirable
|
||||
that differently 'minor numbered' releases can be installed together,
|
||||
@ -71,24 +71,24 @@ A known break in binary compatibility should be addressed by updating
|
||||
the library soname (see the notes in configure.in for details on this)
|
||||
|
||||
I do not know why MSW should not also omit the release number from
|
||||
$version. (maybe that will change by the time this document is ratified)
|
||||
`$version`. (maybe that will change by the time this document is ratified)
|
||||
|
||||
--------------------------------------------------------------------
|
||||
|
||||
$unicode and $debug are either empty or set to 'u' and 'd'
|
||||
`$unicode` and `$debug` are either empty or set to `'u'` and `'d'`
|
||||
respectively when enabled.
|
||||
|
||||
--------------------------------------------------------------------
|
||||
|
||||
$host is empty for a 'native' library, (that is one where the host
|
||||
`$host` is empty for a 'native' library, (that is one where the host
|
||||
system is the same as the build system) or set to the value returned
|
||||
by the autoconf ${host_alias} variable in configure for libraries
|
||||
that are cross compiled.
|
||||
|
||||
--------------------------------------------------------------------
|
||||
|
||||
$lib_extension is system specific and most usually set to .a for
|
||||
a static library, .dll for a MSW shared library, or .so.$so_version
|
||||
`$lib_extension` is system specific and most usually set to `.a` for
|
||||
a static library, `.dll` for a MSW shared library, or `.so.$so_version`
|
||||
for a shared UNIX library.
|
||||
|
||||
====================================================================
|
||||
@ -98,7 +98,7 @@ The installed location of the library specific setup.h is also
|
||||
determined by the values of these items. On UNIX systems they
|
||||
will be found in:
|
||||
|
||||
$(prefix)/lib/wx/include/$(toolkit)$(widgetset)$(debug)-$(version)-$(host)/wx/
|
||||
$(prefix)/lib/wx/include/$(toolkit)$(widgetset)$(debug)-$(version)-$(host)/wx/
|
||||
|
||||
which will be in the include search path returned by the relevant
|
||||
wx-config for that library. (or presumably set in the relevant
|
||||
@ -109,14 +109,9 @@ make/project files for platforms that do not use wx-config)
|
||||
|
||||
The port specific wx-config file for each library shall be named:
|
||||
|
||||
wx-$(toolkit)$(widgetset)$(debug)-$(version)-$(host)-config
|
||||
wx-$(toolkit)$(widgetset)$(debug)-$(version)-$(host)-config
|
||||
|
||||
${prefix}/bin/wx-config shall exist as a link to (or copy of) one of
|
||||
these port specific files (on platforms which support it) and as such
|
||||
it defines the default build configuration for wxApps on the system.
|
||||
It may be modified by the system user at any time.
|
||||
|
||||
|
||||
|
||||
---==O==---
|
||||
|
||||
45
docs/contributing/about-version-numbers.md
Normal file
45
docs/contributing/about-version-numbers.md
Normal file
@ -0,0 +1,45 @@
|
||||
All about wxWidgets Version Numbers
|
||||
===================================
|
||||
|
||||
## Where to update the version numbers
|
||||
|
||||
There are several places in the wxWidgets source tree that
|
||||
define the version number for the library.
|
||||
|
||||
The script misc/scripts/inc_release can be used for incrementing the release
|
||||
field of the version, i.e. changing 2.8.x to 2.8.x+1 but it does not take
|
||||
care of version.bkl and can't be used for changing the other version
|
||||
components, this needs to be done manually. It also doesn't update
|
||||
version.bkl file which always needs to be updated manually, follow the
|
||||
instructions there.
|
||||
|
||||
Here is the list of files that need to be updated:
|
||||
|
||||
build/bakefiles/version.bkl {C:R:A} [NOT UPDATED AUTOMATICALLY]
|
||||
build/bakefiles/wxpresets/presets/wx.bkl [NOT UPDATED AUTOMATICALLY]
|
||||
configure.in
|
||||
build/osx/wxvers.xcconfig
|
||||
docs/changes.txt
|
||||
docs/readme.txt (date needs manual editing) [NOT UPDATED AUTOMATICALLY]
|
||||
docs/doxygen/Doxyfile (PROJECT_NUMBER and DOCSET_FEEDNAME)
|
||||
docs/doxygen/latexdocstart.inc
|
||||
docs/doxygen/mainpages/manual.h (just date) [NOT UPDATED AUTOMATICALLY]
|
||||
docs/msw/install.txt {major release only}
|
||||
include/wx/version.h
|
||||
include/wx/osx/config_xcode.h
|
||||
samples/Info.plist
|
||||
samples/docview/Info.plist
|
||||
samples/minimal/Info_carbon.plist
|
||||
samples/minimal/Info_cocoa.plist
|
||||
samples/minimal/borland_ide.cpp {major release only}
|
||||
|
||||
Do not forget to rebake everything after updating version.bkl!
|
||||
|
||||
|
||||
## When to update the version numbers
|
||||
|
||||
Version should be updated immediately after releasing the previous version
|
||||
so that the sources in the repository always correspond to the next release
|
||||
and not the past one.
|
||||
|
||||
See also [binary compatibility notes](binary-compatibility.md)
|
||||
@ -1,51 +0,0 @@
|
||||
All about wxWidgets Version Numbers
|
||||
===================================
|
||||
|
||||
1. Where to update the version numbers:
|
||||
|
||||
There are several places in the wxWidgets source tree that
|
||||
define the version number for the library.
|
||||
|
||||
The script misc/scripts/inc_release can be used for incrementing the release
|
||||
field of the version, i.e. changing 2.8.x to 2.8.x+1 but it does not take
|
||||
care of version.bkl and can't be used for changing the other version
|
||||
components, this needs to be done manually. It also doesn't update
|
||||
version.bkl file which always needs to be updated manually, follow the
|
||||
instructions there.
|
||||
|
||||
Here is the list of files that need to be updated:
|
||||
|
||||
build/bakefiles/version.bkl {C:R:A} [NOT UPDATED AUTOMATICALLY]
|
||||
build/bakefiles/wxpresets/presets/wx.bkl [NOT UPDATED AUTOMATICALLY]
|
||||
configure.in
|
||||
build/osx/wxvers.xcconfig
|
||||
docs/changes.txt
|
||||
docs/readme.txt (date needs manual editing) [NOT UPDATED AUTOMATICALLY]
|
||||
docs/doxygen/Doxyfile (PROJECT_NUMBER and DOCSET_FEEDNAME)
|
||||
docs/doxygen/latexdocstart.inc
|
||||
docs/doxygen/mainpages/manual.h (just date) [NOT UPDATED AUTOMATICALLY]
|
||||
docs/msw/install.txt {major release only}
|
||||
include/wx/version.h
|
||||
include/wx/osx/config_xcode.h
|
||||
samples/Info.plist
|
||||
samples/docview/Info.plist
|
||||
samples/minimal/Info_carbon.plist
|
||||
samples/minimal/Info_cocoa.plist
|
||||
samples/minimal/borland_ide.cpp {major release only}
|
||||
|
||||
Do not forget to rebake everything after updating version.bkl!
|
||||
|
||||
2. When to update the version numbers:
|
||||
|
||||
Version should be updated immediately after releasing the previous version
|
||||
so that the sources in the repository always correspond to the next release
|
||||
and not the past one.
|
||||
|
||||
See also tn0020.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
|
||||
@ -1,23 +1,24 @@
|
||||
Binary Compatibility and wxWidgets
|
||||
==================================
|
||||
0. Purpose
|
||||
----------
|
||||
Binary Compatibility and wxWidgets
|
||||
==================================
|
||||
|
||||
Purpose
|
||||
-------
|
||||
|
||||
This is a broad technote covering all aspects of binary compatibility with
|
||||
wxWidgets.
|
||||
|
||||
1. Releases
|
||||
-----------
|
||||
Releases
|
||||
--------
|
||||
|
||||
General overview of releases can be found in tn0012.txt, but for
|
||||
completeness the wxWidgets release version number is as follows:
|
||||
|
||||
2.6.2
|
||||
2.6.2
|
||||
|
||||
Where
|
||||
|
||||
2 6 2
|
||||
Major Minor Release
|
||||
2 6 2
|
||||
Major Minor Release
|
||||
|
||||
(I.E. Major.Minor.Release).
|
||||
|
||||
@ -33,19 +34,21 @@ would preclude any additions whatsoever to the stable branch. But see
|
||||
also section (4).
|
||||
|
||||
|
||||
2. What kind of changes are NOT binary compatible
|
||||
-------------------------------------------------
|
||||
What kind of changes are NOT binary compatible
|
||||
----------------------------------------------
|
||||
|
||||
If its still up, the
|
||||
[KDE guide](http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++)
|
||||
is a good reference.
|
||||
|
||||
If its still up, the KDE guide is a good reference:
|
||||
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
|
||||
|
||||
The changes that are NOT binary compatible:
|
||||
|
||||
- Adding a virtual function
|
||||
- Changing the name of a any function or variable
|
||||
- Changing the signature of a virtual function (adding a parameter,
|
||||
even a default one)
|
||||
- Changing the order of the virtual functions in a class
|
||||
["switching" them, etc.]
|
||||
even a default one)
|
||||
- Changing the order of the virtual functions in a class ("switching" them, etc.)
|
||||
- Changing access privileges of a function: some compilers (among which MSVC)
|
||||
use the function access specifier in its mangled name. Moreover, while
|
||||
changing a private function to public should be compatible (as the old
|
||||
@ -58,20 +61,20 @@ even a default one)
|
||||
- Changing the order of non-static member variables
|
||||
|
||||
|
||||
3. Changes which are compatible
|
||||
-------------------------------
|
||||
Changes which are compatible
|
||||
----------------------------
|
||||
|
||||
- Adding a new class
|
||||
- Adding a new non-virtual method to an existing class
|
||||
- Adding a new constructor to an existing class
|
||||
- Overriding the implementation of an existing virtual function
|
||||
[this is considered to be backwards binary compatible until we find a
|
||||
counter example; currently it's known to work with Apple gcc at least]
|
||||
(this is considered to be backwards binary compatible until we find a
|
||||
counter example; currently it's known to work with Apple gcc at least)
|
||||
- Anything which doesn't result in ABI change at all, e.g. adding new
|
||||
macros, constants and, of course, private changes in the implementation
|
||||
|
||||
|
||||
4. wxABI_VERSION and "forward" binary compatibility
|
||||
`wxABI_VERSION` and "forward" binary compatibility
|
||||
--------------------------------------------------
|
||||
|
||||
As mentioned we do not support "forward" binary compatibility, that is the
|
||||
@ -80,47 +83,49 @@ with old wxWidgets libraries.
|
||||
|
||||
However, for the developers who want to ensure that their application works
|
||||
with some fixed old wxWidgets version and doesn't (inadvertently) require
|
||||
features added in later releases, we provide the macro wxABI_VERSION which
|
||||
features added in later releases, we provide the macro `wxABI_VERSION` which
|
||||
can be defined to restrict the API exported by wxWidgets headers to that of
|
||||
a fixed old release.
|
||||
|
||||
For this to work, all new symbols added to binary compatible releases must
|
||||
be #if'ed with wxABI_VERSION.
|
||||
be `#if`'ed with `wxABI_VERSION`.
|
||||
|
||||
The layout of wxABI_VERSION is as follows:
|
||||
The layout of `wxABI_VERSION` is as follows:
|
||||
|
||||
20602
|
||||
20602
|
||||
|
||||
where
|
||||
|
||||
2 06 02
|
||||
Major Minor Release
|
||||
2 06 02
|
||||
Major Minor Release
|
||||
|
||||
I.E. it corresponds to the wxWidgets release in (1).
|
||||
|
||||
An example of using wxABI_VERSION is as follows for symbols
|
||||
An example of using `wxABI_VERSION` is as follows for symbols
|
||||
only in a 2.6.2 release:
|
||||
|
||||
#if wxABI_VERSION >= 20602 /* 2.6.2+ only */
|
||||
bool Load(const wxURI& location, const wxURI& proxy);
|
||||
```cpp
|
||||
#if wxABI_VERSION >= 20602 /* 2.6.2+ only */
|
||||
bool Load(const wxURI& location, const wxURI& proxy);
|
||||
|
||||
wxFileOffset GetDownloadProgress();
|
||||
wxFileOffset GetDownloadTotal();
|
||||
wxFileOffset GetDownloadProgress();
|
||||
wxFileOffset GetDownloadTotal();
|
||||
|
||||
bool ShowPlayerControls(
|
||||
wxMediaCtrlPlayerControls flags =
|
||||
wxMEDIACTRLPLAYERCONTROLS_DEFAULT);
|
||||
bool ShowPlayerControls(
|
||||
wxMediaCtrlPlayerControls flags =
|
||||
wxMEDIACTRLPLAYERCONTROLS_DEFAULT);
|
||||
|
||||
//helpers for the wxPython people
|
||||
bool LoadURI(const wxString& fileName)
|
||||
{ return Load(wxURI(fileName)); }
|
||||
bool LoadURIWithProxy(const wxString& fileName, const wxString& proxy)
|
||||
{ return Load(wxURI(fileName), wxURI(proxy)); }
|
||||
#endif
|
||||
//helpers for the wxPython people
|
||||
bool LoadURI(const wxString& fileName)
|
||||
{ return Load(wxURI(fileName)); }
|
||||
bool LoadURIWithProxy(const wxString& fileName, const wxString& proxy)
|
||||
{ return Load(wxURI(fileName), wxURI(proxy)); }
|
||||
#endif
|
||||
```
|
||||
|
||||
|
||||
5. Workarounds for adding virtual functions
|
||||
-------------------------------------------
|
||||
Workarounds for adding virtual functions
|
||||
----------------------------------------
|
||||
|
||||
Originally the idea for adding virtual functions to binary compatible
|
||||
releases was to pad out some empty "reserved" functions and then
|
||||
@ -145,7 +150,8 @@ field and/or method.
|
||||
|
||||
In the case of fields this is a void*, and in the case of method
|
||||
is a wxShadowObjectMethod which is a typedef:
|
||||
typedef int (*wxShadowObjectMethod)(void*, void*);
|
||||
|
||||
typedef int (*wxShadowObjectMethod)(void*, void*);
|
||||
|
||||
After you add a field, you can set it via SetField with the same
|
||||
parameters as AddField, the second parameter being the value to set
|
||||
@ -163,11 +169,12 @@ parameter passed to the wxShadowObjectMethod, the third is the
|
||||
second parameter passed to that wxShadowObjectMethod, and the
|
||||
fourth is the return value of the wxShadowObjectMethod.
|
||||
|
||||
6. version-script.in
|
||||
--------------------
|
||||
|
||||
version-script.in
|
||||
-----------------
|
||||
|
||||
For ld/libtool we use sun-style version scripts. Basically
|
||||
anything which fits the conditions of being #if'ed via wxABI_VERSION
|
||||
anything which fits the conditions of being `#if`'ed via `wxABI_VERSION`
|
||||
needs to go here also.
|
||||
|
||||
See 'info ld scripts version' on a GNU system, it's online here:
|
||||
@ -179,7 +186,7 @@ http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p1.html
|
||||
|
||||
The file has the layout as follows:
|
||||
|
||||
@WX_VERSION_TAG@.X
|
||||
@WX_VERSION_TAG@.X
|
||||
|
||||
Where X is the current Release as mentioned earlier, i.e. 2. This
|
||||
is following by an opening bracket "{", followed by "global:",
|
||||
@ -191,13 +198,16 @@ The patterns used to specify added symbols are globbing patters and can
|
||||
contain wildcards such as '*'.
|
||||
|
||||
For example for a new class member such as:
|
||||
|
||||
wxFont wxGenericListCtrl::GetItemFont( long item ) const;
|
||||
|
||||
the mangled symbol might be:
|
||||
|
||||
_ZNK17wxGenericListCtrl11GetItemFontEl
|
||||
|
||||
so a line like this could be added to version-script.in:
|
||||
*wxGenericListCtrl*GetItemFont*;
|
||||
|
||||
\*wxGenericListCtrl*GetItemFont*;
|
||||
|
||||
Allow for the fact that the name mangling is going to vary from compiler to
|
||||
complier.
|
||||
@ -205,62 +215,63 @@ complier.
|
||||
When adding a class you can match all the symbols it adds with a single
|
||||
pattern, so long as that pattern is not likely to also match other symbols.
|
||||
For example for wxLogBuffer a line like this:
|
||||
*wxLogBuffer*;
|
||||
|
||||
\*wxLogBuffer*;
|
||||
|
||||
|
||||
7. Checking the version information in libraries and programs
|
||||
-------------------------------------------------------------
|
||||
Checking the version information in libraries and programs
|
||||
----------------------------------------------------------
|
||||
|
||||
On Sun there is a tool for this, see pvs(1). On GNU you can use objdump, below
|
||||
are some examples.
|
||||
|
||||
To see what versions of each library a program (or library) depends on:
|
||||
|
||||
$ objdump -p widgets | sed -ne '/Version References/,/^$/p'
|
||||
Version References:
|
||||
required from libgcc_s.so.1:
|
||||
0x0b792650 0x00 10 GCC_3.0
|
||||
required from libwx_based-2.6.so.0:
|
||||
0x0cca2546 0x00 07 WXD_2.6
|
||||
required from libstdc++.so.6:
|
||||
0x056bafd3 0x00 09 CXXABI_1.3
|
||||
0x08922974 0x00 06 GLIBCXX_3.4
|
||||
required from libwx_gtk2d_core-2.6.so.0:
|
||||
0x0a2545d2 0x00 08 WXD_2.6.2
|
||||
0x0cca2546 0x00 05 WXD_2.6
|
||||
required from libc.so.6:
|
||||
0x09691a75 0x00 04 GLIBC_2.2.5
|
||||
$ objdump -p widgets | sed -ne '/Version References/,/^$/p'
|
||||
Version References:
|
||||
required from libgcc_s.so.1:
|
||||
0x0b792650 0x00 10 GCC_3.0
|
||||
required from libwx_based-2.6.so.0:
|
||||
0x0cca2546 0x00 07 WXD_2.6
|
||||
required from libstdc++.so.6:
|
||||
0x056bafd3 0x00 09 CXXABI_1.3
|
||||
0x08922974 0x00 06 GLIBCXX_3.4
|
||||
required from libwx_gtk2d_core-2.6.so.0:
|
||||
0x0a2545d2 0x00 08 WXD_2.6.2
|
||||
0x0cca2546 0x00 05 WXD_2.6
|
||||
required from libc.so.6:
|
||||
0x09691a75 0x00 04 GLIBC_2.2.5
|
||||
|
||||
To see what WXD_2.6.2 symbols a program uses:
|
||||
|
||||
$ objdump -T widgets | grep 'WXD_2\.6\.2'
|
||||
0000000000000000 g DO *ABS* 0000000000000000 WXD_2.6.2 WXD_2.6.2
|
||||
00000000004126d8 DF *UND* 0000000000000177 WXD_2.6.2 _ZN19wxTopLevelWindowGTK20RequestUserAttentionEi
|
||||
$ objdump -T widgets | grep 'WXD_2\.6\.2'
|
||||
0000000000000000 g DO *ABS* 0000000000000000 WXD_2.6.2 WXD_2.6.2
|
||||
00000000004126d8 DF *UND* 0000000000000177 WXD_2.6.2 _ZN19wxTopLevelWindowGTK20RequestUserAttentionEi
|
||||
|
||||
To see what WXD_2.6.2 symbols a library defines:
|
||||
|
||||
$ objdump -T libwx_based-2.6.so | grep 'WXD_2\.6\.2' | grep -v 'UND\|ABS'
|
||||
0000000000259a10 w DO .data 0000000000000018 WXD_2.6.2 _ZTI19wxMessageOutputBest
|
||||
00000000002599e0 w DO .data 0000000000000028 WXD_2.6.2 _ZTV19wxMessageOutputBest
|
||||
000000000010a98e w DF .text 000000000000003e WXD_2.6.2 _ZN19wxMessageOutputBestD0Ev
|
||||
0000000000114efb w DO .rodata 000000000000000e WXD_2.6.2 _ZTS11wxLogBuffer
|
||||
0000000000255590 w DO .data 0000000000000018 WXD_2.6.2 _ZTI11wxLogBuffer
|
||||
000000000011b550 w DO .rodata 0000000000000016 WXD_2.6.2 _ZTS19wxMessageOutputBest
|
||||
00000000000bfcc8 g DF .text 00000000000000dd WXD_2.6.2 _ZN11wxLogBuffer5DoLogEmPKcl
|
||||
000000000010a3a6 g DF .text 0000000000000153 WXD_2.6.2 _ZN19wxMessageOutputBest6PrintfEPKcz
|
||||
00000000000c0b22 w DF .text 000000000000004b WXD_2.6.2 _ZN11wxLogBufferD0Ev
|
||||
00000000000bfc3e g DF .text 0000000000000089 WXD_2.6.2 _ZN11wxLogBuffer5FlushEv
|
||||
00000000000c0ad6 w DF .text 000000000000004b WXD_2.6.2 _ZN11wxLogBufferD1Ev
|
||||
00000000000b1130 w DF .text 0000000000000036 WXD_2.6.2 _ZN11wxLogBufferC1Ev
|
||||
00000000000c095c w DF .text 0000000000000029 WXD_2.6.2 _ZN19wxMessageOutputBestC1Ev
|
||||
00000000000c08e8 w DF .text 000000000000003e WXD_2.6.2 _ZN19wxMessageOutputBestD1Ev
|
||||
00000000002554c0 w DO .data 0000000000000038 WXD_2.6.2 _ZTV11wxLogBuffer
|
||||
00000000000bfda6 g DF .text 0000000000000036 WXD_2.6.2 _ZN11wxLogBuffer11DoLogStringEPKcl
|
||||
00000000000abe10 g DF .text 0000000000000088 WXD_2.6.2 _ZN14wxZipFSHandler7CleanupEv
|
||||
$ objdump -T libwx_based-2.6.so | grep 'WXD_2\.6\.2' | grep -v 'UND\|ABS'
|
||||
0000000000259a10 w DO .data 0000000000000018 WXD_2.6.2 _ZTI19wxMessageOutputBest
|
||||
00000000002599e0 w DO .data 0000000000000028 WXD_2.6.2 _ZTV19wxMessageOutputBest
|
||||
000000000010a98e w DF .text 000000000000003e WXD_2.6.2 _ZN19wxMessageOutputBestD0Ev
|
||||
0000000000114efb w DO .rodata 000000000000000e WXD_2.6.2 _ZTS11wxLogBuffer
|
||||
0000000000255590 w DO .data 0000000000000018 WXD_2.6.2 _ZTI11wxLogBuffer
|
||||
000000000011b550 w DO .rodata 0000000000000016 WXD_2.6.2 _ZTS19wxMessageOutputBest
|
||||
00000000000bfcc8 g DF .text 00000000000000dd WXD_2.6.2 _ZN11wxLogBuffer5DoLogEmPKcl
|
||||
000000000010a3a6 g DF .text 0000000000000153 WXD_2.6.2 _ZN19wxMessageOutputBest6PrintfEPKcz
|
||||
00000000000c0b22 w DF .text 000000000000004b WXD_2.6.2 _ZN11wxLogBufferD0Ev
|
||||
00000000000bfc3e g DF .text 0000000000000089 WXD_2.6.2 _ZN11wxLogBuffer5FlushEv
|
||||
00000000000c0ad6 w DF .text 000000000000004b WXD_2.6.2 _ZN11wxLogBufferD1Ev
|
||||
00000000000b1130 w DF .text 0000000000000036 WXD_2.6.2 _ZN11wxLogBufferC1Ev
|
||||
00000000000c095c w DF .text 0000000000000029 WXD_2.6.2 _ZN19wxMessageOutputBestC1Ev
|
||||
00000000000c08e8 w DF .text 000000000000003e WXD_2.6.2 _ZN19wxMessageOutputBestD1Ev
|
||||
00000000002554c0 w DO .data 0000000000000038 WXD_2.6.2 _ZTV11wxLogBuffer
|
||||
00000000000bfda6 g DF .text 0000000000000036 WXD_2.6.2 _ZN11wxLogBuffer11DoLogStringEPKcl
|
||||
00000000000abe10 g DF .text 0000000000000088 WXD_2.6.2 _ZN14wxZipFSHandler7CleanupEv
|
||||
|
||||
|
||||
8. Testing binary compatibility between releases
|
||||
------------------------------------------------
|
||||
Testing binary compatibility between releases
|
||||
---------------------------------------------
|
||||
|
||||
An easy way of testing binary compatibility is just to build wxWidgets
|
||||
in dll/dynamic library mode and then switch out the current library
|
||||
@ -280,8 +291,3 @@ the current ABI (if the 'expected_abi' file is not already in the repo).
|
||||
Then rebuild wxWidgets with your changes and use 'abicheck.sh' to compare the
|
||||
resulting ABI with the expected one.
|
||||
Note that the abicheck.sh script is in the "lib" folder.
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: RN
|
||||
@ -1,5 +1,5 @@
|
||||
Adding wxWidgets class documentation
|
||||
====================================
|
||||
Adding wxWidgets class documentation
|
||||
====================================
|
||||
|
||||
This note is aimed at people wishing to add documentation for a
|
||||
class to either the main wxWidgets manual, or to their own
|
||||
@ -31,28 +31,29 @@ which are implementation details.
|
||||
|
||||
|
||||
Running Doxygen
|
||||
===============
|
||||
---------------
|
||||
|
||||
First, make sure you have a recent version of Doxygen installed in your system
|
||||
(you'll need Doxygen >= 1.5.7).
|
||||
(currently Doxygen 1.8.2 is used).
|
||||
|
||||
On Unix:
|
||||
|
||||
1) run wxWidgets/docs/doxygen/regen.sh [format-to-generate]
|
||||
1. run `wxWidgets/docs/doxygen/regen.sh [format-to-generate]`
|
||||
|
||||
On Windows:
|
||||
1) cd wxWidgets/docs/doxygen
|
||||
2) run regen.bat [format-to-generate]
|
||||
|
||||
If you don't specify which format to [re]generate, all output formats will
|
||||
be enabled. Possible values for [format-to-generate] are: "html", "chm", "latex",
|
||||
"xml" and "all".
|
||||
1. cd wxWidgets/docs/doxygen
|
||||
2. run `regen.bat [format-to-generate]`
|
||||
|
||||
If you don't specify which format to generate, all output formats will
|
||||
be enabled. Possible values for `format-to-generate` are: `html`, `chm`, `latex`,
|
||||
`xml` and `all`.
|
||||
|
||||
The output of Doxygen is all placed in the wxWidgets/docs/doxygen/out folder.
|
||||
|
||||
|
||||
Important Dos and Don'ts
|
||||
========================
|
||||
------------------------
|
||||
|
||||
DO:
|
||||
|
||||
@ -93,8 +94,8 @@ DO:
|
||||
will interpret them as the marker of the end of the first argument and
|
||||
the beginning of the second argument's text.
|
||||
|
||||
E.g. if you want to define the item "wxEVT_MACRO(id, func)" you need to
|
||||
write:
|
||||
E.g. if you want to define the item "wxEVT_MACRO(id, func)" you need to write:
|
||||
|
||||
@itemdef{wxEVT_MACRO(id\, func), This is the description of the macro}
|
||||
|
||||
Also note that you need to escape only the commas of the first argument's
|
||||
@ -102,12 +103,12 @@ DO:
|
||||
for the trick used to implement this).
|
||||
|
||||
- for linking use one of:
|
||||
=> the @ref command to refer to topic overviews;
|
||||
=> the () suffix to refer to function members of the same class you're
|
||||
documenting or to refer to global functions or macros;
|
||||
=> the classname:: operator to refer to functions of classes different
|
||||
from the one you're documenting;
|
||||
=> the :: prefix to refer to global variables (e.g. ::wxEmptyString).
|
||||
- the @ref command to refer to topic overviews;
|
||||
- the () suffix to refer to function members of the same class you're
|
||||
- documenting or to refer to global functions or macros;
|
||||
- the classname:: operator to refer to functions of classes different
|
||||
- from the one you're documenting;
|
||||
- the `::` prefix to refer to global variables (e.g. ::wxEmptyString).
|
||||
Class names are auto-linked by Doxygen without the need of any explicit
|
||||
command.
|
||||
|
||||
@ -120,7 +121,7 @@ DON'T:
|
||||
- use non-alphanumeric characters in link anchors.
|
||||
|
||||
- use Doxygen @b @c @e commands when referring to more than a single word;
|
||||
in that case you need to use the <b>...</b>, <tt>...</tt>, <em>...</em>
|
||||
in that case you need to use the `<b>...</b>`, `<tt>...</tt>`, `<em>...</em>`
|
||||
HTML-style tags instead
|
||||
|
||||
- use HTML style tags for creation of tables or lists.
|
||||
@ -130,47 +131,47 @@ DON'T:
|
||||
|
||||
|
||||
Documentation comment for a class
|
||||
=================================
|
||||
---------------------------------
|
||||
|
||||
Start off with:
|
||||
|
||||
/**
|
||||
@class wxMyClass
|
||||
/**
|
||||
@class wxMyClass
|
||||
|
||||
...here goes the description...
|
||||
...here goes the description...
|
||||
|
||||
@beginEventTable
|
||||
@event{EVT_SOME_EVENT(id, func)}:
|
||||
Description for EVT_SOME_EVENT.
|
||||
@endEventTable
|
||||
@beginEventTable
|
||||
@event{EVT_SOME_EVENT(id, func)}:
|
||||
Description for EVT_SOME_EVENT.
|
||||
@endEventTable
|
||||
|
||||
@beginStyleTable
|
||||
@style{wxSOME_STYLE}:
|
||||
Description for wxSOME_STYLE.
|
||||
...
|
||||
@endStyleTable
|
||||
@beginStyleTable
|
||||
@style{wxSOME_STYLE}:
|
||||
Description for wxSOME_STYLE.
|
||||
...
|
||||
@endStyleTable
|
||||
|
||||
@beginExtraStyleTable
|
||||
@style{wxSOME_EXTRA_STYLE}:
|
||||
Description for wxSOME_EXTRA_STYLE.
|
||||
...
|
||||
@endExtraStyleTable
|
||||
@beginExtraStyleTable
|
||||
@style{wxSOME_EXTRA_STYLE}:
|
||||
Description for wxSOME_EXTRA_STYLE.
|
||||
...
|
||||
@endExtraStyleTable
|
||||
|
||||
@library{wxbase}
|
||||
@category{cat_shortcut}
|
||||
@library{wxbase}
|
||||
@category{cat_shortcut}
|
||||
|
||||
@nativeimpl{wxgtk, wxmsw, ...}
|
||||
@onlyfor{wxgtk, wxmsw, ...}
|
||||
@nativeimpl{wxgtk, wxmsw, ...}
|
||||
@onlyfor{wxgtk, wxmsw, ...}
|
||||
|
||||
@appearance{button.png}
|
||||
@appearance{button.png}
|
||||
|
||||
@stdobjects
|
||||
...here goes the list of predefined instances...
|
||||
@stdobjects
|
||||
...here goes the list of predefined instances...
|
||||
|
||||
@see ...here goes the see-also list...
|
||||
you can make references to topic overviews or other
|
||||
manual pages using the @ref command
|
||||
*/
|
||||
@see ...here goes the see-also list...
|
||||
you can make references to topic overviews or other
|
||||
manual pages using the @ref command
|
||||
*/
|
||||
|
||||
Note that everything *except* the @class, @library and @category
|
||||
commands are optionals.
|
||||
@ -181,102 +182,102 @@ where "xxxx" is the class name without the initial "wx" in lowercase
|
||||
and "yyyy" is a lowercase word which uniquely identifies that section.
|
||||
E.g.:
|
||||
|
||||
/**
|
||||
@class wxMyClass
|
||||
/**
|
||||
@class wxMyClass
|
||||
|
||||
This class does not exist really and is only used as an example
|
||||
of best documentation practices.
|
||||
This class does not exist really and is only used as an example
|
||||
of best documentation practices.
|
||||
|
||||
@section myclass_special Special functions of this class
|
||||
@section myclass_special Special functions of this class
|
||||
|
||||
This section describes the functions whose usage is reserved for
|
||||
wxWidgets internal mechanisms... etc etc...
|
||||
This section describes the functions whose usage is reserved for
|
||||
wxWidgets internal mechanisms... etc etc...
|
||||
|
||||
|
||||
@section myclass_custom Customizing wxMyClass
|
||||
@section myclass_custom Customizing wxMyClass
|
||||
|
||||
What if you want to customize this powerful class?
|
||||
First you should do this and that, etc etc...
|
||||
What if you want to customize this powerful class?
|
||||
First you should do this and that, etc etc...
|
||||
|
||||
|
||||
@library{wxbase}
|
||||
@category{misc}
|
||||
@library{wxbase}
|
||||
@category{misc}
|
||||
|
||||
@see wxMyOtherClass
|
||||
*/
|
||||
@see wxMyOtherClass
|
||||
*/
|
||||
|
||||
|
||||
|
||||
Documentation comment for a function
|
||||
====================================
|
||||
------------------------------------
|
||||
|
||||
Start off with:
|
||||
|
||||
/**
|
||||
...here goes the description of the function....
|
||||
/**
|
||||
...here goes the description of the function....
|
||||
|
||||
@param param1
|
||||
...here goes the description for the first parameter of this function
|
||||
@param param2
|
||||
...here goes the description for the second parameter of this function
|
||||
...
|
||||
@param param1
|
||||
...here goes the description for the first parameter of this function
|
||||
@param param2
|
||||
...here goes the description for the second parameter of this function
|
||||
...
|
||||
|
||||
@return
|
||||
...here goes the description of what the function returns...
|
||||
@return
|
||||
...here goes the description of what the function returns...
|
||||
|
||||
@note ...here go any eventual notes about this function...
|
||||
@note ...here go any eventual notes about this function...
|
||||
|
||||
@remarks ...here go any eventual remarks about this function...
|
||||
@remarks ...here go any eventual remarks about this function...
|
||||
|
||||
@see ...here goes the see-also list...
|
||||
*/
|
||||
@see ...here goes the see-also list...
|
||||
*/
|
||||
|
||||
Note that the @return, @note, @remarks, @see commands are optional.
|
||||
|
||||
The @param command has an optional attribute specifying the direction of
|
||||
the attribute. Possible values are "in" and "out". E.g.
|
||||
|
||||
/**
|
||||
* Copies bytes from a source memory area to a destination memory area,
|
||||
* where both areas may not overlap.
|
||||
* @param[out] dest The memory area to copy to.
|
||||
* @param[in] src The memory area to copy from.
|
||||
* @param[in] n The number of bytes to copy.
|
||||
* @param[in,out] pmisc Used both as input and as output.
|
||||
*/
|
||||
void func(void *dest, const void *src, size_t n, void *pmisc);
|
||||
/**
|
||||
* Copies bytes from a source memory area to a destination memory area,
|
||||
* where both areas may not overlap.
|
||||
* @param[out] dest The memory area to copy to.
|
||||
* @param[in] src The memory area to copy from.
|
||||
* @param[in] n The number of bytes to copy.
|
||||
* @param[in,out] pmisc Used both as input and as output.
|
||||
*/
|
||||
void func(void *dest, const void *src, size_t n, void *pmisc);
|
||||
|
||||
|
||||
Documentation comment for a topic overview
|
||||
==========================================
|
||||
------------------------------------------
|
||||
|
||||
Topic overviews are stored inside the docs/doxygen/overviews folder
|
||||
and are completely placed inside a single comment block in the form of:
|
||||
|
||||
/*!
|
||||
/*!
|
||||
|
||||
@page overview_tname wxSomeStuff overview
|
||||
@page overview_tname wxSomeStuff overview
|
||||
|
||||
This page provides an overview of the wxSomeStuff and related classes.
|
||||
....
|
||||
This page provides an overview of the wxSomeStuff and related classes.
|
||||
....
|
||||
|
||||
@li @ref overview_tname_intro
|
||||
@li @ref overview_tname_details
|
||||
...
|
||||
@li @ref overview_tname_intro
|
||||
@li @ref overview_tname_details
|
||||
...
|
||||
|
||||
<hr>
|
||||
<hr>
|
||||
|
||||
|
||||
@section overview_tname_intro Introduction
|
||||
@section overview_tname_intro Introduction
|
||||
|
||||
...here goes the introduction to this topic...
|
||||
...here goes the introduction to this topic...
|
||||
|
||||
|
||||
@section overview_tname_details Details
|
||||
@section overview_tname_details Details
|
||||
|
||||
...here go the details to this topic...
|
||||
...here go the details to this topic...
|
||||
|
||||
*/
|
||||
*/
|
||||
|
||||
Note that there is a convention in the anchor link names.
|
||||
Doxygen in fact requires that for each @page, @section, @subsection, etc tag,
|
||||
@ -284,32 +285,25 @@ there is a corresponding link anchor.
|
||||
|
||||
The following conventions are used in wxWidgets doxygen comments:
|
||||
|
||||
1) all "main" pages of the manual (those which are placed in
|
||||
1. all "main" pages of the manual (those which are placed in
|
||||
docs/doxygen/mainpages) have link anchors which begin with "page_"
|
||||
|
||||
2) all topic overviews (those which are placed in docs/doxygen/overviews) have
|
||||
2. all topic overviews (those which are placed in docs/doxygen/overviews) have
|
||||
link anchors which begin with "overview_"
|
||||
|
||||
3) all @section, @subsection, @subsubsection tags should have as link anchor
|
||||
3. all @section, @subsection, @subsubsection tags should have as link anchor
|
||||
name the name of the parent section plus a specific word separated with an
|
||||
underscore; e.g.:
|
||||
|
||||
/*!
|
||||
/*!
|
||||
|
||||
@page overview_tname wxSomeStuff overview
|
||||
@page overview_tname wxSomeStuff overview
|
||||
|
||||
@section overview_tname_intro Introduction
|
||||
@subsection overview_tname_intro_firstpart First part
|
||||
@subsection overview_tname_intro_secondpart Second part
|
||||
@subsubsection overview_tname_intro_secondpart_sub Second part subsection
|
||||
@subsection overview_tname_intro_thirdpart Third part
|
||||
@section overview_tname_intro Introduction
|
||||
@subsection overview_tname_intro_firstpart First part
|
||||
@subsection overview_tname_intro_secondpart Second part
|
||||
@subsubsection overview_tname_intro_secondpart_sub Second part subsection
|
||||
@subsection overview_tname_intro_thirdpart Third part
|
||||
|
||||
@section overview_tname_details Details
|
||||
...
|
||||
@section overview_tname_details Details
|
||||
...
|
||||
|
||||
*/
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: FM (along the lines of the previous technote about tex2rtf)
|
||||
*/
|
||||
@ -1,14 +1,14 @@
|
||||
How to add new files and libraries to wxWidgets build system
|
||||
============================================================
|
||||
How to add new files and libraries to wxWidgets build system
|
||||
============================================================
|
||||
|
||||
|
||||
1. Regenerating makefiles
|
||||
-------------------------
|
||||
Regenerating makefiles
|
||||
----------------------
|
||||
|
||||
wxWidgets now uses Bakefile (http://bakefile.sourceforge.net) to generate
|
||||
wxWidgets now uses [Bakefile](http://bakefile.sourceforge.net) to generate
|
||||
native makefiles. You must have bakefile installed if you want to regenerate
|
||||
the makefiles. Bakefile currently runs on Unix and Windows systems. You will
|
||||
need Python >= 2.2 installed on Unix and either use Bakefile installer or have
|
||||
need Python 2.x installed on Unix and either use Bakefile installer or have
|
||||
Python on Windows.
|
||||
|
||||
Once you have installed Bakefile, you can easily regenerate the makefiles using
|
||||
@ -27,57 +27,66 @@ You can use Bakefile to generate makefiles or projects customized to your
|
||||
needs, too. See Bakefiles.bkgen for details on bakefile commands used to
|
||||
generate makefiles. For example, you can use this command to generate
|
||||
VC++ project files without wxUniversal configurations:
|
||||
|
||||
bakefile -v -fmsvc6prj -o../wxmy.dsw -DRUNTIME_LIBS=dynamic
|
||||
-DDEBUG_INFO=default -DDEBUG_FLAG=default
|
||||
-DOFFICIAL_BUILD=0 -DUSE_HTML=1 -DUSE_OPENGL=1
|
||||
-DMONOLITHIC=0 -DUSE_GUI=1 -DWXUNIV=0 wx.bkl
|
||||
|
||||
Or monolithic instead of multilib (the default):
|
||||
|
||||
bakefile -v -fmsvc6prj -o../wxmono.dsw -DRUNTIME_LIBS=dynamic
|
||||
-DDEBUG_INFO=default -DDEBUG_FLAG=default
|
||||
-DOFFICIAL_BUILD=0 -DUSE_HTML=1 -DUSE_OPENGL=1
|
||||
-DMONOLITHIC=1 -DUSE_GUI=1 wx.bkl
|
||||
|
||||
Or monolithic wxBase:
|
||||
|
||||
bakefile -v -fmsvc6prj -o../wxBase.dsw -DRUNTIME_LIBS=dynamic
|
||||
-DDEBUG_INFO=default -DDEBUG_FLAG=default
|
||||
-DOFFICIAL_BUILD=0 -DUSE_HTML=0 -DUSE_OPENGL=0
|
||||
-DMONOLITHIC=1 -DUSE_GUI=0 wx.bkl
|
||||
|
||||
It is, however, recommended to modify Bakefiles.bkgen (or
|
||||
Bakefiles.local.bkgen) by means of <add-flags> and <del-flags> directives
|
||||
Bakefiles.local.bkgen) by means of `<add-flags>` and `<del-flags>` directives
|
||||
and use bakefile_gen instead of running bakefile directly.
|
||||
|
||||
|
||||
2. Bakefile files organization
|
||||
------------------------------
|
||||
Bakefile files organization
|
||||
---------------------------
|
||||
|
||||
Makefile are generated from .bkl files ("bakefiles") from two places:
|
||||
|
||||
- $(wx)/build/bakefiles directory
|
||||
- samples directories
|
||||
|
||||
$(wx)/build/bakefiles contains bakefiles for main library and support files
|
||||
that simplify writing bakefiles for samples.
|
||||
|
||||
Support files are:
|
||||
wxwin.py - helper functions
|
||||
common.bkl
|
||||
common_samples.bkl
|
||||
config.bkl - user-configurable build options
|
||||
make_dist.mk - implementation of "make dist" on Unix
|
||||
|
||||
- wxwin.py - helper functions
|
||||
- common.bkl
|
||||
- common_samples.bkl
|
||||
- config.bkl - user-configurable build options
|
||||
- make_dist.mk - implementation of "make dist" on Unix
|
||||
|
||||
Files used to build the library are:
|
||||
wx.bkl - main file
|
||||
files.bkl - lists of source files
|
||||
monolithic.bkl - targets for wxWin built as single big library
|
||||
multilib.bkl - targets for multilib build
|
||||
opengl.bkl - GL library with wxGLCanvas (this one is not
|
||||
|
||||
- wx.bkl - main file
|
||||
- files.bkl - lists of source files
|
||||
- monolithic.bkl - targets for wxWin built as single big library
|
||||
- multilib.bkl - targets for multilib build
|
||||
- opengl.bkl - GL library with wxGLCanvas (this one is not
|
||||
included in monolithic library for historical
|
||||
reasons, so "monolithic" really means "two libs")
|
||||
{expat,jpeg,png,tiff,
|
||||
regex,zlib,odbc}.bkl - 3rd party libraries makefiles
|
||||
- {expat,jpeg,png,tiff, regex,zlib,odbc}.bkl - 3rd party libraries makefiles
|
||||
|
||||
|
||||
3. Adding files to existing library
|
||||
-----------------------------------
|
||||
Adding files to existing library
|
||||
--------------------------------
|
||||
|
||||
UPDATE: files.bkl is now itself partially generated from the master file
|
||||
**UPDATE:** files.bkl is now itself partially generated from the master file
|
||||
build/files. If the variable which you need to modify, according to the
|
||||
instructions below, is already defined in build/files, update it there
|
||||
and run build/upmake to update files.bkl.
|
||||
@ -85,10 +94,10 @@ UPDATE: files.bkl is now itself partially generated from the master file
|
||||
|
||||
All files used by main libraries are listed in files.bkl. The file is
|
||||
organized into variables for toolkits, platforms and libraries. The variables
|
||||
come in pairs: there's always FOO_SRC for source files and FOO_HDR for header
|
||||
come in pairs: there's always `FOO_SRC` for source files and `FOO_HDR` for header
|
||||
files. Platform or toolkit specific files are grouped together in variable
|
||||
with platform or toolkit name in them, e.g. BASE_WIN32_SRC, BASE_UNIX_SRC,
|
||||
GTK_SRC, MOTIF_SRC.
|
||||
with platform or toolkit name in them, e.g. `BASE_WIN32_SRC`, `BASE_UNIX_SRC`,
|
||||
`GTK_SRC`, `MOTIF_SRC`.
|
||||
|
||||
Note: A side effect of this toolkit-centric organization is that one file may
|
||||
be present several times in files.bkl in different contexts.
|
||||
@ -96,28 +105,28 @@ Note: A side effect of this toolkit-centric organization is that one file may
|
||||
When you are adding a file, you must put it into appropriate variable. This is
|
||||
easy if you are adding the file to library that is always built from same
|
||||
sources on all platforms (e.g. wxXml or wxXML) -- simply add the file to e.g.
|
||||
HTML_SRC or HTML_HDR.
|
||||
`HTML_SRC` or `HTML_HDR`.
|
||||
|
||||
If the file is used only on one platform and is part of wxBase, add it to
|
||||
BASE_{platform}_SRC/HDR. If it is used on all platforms, add it to BASE_CMN.
|
||||
`BASE_{platform}_SRC/HDR`. If it is used on all platforms, add it to `BASE_CMN`.
|
||||
If it is built on more than one platform but not on all of them, add the file
|
||||
to *all platforms that use it*!
|
||||
to *all* platforms that use it!
|
||||
|
||||
If a file is not wxBase file, but GUI file, then the variables are named after
|
||||
toolkits/ports, not platforms. Same rules as for wxBase files apply
|
||||
(substitute "platform" with "toolkit"). Make sure you correctly choose between
|
||||
{port}_LOWLEVEL_SRC and {port}_SRC -- the former is for files used by
|
||||
`{port}_LOWLEVEL_SRC` and `{port}_SRC` -- the former is for files used by
|
||||
wxUniversal, e.g. GDI classes. Files shared by all X Window System ports
|
||||
should be put into XWIN_LOWLEVEL_SRC.
|
||||
should be put into `XWIN_LOWLEVEL_SRC`.
|
||||
|
||||
|
||||
4. Adding sample
|
||||
----------------
|
||||
Adding sample
|
||||
-------------
|
||||
|
||||
Copy the bakefile from another sample, change the ID and files accordingly.
|
||||
If the sample uses some data files, make sure to have <wx-data> node
|
||||
If the sample uses some data files, make sure to have `<wx-data>` node
|
||||
in the sample's bakefile (see e.g. samples/image/image.bkl for an example).
|
||||
Make sure to add <wx-lib> statements for all libraries from multilib build
|
||||
Make sure to add `<wx-lib>` statements for all libraries from multilib build
|
||||
that are required by the sample.
|
||||
|
||||
The Windows resource specification should use the central .rc file:
|
||||
@ -131,8 +140,8 @@ Finally commit $(wx)/build/bakefiles/make_dist.mk and all the other modified fil
|
||||
Currently we commit the generated makefiles except .dms, .vcp.
|
||||
|
||||
|
||||
5. Adding new core library
|
||||
--------------------------
|
||||
Adding new core library
|
||||
-----------------------
|
||||
|
||||
When adding new library to the core set of libraries, the files must be
|
||||
added to both a newly added library in multilib build and into the single
|
||||
@ -141,21 +150,21 @@ called wxFoo.
|
||||
|
||||
a) Add files to files.bkl:
|
||||
* If wxFoo builds from same files on all platforms (e.g. wxNet),
|
||||
add FOO_SRC and FOO_HDR variables with lists of sources and headers.
|
||||
* If wxFoo have no files in common (e.g. wxGL), add FOO_SRC and FOO_HDR
|
||||
with toolkit or platform conditions. Have a look at OPENGL_SRC for an
|
||||
add `FOO_SRC` and `FOO_HDR` variables with lists of sources and headers.
|
||||
* If wxFoo have no files in common (e.g. wxGL), add `FOO_SRC` and `FOO_HDR`
|
||||
with toolkit or platform conditions. Have a look at `OPENGL_SRC` for an
|
||||
example.
|
||||
* Otherwise add FOO_CMN_SRC and FOO_CMN_HDR for common files and
|
||||
FOO_{platform}_{SRC,HDR} or FOO_{toolkit}_{SRC,HDR} as appropriate. Add
|
||||
FOO_PLATFORM_{SRC,HDR} into "Define sources for specific libraries"
|
||||
section that is conditionally set to one of FOO_xxx_{SRC,HDR} based on
|
||||
target platform/toolkit (see NET_PLATFORM_SRC definition for an example).
|
||||
Finally, define FOO_SRC and FOO_HDR to contain both
|
||||
FOO_PLATFORM_{SRC,HDR} and FOO_{SRC,HDR} (see NET_SRC definition for an
|
||||
* Otherwise add `FOO_CMN_SRC` and `FOO_CMN_HDR` for common files and
|
||||
`FOO_{platform}_{SRC,HDR}` or `FOO_{toolkit}_{SRC,HDR}` as appropriate. Add
|
||||
`FOO_PLATFORM_{SRC,HDR}` into "Define sources for specific libraries"
|
||||
section that is conditionally set to one of `FOO_xxx_{SRC,HDR}` based on
|
||||
target platform/toolkit (see `NET_PLATFORM_SRC` definition for an example).
|
||||
Finally, define `FOO_SRC` and `FOO_HDR` to contain both
|
||||
`FOO_PLATFORM_{SRC,HDR}` and `FOO_{SRC,HDR}` (see `NET_SRC` definition for an
|
||||
example).
|
||||
* Add FOO_HDR to ALL_GUI_HEADERS or ALL_BASE_HEADERS.
|
||||
* If wxFoo is wxBase library (doesn't use GUI), add FOO_SRC to
|
||||
ALL_BASE_SOURCES.
|
||||
* Add `FOO_HDR` to `ALL_GUI_HEADERS` or `ALL_BASE_HEADERS`.
|
||||
* If wxFoo is wxBase library (doesn't use GUI), add `FOO_SRC` to
|
||||
`ALL_BASE_SOURCES`.
|
||||
|
||||
(You can apply different approaches to HDR and SRC variables, if e.g.
|
||||
headers are all common but sources are not.)
|
||||
@ -164,38 +173,40 @@ a) Add files to files.bkl:
|
||||
native make tools.
|
||||
|
||||
b) Modify bakefile system in build/bakefiles/ to recognize wxFoo:
|
||||
* Add 'foo' to MAIN_LIBS and LIBS_NOGUI or LIBS_GUI (depending on whether
|
||||
* Add 'foo' to `MAIN_LIBS` and `LIBS_NOGUI` or `LIBS_GUI` (depending on whether
|
||||
the library depends on wxCore or not) to wxwin.py file.
|
||||
* Add extra libraries needed by wxFoo (if any) to EXTRALIBS in wxwin.py
|
||||
* Add WXLIB_FOO definition to common.bkl (into the "Names of component
|
||||
* Add `WXLIB_FOO` definition to common.bkl (into the "Names of component
|
||||
libraries" section). It looks like this:
|
||||
|
||||
<set var="WXLIB_FOO">
|
||||
<if cond="MONOLITHIC=='0'">$(mk.evalExpr(wxwin.mkLibName('foo')))</if>
|
||||
</set>
|
||||
|
||||
c) Modify monolithic.bkl to add files to monolithic build: it's enough to add
|
||||
FOO_SRC to MONOLIB_GUI_SRC or MONOLIB_SRC, depending on whether wxFoo uses
|
||||
`FOO_SRC` to `MONOLIB_GUI_SRC` or `MONOLIB_SRC`, depending on whether wxFoo uses
|
||||
GUI or not.
|
||||
|
||||
d) Modify multilib.bkl to add files to multilib build: add foolib and foodll
|
||||
targets. Don't use wxBase targets as the template, use e.g. wxXML or wxHTML.
|
||||
Make sure WXMAKINGDLL_FOO is defined in foodll.
|
||||
Make sure `WXMAKINGDLL_FOO` is defined in foodll.
|
||||
|
||||
e) Regenerate all makefiles (don't forget to run autoconf)
|
||||
|
||||
f) Update configure.in and wx-config.in to contain information about
|
||||
the library and needed linker flags:
|
||||
* Add "foo" to BUILT_WX_LIBS in configure.in.
|
||||
* Add "foo" to `BUILT_WX_LIBS` in configure.in.
|
||||
* If appropriate, but it rarely is, so normally this should _not_ be done,
|
||||
add "foo" to either STD_BASE_LIBS or STD_GUI_LIBS in configure.in.
|
||||
add "foo" to either `STD_BASE_LIBS` or `STD_GUI_LIBS` in configure.in.
|
||||
* If wxFoo links against additional libraries, add necessary linker
|
||||
flags and libraries to ldflags_foo and ldlibs_foo variables in
|
||||
wx-config.in (both are optional).
|
||||
|
||||
g) Update dlimpexp.h to define WXMAKINGDLL_FOO if WXMAKINGDLL is defined (add
|
||||
#define WXMAKINGDLL_FOO inside first "#ifdef WXMAKINGDLL" block in
|
||||
dlimpexp.h) and to define WXDLLIMPEXP_FOO and WXDLLIMPEXP_DATA_FOO. You
|
||||
can copy e.g. WXDLLIMPEXP_NET definition, it is something like this:
|
||||
g) Update dlimpexp.h to define `WXMAKINGDLL_FOO` if `WXMAKINGDLL` is defined (add
|
||||
`#define WXMAKINGDLL_FOO` inside first `#ifdef WXMAKINGDLL` block in
|
||||
dlimpexp.h) and to define `WXDLLIMPEXP_FOO` and `WXDLLIMPEXP_DATA_FOO`. You
|
||||
can copy e.g. `WXDLLIMPEXP_NET` definition, it is something like this:
|
||||
|
||||
#ifdef WXMAKINGDLL_NET
|
||||
#define WXDLLIMPEXP_NET WXEXPORT
|
||||
#define WXDLLIMPEXP_DATA_NET(type) WXEXPORT type
|
||||
@ -206,10 +217,12 @@ g) Update dlimpexp.h to define WXMAKINGDLL_FOO if WXMAKINGDLL is defined (add
|
||||
#define WXDLLIMPEXP_NET
|
||||
#define WXDLLIMPEXP_DATA_NET(type) type
|
||||
#endif
|
||||
Don't forget to add WXDLLIMPEXP_FWD_FOO definitions too.
|
||||
Use WXDLLIMPEXP_FOO when declaring wxFoo classes and functions.
|
||||
|
||||
Don't forget to add `WXDLLIMPEXP_FWD_FOO` definitions too.
|
||||
Use `WXDLLIMPEXP_FOO` when declaring wxFoo classes and functions.
|
||||
|
||||
h) Add this code to one of wxFoo's files (the more often used, the better):
|
||||
|
||||
// DLL options compatibility check:
|
||||
#include "wx/app.h"
|
||||
WX_CHECK_BUILD_OPTIONS("wxFoo")
|
||||
@ -218,10 +231,7 @@ i) Add information about wxFoo to the manual ("Libraries list" section
|
||||
in libs.tex) and update docs/latex/wx/libs.dia (you need Dia for this)
|
||||
to show the dependencies of the new library.
|
||||
|
||||
j) Also please add 4 #pragma comment(lib, "foo") (for Unicode/ANSI
|
||||
Release/Debug combinations) to the file include/msvc/wx/setup.h and
|
||||
add a check for WXMAKINGDLL_FOO to the test whether we're building a DLL at
|
||||
j) Also please add `#pragma comment(lib, "foo")` (for all build configuration
|
||||
combinations) to the file include/msvc/wx/setup.h and
|
||||
add a check for `WXMAKINGDLL_FOO` to the test whether we're building a DLL at
|
||||
the end of include/wx/msw/chkconf.h.
|
||||
|
||||
=== EOF ===
|
||||
|
||||
@ -1,42 +1,43 @@
|
||||
How to add a new font encoding to wxWidgets
|
||||
===========================================
|
||||
How to add a new font encoding to wxWidgets
|
||||
===========================================
|
||||
|
||||
I. Introduction
|
||||
---------------
|
||||
Introduction
|
||||
------------
|
||||
|
||||
wxWidgets has built in support for a certain number of font encodings (which
|
||||
wxWidgets has built in support for a certain number of font encodings (which
|
||||
is synonymous with code sets and character sets for us here even though it is
|
||||
not exactly the same thing), look at include/wx/fontenc.h for the full list.
|
||||
This list is far from being exhaustive though and if you have enough knowledge
|
||||
about an encoding to add support for it to wxWidgets, this tech note is for
|
||||
you!
|
||||
|
||||
A word of warning though: this is written out of my head and is surely
|
||||
A word of warning though: this is written out of my head and is surely
|
||||
incomplete. Please correct the text here, especially if you detect problems
|
||||
when you try following it.
|
||||
|
||||
Also note that I completely ignore all the difficult issues of support for
|
||||
Also note that I completely ignore all the difficult issues of support for
|
||||
non European languages in the GUI (i.e. BiDi and text orientation support).
|
||||
|
||||
|
||||
II. The receipt
|
||||
---------------
|
||||
The recipe
|
||||
----------
|
||||
|
||||
Suppose you want to add support for Klingon to wxWidgets. This is what you'd
|
||||
have to do:
|
||||
|
||||
1. include/wx/fontenc.h: add a new wxFONTENCODING_KLINGON enum element, if
|
||||
1. include/wx/fontenc.h: add a new `wxFONTENCODING_KLINGON` enum element, if
|
||||
possible without changing the values of the existing elements of the enum
|
||||
and be careful to now make it equal to some other elements -- this means
|
||||
that you have to put it before wxFONTENCODING_MAX
|
||||
that you have to put it before `wxFONTENCODING_MAX`
|
||||
|
||||
2. wxFONTENCODING_MAX must be the same as the number of elements in 3
|
||||
2. `wxFONTENCODING_MAX` must be the same as the number of elements in 3
|
||||
(hopefully) self explanatory arrays in src/common/fmapbase.cpp:
|
||||
a) gs_encodings
|
||||
b) gs_encodingDescs
|
||||
c) gs_encodingNames
|
||||
|
||||
You must update all of them, e.g. you'd add wxFONTENCODING_KLINGON,
|
||||
- gs_encodings
|
||||
- gs_encodingDescs
|
||||
- gs_encodingNames
|
||||
|
||||
You must update all of them, e.g. you'd add `wxFONTENCODING_KLINGON`,
|
||||
"Klingon (Star Trek)" and "klingon" to them in this example. The latter
|
||||
name should ideally be understandable to both Win32 and iconv as it is used
|
||||
to convert to/from this encoding under Windows and Unix respectively.
|
||||
@ -53,15 +54,10 @@ have to do:
|
||||
a) add a new table to src/common/unictabl.inc: note that this file is auto
|
||||
generated so you have to modify misc/unictabl script instead (probably)
|
||||
b) possibly update EquivalentEncodings table in src/common/encconv.cpp
|
||||
if wxFONTENCODING_KLINGON can be converted into another one
|
||||
if `wxFONTENCODING_KLINGON` can be converted into another one
|
||||
(losslessly only or not?)
|
||||
|
||||
4. Add a unit test (see tn0017.txt) for support of your new encoding (with
|
||||
4. Add a [unit test](how-to-write-unit-tests.md) for support of your new encoding (with
|
||||
time we should have a wxCSConv unit test so you would just add a case to
|
||||
it for wxFONTENCODING_KLINGON) and test everything on as many different
|
||||
it for `wxFONTENCODING_KLINGON`) and test everything on as many different
|
||||
platforms as you can.
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: VZ
|
||||
@ -1,5 +1,5 @@
|
||||
How to add a new sample to wxWidgets.
|
||||
=====================================
|
||||
How to add a new sample to wxWidgets.
|
||||
=====================================
|
||||
|
||||
To add a new sample "foo" under directory "samples/foo" you need to do
|
||||
the following: (note that all this applies also to demos: just replace
|
||||
@ -14,31 +14,31 @@ samples/ with demos/ where needed).
|
||||
files in the samples subdirectory.
|
||||
|
||||
3. Create the makefiles:
|
||||
a) modify samples/samples.bkl (just copy an existing line)
|
||||
b) create foo.bkl (sed 's/minimal/foo/g' minimal.bkl > foo.bkl is usually
|
||||
enough, but you may need to add more <wx-lib> lines if your sample uses
|
||||
- modify samples/samples.bkl (just copy an existing line)
|
||||
- create foo.bkl (`sed 's/minimal/foo/g' minimal.bkl > foo.bkl` is usually
|
||||
enough, but you may need to add more `<wx-lib>` lines if your sample uses
|
||||
anything not in the core lib)
|
||||
c) generate the makefiles for your sample using bakefile. For this you
|
||||
- generate the makefiles for your sample using bakefile. For this you
|
||||
need to:
|
||||
(i) install bakefile (see http://bakefile.sf.net/)
|
||||
(ii) run bakefile_gen in build/bakefiles which will regenerate all
|
||||
makefiles which are not up to date
|
||||
- install bakefile (see http://bakefile.sf.net/)
|
||||
- run bakefile_gen in build/bakefiles which will regenerate all
|
||||
makefiles which are not up to date
|
||||
|
||||
You may also use "bakefile_gen -b ../../samples/foo/foo.bkl" to
|
||||
You may also use `bakefile_gen -b ../../samples/foo/foo.bkl` to
|
||||
regenerate only the makefiles for this sample (path must be relative!)
|
||||
or even add a "-f<compiler>" to generate just the makefiles for the given
|
||||
compiler (run 'bakefile --help' to get the list of possible values).
|
||||
See Technote #16 for more information.
|
||||
d) currently samples/samples.dsw needs to be updated manually as it's not
|
||||
or even add a `-f<compiler>` to generate just the makefiles for the given
|
||||
compiler (run `bakefile --help` to get the list of possible values).
|
||||
See how-to-add-files-to-build-system.md for more information.
|
||||
- currently samples/samples.dsw needs to be updated manually as it's not
|
||||
generated by bakefile.
|
||||
|
||||
4. Modify configure.in Unix compilation:
|
||||
a) if the sample should only be built if "wxUSE_FOO" is enabled, locate
|
||||
the test for "wxUSE_FOO = yes" in configure.in and add a line
|
||||
SAMPLES_SUBDIRS="$SAMPLES_SUBDIRS foo" under it
|
||||
b) if it should be always built, locate the line "if test $wxUSE_GUI = yes"
|
||||
- if the sample should only be built if `wxUSE_FOO` is enabled, locate
|
||||
the test for `wxUSE_FOO = yes` in configure.in and add a line
|
||||
`SAMPLES_SUBDIRS="$SAMPLES_SUBDIRS foo"` under it
|
||||
b) if it should be always built, locate the line `if test $wxUSE_GUI = yes`
|
||||
near the end of configure.in and modify the assignment to
|
||||
SAMPLES_SUBDIRS to include "foo" (put in alphabetical order)
|
||||
`SAMPLES_SUBDIRS` to include "foo" (put in alphabetical order)
|
||||
|
||||
After this, regenerate configure from configure.in
|
||||
by running "autoconf" on a Unix system in the corresponding directory.
|
||||
@ -53,7 +53,3 @@ samples/ with demos/ where needed).
|
||||
default, you only need to update it if the sample uses some other files)
|
||||
and run the ./update-manifests.sh script in distrib/scripts (don't forget
|
||||
to check the changes to manifests/*.rsp files in).
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: VZ
|
||||
@ -1,5 +1,5 @@
|
||||
How to add new bitmaps to wxWidgets UI elements
|
||||
===============================================
|
||||
How to add new bitmaps to wxWidgets UI elements
|
||||
===============================================
|
||||
|
||||
0. Introduction
|
||||
---------------
|
||||
@ -21,6 +21,7 @@ when adding new bitmap/icon.
|
||||
|
||||
First of all, you have to add new wxArtID constant to include/wx/artprov.h.
|
||||
Look for "Art IDs" and add new definition to the list, e.g.
|
||||
|
||||
#define wxART_MY_BITMAP wxART_MAKE_ART_ID(wxART_MY_BITMAP)
|
||||
|
||||
Add it to interface/wx/artprov.h, too.
|
||||
@ -30,6 +31,7 @@ of defined client categories (search for "Art clients" in the header). In case
|
||||
the new resource is part of a larger category, you need to define a new
|
||||
client. Just add it to the list of existing clients (and don't forget to
|
||||
update artprov.tex):
|
||||
|
||||
#define wxART_MY_CLIENT wxART_MAKE_CLIENT_ID(wxART_MY_CLIENT)
|
||||
|
||||
Alternatively, you may use wxART_OTHER when accessing the resource if the
|
||||
@ -48,8 +50,8 @@ can be used by users, not only the library.
|
||||
Finally, wxDefaultArtProvider in $(wx)/src/common/artstd.cpp must be updated.
|
||||
This consists of two steps:
|
||||
|
||||
a) add #include line for your XPM file, e.g. #include "../../art/my_bmp.xpm"
|
||||
b) add ART(...) line to wxDefaultArtProvider::CreateBitmap(). The first
|
||||
- add #include line for your XPM file, e.g. #include "../../art/my_bmp.xpm"
|
||||
- add ART(...) line to wxDefaultArtProvider::CreateBitmap(). The first
|
||||
argument is wxArtID, the other is XPM file name (w/o extension), e.g.
|
||||
ART(wxART_MY_BITMAP, my_bmp)
|
||||
|
||||
@ -111,10 +113,7 @@ dialog that displays all available art resources.
|
||||
|
||||
It has to be updated to accommodate for new bitmaps. Fortunately, this is
|
||||
trivial: open $(wx)/samples/artprov/artbrows.cpp in text editor and
|
||||
ART_ICON(wxART_MY_BITMAP) line to the FillBitmaps() function.
|
||||
`ART_ICON(wxART_MY_BITMAP)` line to the FillBitmaps() function.
|
||||
|
||||
Similarly, if you add a new client, please update FillClients() by adding new
|
||||
client to the end of the list.
|
||||
|
||||
=== EOF ===
|
||||
|
||||
@ -1,35 +1,35 @@
|
||||
How to add a new wxUSE_XXX preprocessor constant
|
||||
================================================
|
||||
How to add a new `wxUSE_XXX` preprocessor constant
|
||||
================================================
|
||||
|
||||
0. Purpose
|
||||
----------
|
||||
|
||||
Detailed description of what needs to be done when you want to add a new
|
||||
wxUSE_XXX compilation flag. The text below assumes you need new wxUSE_FOO.
|
||||
`wxUSE_XXX` compilation flag. The text below assumes you need new `wxUSE_FOO`.
|
||||
|
||||
|
||||
1. Overview
|
||||
-----------
|
||||
|
||||
wxWidgets uses wxUSE_XXX macros for conditionally compiling in (or not)
|
||||
wxWidgets uses `wxUSE_XXX` macros for conditionally compiling in (or not)
|
||||
optional components. In general, whenever a new non critical (i.e. not
|
||||
absolutely required by important parts of the library) class Foo is added it
|
||||
should use its own wxUSE_FOO compilation flag.
|
||||
should use its own `wxUSE_FOO` compilation flag.
|
||||
|
||||
wxUSE_FOO must be always defined and have value of 0 or 1. Be careful with
|
||||
`wxUSE_FOO` must be always defined and have value of 0 or 1. Be careful with
|
||||
testing for it in wx/foo.h: don't do it at the very beginning of the file
|
||||
because then wxUSE_FOO would be not defined at all if the user directly
|
||||
includes wx/foo.h, include "wx/defs.h" before testing for wxUSE_FOO.
|
||||
because then `wxUSE_FOO` would be not defined at all if the user directly
|
||||
includes wx/foo.h, include "wx/defs.h" before testing for `wxUSE_FOO`.
|
||||
|
||||
|
||||
2. Files to update
|
||||
------------------
|
||||
|
||||
The following files need to be modified when adding a new wxUSE_FOO:
|
||||
The following files need to be modified when adding a new `wxUSE_FOO`:
|
||||
|
||||
a) include/wx/setup_inc.h
|
||||
|
||||
This file contains all common wxUSE_XXXs, and is used to update wxMSW, wxMac
|
||||
This file contains all common `wxUSE_XXXs`, and is used to update wxMSW, wxMac
|
||||
setup.h and Unix setup.h.in using build/update-setup-h. Please try to add
|
||||
the new define in a logical place (i.e. near any related ones) and write a
|
||||
detailed comment explaining what does it do and why would you want to turn
|
||||
@ -47,11 +47,11 @@ a') include/wx/msw/setup_inc.h for MSW-specific options
|
||||
|
||||
b) include/wx/chkconf.h
|
||||
|
||||
Add the check for wxUSE_FOO definedness in the corresponding (base or GUI)
|
||||
Add the check for `wxUSE_FOO` definedness in the corresponding (base or GUI)
|
||||
section. Please keep the alphabetic order.
|
||||
|
||||
If there are any dependencies, i.e. wxUSE_FOO requires wxUSE_BAR and
|
||||
wxUSE_BAZ, check for thme here too.
|
||||
If there are any dependencies, i.e. `wxUSE_FOO` requires `wxUSE_BAR` and
|
||||
`wxUSE_BAZ`, check for thme here too.
|
||||
|
||||
b') include/wx/msw/chkconf.h for MSW-specific options
|
||||
|
||||
@ -60,7 +60,7 @@ b') include/wx/msw/chkconf.h for MSW-specific options
|
||||
|
||||
c) configure.in
|
||||
|
||||
Here you need to add DEFAULT_wxUSE_FOO define. It should be added in the
|
||||
Here you need to add `DEFAULT_wxUSE_FOO` define. It should be added in the
|
||||
block beginning after WX_ARG_CACHE_INIT line and should default to "no" for
|
||||
"if DEBUG_CONFIGURE = 1" branch (this is used for absolutely minimal builds)
|
||||
and the same as default value in setup_inc.h in the "else" branch.
|
||||
@ -69,15 +69,9 @@ c) configure.in
|
||||
reasonably described as support for a 3rd party library, WX_ARG_WITH)
|
||||
line togetherw with all the existing WX_ARG_ENABLEs.
|
||||
|
||||
If you have a sample/foo which should be only built when wxUSE_FOO==1,
|
||||
then only add it to the SAMPLES_SUBDIRS if wxUSE_FOO=yes in configure.
|
||||
If you have a sample/foo which should be only built when `wxUSE_FOO==1`,
|
||||
then only add it to the SAMPLES_SUBDIRS if `wxUSE_FOO=yes` in configure.
|
||||
|
||||
d) docs/doxygen/mainpages/const_wxusedef.h
|
||||
|
||||
Add a brief description of the new constant.
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: VZ
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
How to add a new XRC handler
|
||||
============================
|
||||
How to add a new XRC handler
|
||||
============================
|
||||
|
||||
0. Purpose
|
||||
----------
|
||||
@ -16,12 +16,12 @@ wxFooXmlHandler and is declared in the file wx/xrc/xh_foo.h (this last rule
|
||||
wasn't always respected in the past, however it's not a reason to not respect
|
||||
it in the future). The steps for adding a new handler are:
|
||||
|
||||
a) Add handler declaration in include/wx/xrc/xh_foo.h, it will usually be the
|
||||
- Add handler declaration in include/wx/xrc/xh_foo.h, it will usually be the
|
||||
same as in the other files so you can get inspiration for your brand new
|
||||
handler from e.g. wx/xrc/xh_srchctrl.h. Notice the use of wxUSE_FOO if wxFoo
|
||||
handler from e.g. wx/xrc/xh_srchctrl.h. Notice the use of `wxUSE_FOO` if wxFoo
|
||||
is guarded by this symbol.
|
||||
|
||||
b) Add implementation in src/xrc/xh_foo.cpp: again, it will be almost always
|
||||
- Add implementation in src/xrc/xh_foo.cpp: again, it will be almost always
|
||||
very similar to the existing controls. You will need to add support for
|
||||
the control-specific styles.
|
||||
|
||||
@ -32,12 +32,12 @@ b) Add implementation in src/xrc/xh_foo.cpp: again, it will be almost always
|
||||
There are a few other files to update to make wxWidgets aware of the new
|
||||
handler:
|
||||
|
||||
a) Add the new files created above to build/bakefiles/files.bkl: search for
|
||||
- Add the new files created above to build/bakefiles/files.bkl: search for
|
||||
"xh_srchctrl" to see where you need to add them
|
||||
|
||||
b) Add #include "wx/xrc/xh_foo.h" to wx/xrc/xh_all.h.
|
||||
- Add #include "wx/xrc/xh_foo.h" to wx/xrc/xh_all.h.
|
||||
|
||||
c) Register the new handler in wxXmlResource::InitAllHandlers() in
|
||||
- Register the new handler in wxXmlResource::InitAllHandlers() in
|
||||
src/xrc/xmlrsall.cpp
|
||||
|
||||
|
||||
@ -46,9 +46,3 @@ c) Register the new handler in wxXmlResource::InitAllHandlers() in
|
||||
|
||||
Demonstrate that the new handler works by adding a control using it to
|
||||
samples/xrc/rc/controls.xrc.
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: VZ
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Making a new wxWidgets release
|
||||
==============================
|
||||
Making a new wxWidgets release
|
||||
==============================
|
||||
|
||||
Before making the release
|
||||
-------------------------
|
||||
@ -27,14 +27,14 @@ section.
|
||||
Follow these steps assuming the current working directory is the root of git
|
||||
working copy and you want to prepare distribution for the version x.y.z:
|
||||
|
||||
1. Run "./build/tools/svn-find-native-eols.pl > ../eol-native" (if you have
|
||||
1. Run `./build/tools/svn-find-native-eols.pl > ../eol-native` (if you have
|
||||
an existing svn checkout, pass it to the script to make it run much faster,
|
||||
but take care to have up to date sources in the working tree).
|
||||
|
||||
2. Run "./build/tools/git-make-release x.y.z" to create source archives
|
||||
2. Run `./build/tools/git-make-release x.y.z` to create source archives
|
||||
../wxWidgets-x.y.z.{7z,tar.bz2,zip} and wxWidgets_x.y.z_Headers.zip.
|
||||
|
||||
3. Run "./build/tools/make-html-docs x.y.z" to create HTML documentation
|
||||
3. Run `./build/tools/make-html-docs x.y.z` to create HTML documentation
|
||||
archives ../wxWidgets-x.y.z.{tar.bz2,zip}
|
||||
|
||||
4. This step must be done under Windows as it relies on having hhc.exe, the
|
||||
@ -1,5 +1,5 @@
|
||||
How to update a third party library to a newer version
|
||||
======================================================
|
||||
How to update a third party library to a newer version
|
||||
======================================================
|
||||
|
||||
0. Introduction
|
||||
---------------
|
||||
@ -1,5 +1,5 @@
|
||||
How to write unit tests for wxWidgets
|
||||
=====================================
|
||||
How to write unit tests for wxWidgets
|
||||
=====================================
|
||||
|
||||
Unit tests for wxWidgets are written using small cppunit framework. To compile
|
||||
(but not to run) them you need to have it installed. Hence the first part of
|
||||
@ -13,13 +13,13 @@ I. CppUnit Installation
|
||||
(latest version as of the time of this writing is 1.10.2)
|
||||
|
||||
2. Build the library:
|
||||
a) Under Windows using VC++:
|
||||
- Under Windows using VC++:
|
||||
- build everything in CppUnitLibraries.dsw work space
|
||||
- add include and lib subdirectories of the directory
|
||||
where you installed cppunit to the compiler search path
|
||||
using "Tools|Options" menu in VC IDE
|
||||
|
||||
b) Under Unix: run configure && make && make install as usual
|
||||
- Under Unix: run `configure && make && make install` as usual
|
||||
|
||||
|
||||
II. Writing tests with CppUnit
|
||||
@ -29,9 +29,12 @@ II. Writing tests with CppUnit
|
||||
|
||||
2. Write a cpp file for the test copying, if you want,
|
||||
from one of the existing tests. The things to look for:
|
||||
|
||||
a) #include "wx/cppunit.h" instead of directly including CppUnit headers
|
||||
|
||||
b) don't put too many things in one test case nor in one method of a test
|
||||
case as it makes understanding what exactly failed harder later
|
||||
|
||||
c) 'register' your tests as follows so that the test program will find and
|
||||
execute them:
|
||||
|
||||
@ -42,6 +45,7 @@ II. Writing tests with CppUnit
|
||||
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION(MBConvTestCase, "MBConvTestCase");
|
||||
|
||||
Read CppUnit documentation for more.
|
||||
|
||||
d) wxUIActionSimulator can be used when user input is required, for example
|
||||
clicking buttons or typing text. A simple example of this can be found
|
||||
in controls/buttontest.cpp. After simulating some user input always
|
||||
@ -49,9 +53,10 @@ II. Writing tests with CppUnit
|
||||
wxUIActionSimulator always add the test using WXUISIM_TEST rather than
|
||||
CPPUNIT_TEST as then it won't run on unsupported platforms. The test itself
|
||||
must also be wrapped in a #if wxUSE_UIACTIONSIMULATOR block.
|
||||
|
||||
e) There are a number of classes that are available to help with testing GUI
|
||||
elements. Firstly throughout the test run there is a frame of type
|
||||
wxTestableFrame that you can access through wxTheApp->GetTopWindow(). This
|
||||
wxTestableFrame that you can access through `wxTheApp->GetTopWindow()`. This
|
||||
class adds two new functions, GetEventCount, which takes an optional
|
||||
wxEventType. It then returns the number of events of that type that it has
|
||||
received since the last call. Passing nothing returns the total number of
|
||||
@ -62,9 +67,9 @@ II. Writing tests with CppUnit
|
||||
event type. It disconnects again once it is out of scope. It simply reduces
|
||||
the amount of typing required to count events.
|
||||
|
||||
3. add a '<sources>' tag for your source file to tests/test.bkl. Make sure it's
|
||||
in the correct section: the one starting '<exe id="test_gui"' for a gui test,
|
||||
the one starting '<exe id="test" template="wx_sample_console' otherwise.
|
||||
3. add a `<sources>` tag for your source file to tests/test.bkl. Make sure it's
|
||||
in the correct section: the one starting `<exe id="test_gui"` for a gui test,
|
||||
the one starting `<exe id="test" template="wx_sample_console` otherwise.
|
||||
|
||||
|
||||
III. Running the tests
|
||||
@ -137,8 +142,3 @@ IV. Notes
|
||||
instead of the unnamed registry. The default suite should execute reasonably
|
||||
quickly. To run the default and advanced tests together:
|
||||
test "" advanced
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: VZ & MW
|
||||
@ -1,5 +1,5 @@
|
||||
wxWidgets translator guide
|
||||
==========================
|
||||
wxWidgets translator guide
|
||||
==========================
|
||||
|
||||
This note is addressed to wxWidgets translators.
|
||||
|
||||
@ -73,30 +73,3 @@ in wx.bkl:
|
||||
<linguas>it</linguas>
|
||||
<install-to>$(LOCALEDIR)</install-to>
|
||||
</gettext-catalogs>
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: VZ
|
||||
|
||||
$Log$
|
||||
Revision 1.7 2005/08/12 15:34:01 MW
|
||||
Typo
|
||||
|
||||
Revision 1.6 2005/08/12 15:29:47 MW
|
||||
Translate '&Help' to '&' for italian Windows only
|
||||
|
||||
Revision 1.5 2004/10/22 19:12:59 KH
|
||||
*** empty log message ***
|
||||
|
||||
Revision 1.4 2004/05/04 08:26:58 JS
|
||||
Name change replacements
|
||||
|
||||
Revision 1.3 2003/11/18 16:37:11 DS
|
||||
Updated translation technote to mention Makefile usage under Windows.
|
||||
|
||||
Revision 1.2 2002/07/03 15:01:26 VZ
|
||||
typos and other doc corrections from Olly Betts (patch 573738)
|
||||
|
||||
Revision 1.1 2000/03/07 10:53:53 VZ
|
||||
technote about translations added
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Special notes about writing wxMSW code
|
||||
======================================
|
||||
Special notes about writing wxMSW code
|
||||
======================================
|
||||
|
||||
0. Purpose
|
||||
----------
|
||||
@ -14,12 +14,12 @@ doesn't cover any wxWidgets-wide issues not specific to Windows.
|
||||
1. Windows headers wrappers
|
||||
---------------------------
|
||||
|
||||
In no event should the Windows headers such as <windows.h> or <commctrl.h> be
|
||||
included directly. So instead of #include <...> use "wx/msw/wrapwin.h" or
|
||||
"wx/msw/wrapcctl.h".
|
||||
In no event should the Windows headers such as `<windows.h>` or `<commctrl.h>` be
|
||||
included directly. So instead of `#include <...>` use `"wx/msw/wrapwin.h"` or
|
||||
`wx/msw/wrapcctl.h`.
|
||||
|
||||
For convenience it is also possible to replace #include <commdlg.h> and
|
||||
<shlobj.h> with #include "wx/msw/wrapcdlg.h" and wrapshl.h but this is less
|
||||
For convenience it is also possible to replace `#include <commdlg.h>` and
|
||||
`<shlobj.h>` with `#include "wx/msw/wrapcdlg.h"` and `wrapshl.h` but this is less
|
||||
vital.
|
||||
|
||||
Also notice that many convenient (albeit undocumented) functions and classes
|
||||
@ -46,8 +46,3 @@ Windows versions should be resolved dynamically, i.e. using wxDynamicLibrary as
|
||||
otherwise any wx application -- even not needing them at all -- would refuse to
|
||||
start up on Windows versions not implementing the feature in question. As an
|
||||
example, look at AlphaBlt()-related code in src/msw/dc.cpp.
|
||||
|
||||
|
||||
=== EOF ===
|
||||
|
||||
Author: VZ
|
||||
@ -3,9 +3,9 @@ just to avoid breaking the existing links to them, please refer to the files
|
||||
with the corresponding name under docs/contributing instead:
|
||||
|
||||
|
||||
tn0001.txt -> docs/contributing/how-to-add-new-sample.txt
|
||||
tn0002.txt -> docs/contributing/translators-guide.txt
|
||||
tn0003.txt -> docs/contributing/how-to-add-class-documentation.txt
|
||||
tn0001.txt -> docs/contributing/how-to-add-new-sample.md
|
||||
tn0002.txt -> docs/contributing/translators-guide.md
|
||||
tn0003.txt -> docs/contributing/how-to-add-class-documentation.md
|
||||
tn0004.htm -> *** REMOVED *** (obsoleted by Bakefile changes)
|
||||
tn0005.txt -> *** REMOVED *** (obsoleted by http://wiki.wxwidgets.org/Development:_How_To_Contribute)
|
||||
tn0006.txt -> *** REMOVED *** (obsoleted by tn0013.txt)
|
||||
@ -13,19 +13,19 @@ tn0007.txt -> *** REMOVED *** (obsoleted by Bakefile changes)
|
||||
tn0008.htm -> *** REMOVED *** (included in the manual now)
|
||||
tn0009.htm -> *** REMOVED *** (use any standard tool for icon creation)
|
||||
tn0010.htm -> *** REMOVED *** (obsoleted by Bakefile changes)
|
||||
tn0011.txt -> docs/contributing/about-version-numbers.txt
|
||||
tn0012.txt -> docs/contributing/about-platform-toolkit-and-library-names.txt
|
||||
tn0011.txt -> docs/contributing/about-version-numbers.md
|
||||
tn0012.txt -> docs/contributing/about-platform-toolkit-and-library-names.md
|
||||
tn0013.txt -> *** REMOVED *** (obsoleted by tn0022.txt)
|
||||
tn0014.txt -> *** REMOVED *** (included in the manual now)
|
||||
tn0015.txt -> docs/contributing/how-to-add-new-ui-bitmaps.txt
|
||||
tn0016.txt -> docs/contributing/how-to-add-files-to-build-system.txt
|
||||
tn0017.txt -> docs/contributing/how-to-write-unit-tests.txt
|
||||
tn0018.txt -> docs/contributing/how-to-add-new-font-encoding.txt
|
||||
tn0019.txt -> docs/contributing/wxmsw-contributor-guide.txt
|
||||
tn0020.txt -> docs/contributing/binary-compatibility.txt
|
||||
tn0021.txt -> docs/contributing/how-to-add-new-wxUSE_XXX.txt
|
||||
tn0022.txt -> docs/contributing/how-to-release.txt
|
||||
tn0015.txt -> docs/contributing/how-to-add-new-ui-bitmaps.md
|
||||
tn0016.txt -> docs/contributing/how-to-add-files-to-build-system.md
|
||||
tn0017.txt -> docs/contributing/how-to-write-unit-tests.md
|
||||
tn0018.txt -> docs/contributing/how-to-add-new-font-encoding.md
|
||||
tn0019.txt -> docs/contributing/wxmsw-contributor-guide.md
|
||||
tn0020.txt -> docs/contributing/binary-compatibility.md
|
||||
tn0021.txt -> docs/contributing/how-to-add-new-wxUSE_XXX.md
|
||||
tn0022.txt -> docs/contributing/how-to-release.md
|
||||
tn0023.txt -> *** REMOVED *** (obsoleted by web site redesign)
|
||||
tn0024.txt -> docs/contributing/how-to-add-new-xrc-handler.txt
|
||||
tn0025.txt -> docs/contributing/how-to-update-third-party-library.txt
|
||||
tn0024.txt -> docs/contributing/how-to-add-new-xrc-handler.md
|
||||
tn0025.txt -> docs/contributing/how-to-update-third-party-library.md
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user