| 1 | |
| 2 | <HTML> |
| 3 | |
| 4 | <HEAD> |
| 5 | <TITLE>wxWidgets FAQ: General</TITLE> |
| 6 | </HEAD> |
| 7 | |
| 8 | <BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063"> |
| 9 | |
| 10 | <font face="Arial, Lucida Sans, Helvetica"> |
| 11 | |
| 12 | <table width=100% border=0 cellpadding=3 cellspacing=0> |
| 13 | <tr> |
| 14 | <td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif"> |
| 15 | <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> |
| 16 | <b>wxWidgets FAQ: General</b> |
| 17 | </font> |
| 18 | </td> |
| 19 | </tr> |
| 20 | </table> |
| 21 | |
| 22 | <P> |
| 23 | |
| 24 | See also <a href="faq.htm">top-level FAQ page</a>. |
| 25 | <hr> |
| 26 | <h3>List of questions in this category</h3> |
| 27 | <ul> |
| 28 | <li><a href="#whatis">What is wxWidgets?</a></li> |
| 29 | <li><a href="#licence">Can I use wxWidgets for both proprietary projects, and GPL'ed projects?</a></li> |
| 30 | <li><a href="#support">Is there support?</a></li> |
| 31 | <li><a href="#users">Who uses wxWidgets?</a></li> |
| 32 | <li><a href="#platforms">What platforms are supported by wxWidgets?</a></li> |
| 33 | <li><a href="#specific">How does wxWidgets support platform-specific features?</a></li> |
| 34 | <li><a href="#stl">Does wxWidgets use STL? or the standard string class?</a></li> |
| 35 | <li><a href="#richedit">Is there a rich edit/markup widget for wxWidgets?</a></ li> |
| 36 | <li><a href="#exceptions">How to use C++ exceptions with wxWidgets?</a></ li> |
| 37 | <li><a href="#dev">How is wxWidgets being developed?</a></li> |
| 38 | <li><a href="#distrib">How is wxWidgets distributed?</a></li> |
| 39 | <!-- |
| 40 | <li><a href="#future">What are the plans for the future?</a></li> |
| 41 | --> |
| 42 | <li><a href="#base">What is wxBase?</a></li> |
| 43 | <li><a href="#univ">What is wxUniversal?</a></li> |
| 44 | <li><a href="#jave">What about Java?</a></li> |
| 45 | <li><a href="#dotnet">What about .NET/Mono?</a></li> |
| 46 | <li><a href="#help">How can I help the project?</a></li> |
| 47 | <li><a href="#newport">How do I start a new port?</a></li> |
| 48 | </ul> |
| 49 | <hr> |
| 50 | |
| 51 | <H3><a name="whatis">What is wxWidgets?</a></H3> |
| 52 | |
| 53 | wxWidgets is a class library that allows you to compile graphical C++ programs on a range of |
| 54 | different platforms. wxWidgets defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform, |
| 55 | so your program will take on the native 'look and feel' that users are familiar with.<P> |
| 56 | |
| 57 | Although GUI applications are mostly built programmatically, there are several dialog editors to help |
| 58 | build attractive dialogs and panels. Robert Roebling's <a href="http://www.roebling.com">wxDesigner</a> |
| 59 | and Anthemion Software's <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a> |
| 60 | are two commercial examples, but there are others: see the <a href="lnk_tool.htm">Useful Tools</a> page.<P> |
| 61 | |
| 62 | You don't have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets, |
| 63 | and also a <a href="http://wxperl.sourceforge.net" target=_top>Perl interface</a>. |
| 64 | <P> |
| 65 | |
| 66 | <h3><a name="licence">Can I use wxWidgets for both proprietary (commercial) projects, and GPL'ed projects?</a></h3> |
| 67 | |
| 68 | Yes. Please see the <a href="newlicen.htm">licence</a> for details, but basically |
| 69 | you can distribute proprietary binaries without distributing any source code, and neither will wxWidgets |
| 70 | conflict with GPL code you may be using or developing with it. |
| 71 | <P> |
| 72 | The conditions for using wxWidgets are the same whether you are a personal, academic |
| 73 | or commercial developer. |
| 74 | <P> |
| 75 | |
| 76 | <h3><a name="support">Is there support?</a></h3> |
| 77 | |
| 78 | No official support, but the mailing list is very helpful and some people say that |
| 79 | wxWidgets support is better than for much commercial software. The developers are |
| 80 | keen to fix bugs as soon as possible, though obviously there are no guarantees. |
| 81 | <P> |
| 82 | |
| 83 | <H3><a name="users">Who uses wxWidgets?</a></H3> |
| 84 | |
| 85 | Many organisations - commercial, government, and academic - across the |
| 86 | world. It's impossible to estimate the true number of users, since |
| 87 | wxWidgets is obtained by many different means, and we cannot monitor |
| 88 | distribution. The mailing list contains around 300-400 entries which is |
| 89 | quite large for a list of this type.<P> |
| 90 | |
| 91 | See <a href="users.htm">Users</a> for a list of some users and their applications, and |
| 92 | also <A href="feedback.htm">Feedback</a> for comments.<P> |
| 93 | Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch Kapor |
| 94 | and his <a href="http://www.osafoundation.org" target=_new>Open Source Applications Foundation</a>. |
| 95 | <P> |
| 96 | |
| 97 | <H3><a name="platforms">What platforms are supported by wxWidgets?</a></H3> |
| 98 | |
| 99 | <ul> |
| 100 | <li>Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME. |
| 101 | <li>Linux and other Unix platforms with GTK+. |
| 102 | <li>Unix with Motif or the free Motif clone Lesstif. |
| 103 | <li>Mac OS. |
| 104 | <li>Embedded platforms are being investigated. See the <a href="wxuniv.htm">wxUniversal</a> project. |
| 105 | <li>An OS/2 port is in progress, and you can also compile wxWidgets for GTK+ or Motif |
| 106 | on OS/2. |
| 107 | </ul> |
| 108 | <P> |
| 109 | |
| 110 | <H3><a name="specific">How does wxWidgets support platform-specific |
| 111 | features?</a></H3> |
| 112 | |
| 113 | This is a hotly-debated topic amongst the developers. My own philosophy |
| 114 | is to make wxWidgets as platform-independent as possible, but allow in a |
| 115 | few classes (functions, window styles) that are platform-specific. |
| 116 | For example, Windows metafiles and Windows 95 taskbar icons have |
| 117 | their own classes on Windows, but nowhere else. Because these classes |
| 118 | are provided and are wxWidgets-compatible, it doesn't take much |
| 119 | coding effort for an application programmer to add support for |
| 120 | some functionality that the user on a particular platform might otherwise |
| 121 | miss. Also, some classes that started off as platform-specific, such |
| 122 | as the MDI classes, have been emulated on other platforms. I can imagine |
| 123 | that even wxTaskBarIcon may be implemented for Unix desktops one day. |
| 124 | <P> |
| 125 | |
| 126 | In other words, wxWidgets is not a 'lowest common denominator' approach, |
| 127 | but it will still be possible to write portable programs using the |
| 128 | core API. Forbidding some platform-specific classes would be a stupid |
| 129 | approach that would alienate many potential users, and encourage |
| 130 | the perception that toolkits such as wxWidgets are not up to the demands |
| 131 | of today's sophisticated applications.<P> |
| 132 | |
| 133 | Currently resources such as bitmaps and icons are handled in a platform-specific |
| 134 | way, but it is hoped to reduce this dependence in due course.<P> |
| 135 | |
| 136 | Another reason why wxWidgets is not a 'lowest common denominator' toolkit is that |
| 137 | some functionality missing on some platform has been provided using generic, |
| 138 | platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.<P> |
| 139 | |
| 140 | <H3><a name="stl">Does wxWidgets use STL? or the standard string class?</a></H3> |
| 141 | |
| 142 | No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in |
| 143 | wxWidgets' best interests to avoid use of templates. Not all compilers can handle |
| 144 | templates adequately so it would dramatically reduce the number of compilers |
| 145 | and platforms that could be supported. It would also be undesirable to make |
| 146 | wxWidgets dependent on another large library that may have to be downloaded and installed. |
| 147 | In addition, use of templates can lead to executable bloat, which is something |
| 148 | wxWidgets is strenuously trying to avoid.<P> |
| 149 | |
| 150 | The standard C++ string class is not used, again because it is not available to all compilers, |
| 151 | and it is not necessarily a very efficient implementation. Also, we retain more flexibility |
| 152 | by being able to modify our own string class. Some compatibility with the string class |
| 153 | has been built into wxString.<P> |
| 154 | |
| 155 | There is nothing to stop an application using templates or the string class for its own |
| 156 | purposes. With wxWidgets debugging options on, you may find you get errors when including |
| 157 | STL headers. You can work around it either by switching off memory checking, |
| 158 | or by adding this to a header before you include any STL files:<P> |
| 159 | |
| 160 | <PRE> |
| 161 | #ifdef new |
| 162 | #undef new |
| 163 | #endif |
| 164 | </PRE> |
| 165 | |
| 166 | <P> |
| 167 | |
| 168 | |
| 169 | <H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets?</a></H3> |
| 170 | |
| 171 | These are the possibilities so far:<P> |
| 172 | |
| 173 | <ul> |
| 174 | <li>See <a href="http://www.scintilla.org" target=_top>www.scintilla.org</a> for |
| 175 | a very nice syntax-highlighting editor widget. Robin Dunn has written a wxWidgets wrapper |
| 176 | for this widget, available in the wxWidgets distribution under contrib/src/stc. |
| 177 | <li>If you only need to display marked-up information, rather than edit it, |
| 178 | then wxHTML will suit your needs. wxHTML is built into wxWidgets - please see the reference |
| 179 | manual for details, and samples/html. |
| 180 | <li>There are rich edit widgets in both WIN32 and GTK+, but there is currently |
| 181 | no wxWidgets wrapper for these (but text attribute functions are being added in the wxWidgets 2.3.x series). |
| 182 | </ul> |
| 183 | |
| 184 | <P> |
| 185 | |
| 186 | <h3><a name="exceptions">How to use C++ exceptions with wxWidgets?</a></h3> |
| 187 | |
| 188 | wxWidgets library itself is unfortunately <i>not</i> exception-safe (as its |
| 189 | initial version predates, by far, the addition of the exceptions to the C++ |
| 190 | language). However you can still use the exceptions in your own code and use |
| 191 | the other libraries using the exceptions for the error reporting together with |
| 192 | wxWidgets. |
| 193 | |
| 194 | <p> |
| 195 | There are a few issues to keep in mind, though: |
| 196 | <ul> |
| 197 | <li>You shouldn't let the exceptions propagate through wxWidgets code, |
| 198 | in particular you should always catch the exceptions thrown by the |
| 199 | functions called from an event handler in the handler itself and not |
| 200 | let them propagate upwards to wxWidgets. |
| 201 | |
| 202 | <li>You may need to ensure that the compiler support for the exceptions is |
| 203 | enabled as, considering that wxWidgets itself doesn't use the |
| 204 | exceptions and turning their support on results in the library size |
| 205 | augmentation of 10% to 20%, it is turned off by default for a few |
| 206 | compilers. Moreover, for gcc (or at least its mingw version) you must |
| 207 | also turn on the RTTI support to be able to use the exceptions, so you |
| 208 | should use <tt>--disable-no_rtti --disable-no_exceptions</tt> options |
| 209 | when configuring the library (attention to the double negation). |
| 210 | </ul> |
| 211 | |
| 212 | <p> |
| 213 | |
| 214 | <H3><a name="dev">How is wxWidgets being developed?</a></H3> |
| 215 | |
| 216 | We are using the <a href="cvs.htm">CVS</a> system to develop and maintain wxWidgets. This allows |
| 217 | us to make alterations and upload them instantly to the server, from |
| 218 | which others can update their source.<P> |
| 219 | |
| 220 | To build source from CVS, see the file BuildCVS.txt in the top-level wxWidgets distribution |
| 221 | directory.<P> |
| 222 | |
| 223 | <H3><a name="distrib">How is wxWidgets distributed?</a></H3> |
| 224 | |
| 225 | By ftp, and via the <a href="cdrom2.htm">wxWidgets CD-ROM</a>. |
| 226 | <P> |
| 227 | If you are feeling adventurous, you may also check out the sources directly |
| 228 | from <a href="cvs.htm">cvs</a>. |
| 229 | <p> |
| 230 | |
| 231 | <!-- |
| 232 | <H3><a name="future">What are the plans for the future?</a></H3> |
| 233 | |
| 234 | TODO |
| 235 | |
| 236 | <p> |
| 237 | |
| 238 | --> |
| 239 | |
| 240 | <h3><a name="base">What is wxBase?</a></h3> |
| 241 | |
| 242 | wxBase is a subset of wxWidgets comprised by the non-GUI classes. It includes |
| 243 | wxWidgets container and primitive data type classes (including wxString, |
| 244 | wxDateTime and so on) and also useful wrappers for the operating system objects |
| 245 | such as files, processes, threads, sockets and so on. With very minor |
| 246 | exceptions wxBase may be used in exactly the same way as wxWidgets but it |
| 247 | doesn't require a GUI to run and so is ideal for creating console mode |
| 248 | utilities or server programs. It is also possible to create a program which can |
| 249 | be compiled either as a console application (using wxBase) or a GUI one (using |
| 250 | a full featured wxWidgets port). |
| 251 | |
| 252 | <H3><a name="univ">What is wxUniversal?</a></H3> |
| 253 | |
| 254 | The main difference between wxUniversal-based ports (such as wxX11, wxMGL) and other ports (such as wxMSW, wxGTK+, wxMac) |
| 255 | is that wxUniversal implements all controls (or widgets) in |
| 256 | wxWidgets itself thus allowing to have much more flexibility (for example, support for |
| 257 | themes even under MS Windows). It also means that it is now much easier to |
| 258 | port wxWidgets to a new platform as only the low-level classes must be ported |
| 259 | which make for a small part of the library. |
| 260 | <p> |
| 261 | You may find more about wxUniversal <a href=wxuniv.htm>here</a>. |
| 262 | |
| 263 | <H3><a name="jave">What about Java?</a></H3> |
| 264 | |
| 265 | The Java honeymoon period is over :-) and people are realising that it cannot |
| 266 | meet all their cross-platform development needs. We don't anticipate a major threat |
| 267 | from Java, and the level of interest in wxWidgets is as high as ever.<P> |
| 268 | |
| 269 | <H3><a name="dotnet">What about .NET/Mono?</a></H3> |
| 270 | |
| 271 | Microsoft is spending a lot on promoting the .NET initiative, which |
| 272 | is a set of languages, APIs and web service components for Windows. |
| 273 | Ximian has started an open source version of .NET, mostly for Linux. |
| 274 | C# is Microsoft's alternative to Java, supporting 'managed code', |
| 275 | garbage collection and various other Java-like language features.<P> |
| 276 | |
| 277 | Although this may be attractive to some developers, there |
| 278 | is a variety of reasons why the .NET/Mono combination is unlikely |
| 279 | to make wxWidgets redundant. Please note that the following comments |
| 280 | are Julian Smart's opinions.<P> |
| 281 | |
| 282 | <ol> |
| 283 | <li>Not everyone wants or needs net services. |
| 284 | <li>C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain. |
| 285 | <li>Mono Forms may only target Winelib (at least to begin with), so the end result is not as native as |
| 286 | wxWidgets (I'm aware there is GTK# for use with the C# language). |
| 287 | <li>C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer |
| 288 | that wxWidgets does not require. |
| 289 | <li>Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now. |
| 290 | <li>You may not wish to buy into Microsoft marketing spin and APIs. |
| 291 | <li>Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all, |
| 292 | platform-independence is not in Microsoft's interest. |
| 293 | <li>.NET might never be implemented on some platforms, especially Mac and embedded variants of Linux. |
| 294 | <li>wxPython and other language variants provide further reasons for wxWidgets to continue. |
| 295 | <li>The same issue exists for Qt: if Qt sales remain strong, it's a good indication that |
| 296 | the market for a C++-based approach is still there. (Either that, or everyone's turning to wxWidgets!) |
| 297 | </ol> |
| 298 | |
| 299 | There is nothing to stop folk from developing a C# version of the wxWidgets API; |
| 300 | we already have bindings to Python, Perl, JavaScript, Lua, Basic, and Eiffel. |
| 301 | Update: a <a href="http://wxnet.sourceforge.net/" target=_new>wx.NET</a> project is now in progress. |
| 302 | |
| 303 | <P> |
| 304 | |
| 305 | <H3><a name="help">How can I help the project?</a></H3> |
| 306 | |
| 307 | Please check out the <a href="http://www.wxwidgets.org/develop2.htm">Community</a> pages, |
| 308 | in particular the <a href="projects.htm">suggested projects</a>, and |
| 309 | mail the developers' mailing list with your own suggestions.<P> |
| 310 | |
| 311 | <H3><a name="newport">How do I start a new port?</a></H3> |
| 312 | |
| 313 | Please subscribe to the wx-dev <a href="maillst2.htm">developers' mailing list</a> and |
| 314 | ask if anyone else is interested in helping with the port, or |
| 315 | has specific suggestions. Also please read the <a href="standard.htm">coding standards</a>. |
| 316 | |
| 317 | <P> |
| 318 | Each port consists of a platform-specific part (e.g. src/msw, include/wx/msw), |
| 319 | a generic set of widgets and dialogs for when the port doesn't support |
| 320 | them natively (src/generic, include/wx/generic) and the common code |
| 321 | that all ports use (src/common, include/wx). By browsing the source |
| 322 | you should get a good idea of the general pattern.<P> |
| 323 | |
| 324 | Take a port that most closely matches your port, and strip out |
| 325 | the implementation so you have a skeleton port that compiles. Ask on wx-dev |
| 326 | first for the wxStubs port - however, any such predefined skeleton |
| 327 | port may be out of date, so make a judgement on whether to use it. |
| 328 | Perhaps it will still save you time to clean up wxStubs, and |
| 329 | others may benefit from this too.<P> |
| 330 | |
| 331 | You will need to define a symbol for the new port, e.g. __WXXBOX__. |
| 332 | Look at files such as wx/defs.h, wx/wxchar.h for areas where you'll |
| 333 | need to add to existing conditionals to set up wide character |
| 334 | support and other issues. If the GUI runs on a Unix variant, |
| 335 | define the __UNIX__ variable in your makefile.<P> |
| 336 | |
| 337 | Then you can start implementing the port, starting with |
| 338 | wxWindow, wxTopLevelWindow, wxFrame, wxDialog so you |
| 339 | can get the minimal sample running as soon as possible.<P> |
| 340 | |
| 341 | If GDI objects (wxPen, wxBrush, etc.) are not concepts in your |
| 342 | native GUI, you may wish to use very generic versions of |
| 343 | some of these - see the wxX11 port.<P> |
| 344 | |
| 345 | Consider using the wxUniversal widget set as a quick way |
| 346 | to implement wxWidgets on your platform. You only need |
| 347 | to define some basic classes such as device contexts, |
| 348 | wxWindow, wxTopLevelWindow, GDI objects etc. and |
| 349 | the actual widgets will be drawn for you. See wxX11, |
| 350 | wxMGL, and wxMSW/Univ for sample wxUniversal ports.<P> |
| 351 | |
| 352 | To begin with, you can use whatever makefiles or project |
| 353 | files work for you. Look at existing makefiles to see what |
| 354 | generic/common/Unix files need to be included. Later, you'll want to integrate support |
| 355 | for your port into configure (Unix-like systems and gcc under Windows), |
| 356 | and bakefile (for other makefiles on Windows).<P> |
| 357 | |
| 358 | Submit your port as patches via SourceForge; you might |
| 359 | wish to separate it into one patch that touches common headers |
| 360 | and source files, and another containing the port-specific code, to make |
| 361 | it much easier for us to review and apply the patches.<P> |
| 362 | |
| 363 | Good luck! |
| 364 | |
| 365 | </font> |
| 366 | |
| 367 | </BODY> |
| 368 | |
| 369 | </HTML> |