| | 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> |
projects / wxWidgets.git / blame_incremental