| | 1 | <HTML> |
| | 2 | |
| | 3 | <HEAD> |
| | 4 | <TITLE>wxWindows 2 FAQ: General</TITLE> |
| | 5 | </HEAD> |
| | 6 | |
| | 7 | <BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000> |
| | 8 | |
| | 9 | <font face="Arial, Lucida Sans, Helvetica"> |
| | 10 | |
| | 11 | <table width=100% border=4 cellpadding=5 cellspacing=0> |
| | 12 | <tr> |
| | 13 | <td bgcolor="#660000"> |
| | 14 | <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> |
| | 15 | wxWindows 2 FAQ: General |
| | 16 | </font> |
| | 17 | </td> |
| | 18 | </tr> |
| | 19 | </table> |
| | 20 | |
| | 21 | <P> |
| | 22 | |
| | 23 | See also <a href="faq.htm">top-level FAQ page</a>. |
| | 24 | <hr> |
| | 25 | |
| | 26 | <H3><a name="whatis">What is wxWindows?</a></H3> |
| | 27 | |
| | 28 | wxWindows is a class library that allows you to compile graphical C++ programs on a range of |
| | 29 | different platforms. wxWindows defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform, |
| | 30 | so your program will take on the native 'look and feel' that users are familiar with.<P> |
| | 31 | |
| | 32 | Although GUI applications are mostly built programmatically, there is a dialog editor to help |
| | 33 | build attractive dialogs and panels.<P> |
| | 34 | |
| | 35 | You don't have to use C++ to use wxWindows: wxWindows 1 has been interfaced to several interpreted languages, |
| | 36 | such as CLIPS, Python, Scheme, XLisp and Perl, and there is a Python interface for wxWindows 2. |
| | 37 | <P> |
| | 38 | |
| | 39 | <h3>Can I use wxWindows 2 for both proprietary (commercial) projects, and GPL'ed projects?</h3> |
| | 40 | |
| | 41 | Yes. Please see the <a href="newlicen.htm">licence</a> for details, but basically |
| | 42 | you can distribute proprietary binaries without distributing any source code, and neither will wxWindows |
| | 43 | conflict with GPL code you may be using or developing with it. |
| | 44 | <P> |
| | 45 | The conditions for using wxWindows 2 are the same whether you are a personal, academic |
| | 46 | or commercial developer. |
| | 47 | <P> |
| | 48 | |
| | 49 | <h3>Is there support?</h3> |
| | 50 | |
| | 51 | No official support, but the mailing list is very helpful and some people say that |
| | 52 | wxWindows support is better than for much commercial software. The developers are |
| | 53 | keen to fix bugs as soon as possible, though obviously there are no guarantees. |
| | 54 | <P> |
| | 55 | |
| | 56 | <H3><a name="users">Who uses wxWindows?</a></H3> |
| | 57 | |
| | 58 | Many organisations - commercial, government, and academic - across the |
| | 59 | world. It's impossible to estimate the true number of users, since |
| | 60 | wxWindows is obtained by many different means, and we cannot monitor |
| | 61 | distribution. The mailing list contains around 300-400 entries which is |
| | 62 | quite large for a list of this type.<P> |
| | 63 | |
| | 64 | <H3>I am about to start a wxWindows 1.xx project. Should I use 2 instead?</H3> |
| | 65 | |
| | 66 | wxWindows 2 is still in beta but it's actually pretty useable (Windows, GTK, Motif).<P> |
| | 67 | |
| | 68 | Porting to wxWindows 2 from 1.xx will not be too painful; see the next question |
| | 69 | for ways in which you can make it easier.<P> |
| | 70 | |
| | 71 | <H3>Why would I want to use wxWindows 2 in preference to wxWindows 1.xx?</H3> |
| | 72 | |
| | 73 | Some reasons: |
| | 74 | |
| | 75 | <ul> |
| | 76 | <li>In 2 there is far more flexibility, for example in the way windows can be |
| | 77 | nested, and the way events are intercepted. |
| | 78 | <li>There is more functionality for producing sophisticated applications, |
| | 79 | for example using the wxTreeCtrl and wxListCtrl classes. |
| | 80 | <li>There is better C++-conformance (such as usage of wxString and const) which |
| | 81 | will make your applications more reliable and easier to maintain. |
| | 82 | <li>wxWindows 2 will be better supported than 1.xx. |
| | 83 | <li>The GTK version is attractive for people interested in writing Linux and GNOME |
| | 84 | applications. |
| | 85 | <li>The Mac version will be one of the best frameworks available on that platform. |
| | 86 | </ul> |
| | 87 | |
| | 88 | <H3>How can I prepare for wxWindows 2?</H3> |
| | 89 | |
| | 90 | To make porting to wxWindows 2 easier in the future, take a look at some |
| | 91 | <a href="http://www.wxwindows.org/prepare.htm">tips</a> for writing existing code in a 2-compatible way.<P> |
| | 92 | |
| | 93 | <H3>How much has the API changed since 1.xx?</H3> |
| | 94 | |
| | 95 | It's difficult to summarize, but some aspects haven't changed very much. For example, if you have some |
| | 96 | complex drawing code, you will mostly need to make sure it's parameterised with a device |
| | 97 | context (instead of obtaining one from a window or storing it). You won't have |
| | 98 | to completely rewrite the drawing code.<P> |
| | 99 | |
| | 100 | The way that events are handled has changed, so for example, where you overrode |
| | 101 | OnSize before, you now have a non-virtual OnSize with a single event class argument. |
| | 102 | To make this function known to wxWindows, you add an entry in an 'event table' using macros. Addition of these macros |
| | 103 | will eventually be made easier by a tool which will allow selection from a list |
| | 104 | and copy-and-paste into your editor. This is extended to button presses, listbox selection |
| | 105 | etc. so callbacks have gone (they may be added back for limited backward compatibility).<P> |
| | 106 | |
| | 107 | The class hierarchy has changed to allow greater flexibility but it probably won't affect your |
| | 108 | existing application. One exception to this is MDI applications which now use separate MDI classes instead of style |
| | 109 | flags. As a result, it won't be possible to switch between MDI and SDI operation at run-time |
| | 110 | without further coding, but a benefit is less interdependence between areas of code, |
| | 111 | and therefore smaller executable size.<P> |
| | 112 | |
| | 113 | Panel items (now called controls) no longer have labels associated with most of them, |
| | 114 | and default panel layout has been removed. The idea is that you make greater use |
| | 115 | of dialog resources, for better-looking dialogs.<P> |
| | 116 | |
| | 117 | <H3>What classes have disappeared?</H3> |
| | 118 | |
| | 119 | wxForm, wxTextWindow (subsumed into wxTextCtrl). |
| | 120 | |
| | 121 | <H3>Does wxWindows 2 mean that wxWindows 1.xx is dead?</H3> |
| | 122 | |
| | 123 | While wxWindows 2 is being developed, there will be further patches to wxWindows 1.xx. |
| | 124 | Obviously we are investing most of our energy into the new code, but we're also trying |
| | 125 | to fix bugs in the current version.<P> |
| | 126 | |
| | 127 | <H3>What platforms will be supported by wxWindows 2?</H3> |
| | 128 | |
| | 129 | <ul> |
| | 130 | <li>Windows 3.1, Windows 95/98, Windows NT; |
| | 131 | <li>Linux and other Unix platforms with GTK+; |
| | 132 | <li>Unix with Motif or the free Motif clone Lesstif; |
| | 133 | <li>Mac (coming later in 1999); |
| | 134 | <li>A BeOS port is being investigated. |
| | 135 | <li>A Windows CE port is being investigated. |
| | 136 | <li>There are no plans to support OS/2 or XView. However, |
| | 137 | you may be able to compile the GTK and Motif versions under OS/2 with X and GTK |
| | 138 | installed, or the Windows version with IBM's Open32 extensions. |
| | 139 | </ul> |
| | 140 | <P> |
| | 141 | |
| | 142 | <H3>How does wxWindows 2 support platform-specific features?</H3> |
| | 143 | |
| | 144 | This is a hotly-debated topic amongst the developers. My own philosophy |
| | 145 | is to make wxWindows as platform-independent as possible, but allow in a |
| | 146 | few classes (functions, window styles) that are platform-specific. |
| | 147 | For example, Windows metafiles and Windows 95 taskbar icons have |
| | 148 | their own classes on Windows, but nowhere else. Because these classes |
| | 149 | are provided and are wxWindows-compatible, it doesn't take much |
| | 150 | coding effort for an application programmer to add support for |
| | 151 | some functionality that the user on a particular platform might otherwise |
| | 152 | miss. Also, some classes that started off as platform-specific, such |
| | 153 | as the MDI classes, have been emulated on other platforms. I can imagine |
| | 154 | that even wxTaskBarIcon may be implemented for Unix desktops one day. |
| | 155 | <P> |
| | 156 | |
| | 157 | In other words, wxWindows is not a 'lowest common denominator' approach, |
| | 158 | but it will still be possible to write portable programs using the |
| | 159 | core API. Forbidding some platform-specific classes would be a stupid |
| | 160 | approach that would alienate many potential users, and encourage |
| | 161 | the perception that toolkits such as wxWindows are not up to the demands |
| | 162 | of today's sophisticated applications.<P> |
| | 163 | |
| | 164 | Currently resources such as bitmaps and icons are handled in a platform-specific |
| | 165 | way, but it is hoped to reduce this dependence in due course.<P> |
| | 166 | |
| | 167 | Another reason why wxWindows 2 is not a 'lowest common denominator' toolkit is that |
| | 168 | some functionality missing on some platform has been provided using generic, |
| | 169 | platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.<P> |
| | 170 | |
| | 171 | <H3>Does wxWindows use STL? or the standard string class?</H3> |
| | 172 | |
| | 173 | No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in |
| | 174 | wxWindows' best interests to avoid use of templates. Not all compilers can handle |
| | 175 | templates adequately so it would dramatically reduce the number of compilers |
| | 176 | and platforms that could be supported. It would also be undersirable to make |
| | 177 | wxWindows dependent on another large library that may have to be downloaded and installed. |
| | 178 | In addition, use of templates can lead to executable bloat, which is something |
| | 179 | wxWindows 2 is strenously trying to avoid.<P> |
| | 180 | |
| | 181 | The standard C++ string class is not used, again because it is not available to all compilers, |
| | 182 | and it is not necessarily a very efficient implementation. Also, we retain more flexibility |
| | 183 | by being able to modify our own string class. Some compatibility with the string class |
| | 184 | has been built into wxString.<P> |
| | 185 | |
| | 186 | There is nothing to stop an application using templates or the string class for its own |
| | 187 | purposes.<P> |
| | 188 | |
| | 189 | <H3>Is there a rich edit/markup widget for wxWindows 2?</H3> |
| | 190 | |
| | 191 | These are the possibilities so far:<P> |
| | 192 | |
| | 193 | <ul> |
| | 194 | <li>The richedit sample has a text editor that does markup. |
| | 195 | <li>See <a href="http://www.scintilla.org" target=_top>www.scintilla.org</a> for |
| | 196 | a very nice syntax-highlighting editor widget. Robin Dunn is writing a wxWindows wrapper |
| | 197 | for this widget. |
| | 198 | <li>If you only need to display marked-up information, rather than edit it, |
| | 199 | then wxHTML will suit your needs. wxHTML is built into wxWindows - please see the reference |
| | 200 | manual for details, and samples/html. |
| | 201 | <li>There are rich edit widgets in both WIN32 and GTK+, but there is currently |
| | 202 | no wxWindows wrapper for these. |
| | 203 | </ul> |
| | 204 | |
| | 205 | <P> |
| | 206 | |
| | 207 | <H3>How is wxWindows 2 being developed?</H3> |
| | 208 | |
| | 209 | We are using the <a href="cvs.htm">CVS</a> system to develop and maintain wxWindows. This allows |
| | 210 | us to make alterations and upload them instantly to the server in Edinburgh, from |
| | 211 | which others can update their source.<P> |
| | 212 | |
| | 213 | To build source from CVS, see the file BuildCVS.txt in the top-level wxWindows distribution |
| | 214 | directory.<P> |
| | 215 | |
| | 216 | <H3>How is wxWindows 2 distributed?</H3> |
| | 217 | |
| | 218 | By ftp, and via the <a href="cdrom2.htm">wxWindows CD-ROM</a>.<P> |
| | 219 | |
| | 220 | <H3>What are the plans for the future?</H3> |
| | 221 | |
| | 222 | Currently we're working too hard on getting wxWindows 2 finished (are GUI toolkits ever |
| | 223 | finished?) to think very far ahead. However, we know we want to make wxWindows as robust |
| | 224 | and well-publicised as possible. We also want to aim for better platform-independence of |
| | 225 | resources such as icons and bitmaps, standardising on the PNG for all platforms.<P> |
| | 226 | |
| | 227 | Other possibilities include: DCOM/CORBA compatibility; a wxWindows book; |
| | 228 | <a href="http://wxstudio.linuxbox.com/">wxStudio</a>, an IDE; |
| | 229 | other platforms; other interface abilities such as speech output.<P> |
| | 230 | |
| | 231 | We will investigate the possibility of compiler or operating system vendors bundling wxWindows with |
| | 232 | their product.<P> |
| | 233 | |
| | 234 | The high-level goal of wxWindows is to be thought of as the number one C++ framework, |
| | 235 | for virtually any platform. Move over, MFC!<P> |
| | 236 | |
| | 237 | <H3>What about Java?</H3> |
| | 238 | |
| | 239 | The Java honeymoon period is over :-) and people are realising that it cannot |
| | 240 | meet all their cross-platform development needs. We don't anticipate a major threat |
| | 241 | from Java, and the level of interest in wxWindows is as high as ever.<P> |
| | 242 | |
| | 243 | <H3>How can I help the project?</H3> |
| | 244 | |
| | 245 | Please check out the <a href="http://www.wxwindows.org/develop.htm" target=main>Backroom</a> pages, |
| | 246 | in particular the <a href="http://www.wxwindows.org/projects.htm">suggested projects</a>, and |
| | 247 | mail <a href="mailto:julian.smart@ukonline.co.uk">Julian Smart</a> or the developers' mailing list with your own suggestions.<P> |
| | 248 | |
| | 249 | </font> |
| | 250 | |
| | 251 | </BODY> |
| | 252 | |
| | 253 | </HTML> |
projects / wxWidgets.git / blame_incremental