| | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| | 2 | <HTML> |
| | 3 | <HEAD> |
| | 4 | <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8"> |
| | 5 | <TITLE></TITLE> |
| | 6 | <META NAME="GENERATOR" CONTENT="OpenOffice.org 2.3 (Linux)"> |
| | 7 | <META NAME="AUTHOR" CONTENT="Robert Roebling"> |
| | 8 | <META NAME="CREATED" CONTENT="20080829;16130000"> |
| | 9 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 10 | <META NAME="CHANGED" CONTENT="20090209;11181400"> |
| | 11 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 12 | <META NAME="CHANGEDBY" CONTENT="Julian Smart"> |
| | 13 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 14 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 15 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 16 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 17 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 18 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 19 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 20 | <META NAME="CHANGEDBY" CONTENT="Robert Roebling"> |
| | 21 | <STYLE TYPE="text/css"> |
| | 22 | <!-- |
| | 23 | @page { margin: 2cm } |
| | 24 | P { margin-bottom: 0.21cm } |
| | 25 | H2 { margin-bottom: 0.21cm } |
| | 26 | H2.western { font-family: "Albany AMT", sans-serif; font-size: 14pt; font-style: italic } |
| | 27 | H2.cjk { font-family: "Albany AMT"; font-size: 14pt; font-style: italic } |
| | 28 | H2.ctl { font-family: "Arial Unicode MS"; font-size: 14pt; font-style: italic } |
| | 29 | H3.western { font-family: "Albany", sans-serif } |
| | 30 | H3.cjk { font-family: "HG Mincho Light J" } |
| | 31 | H3.ctl { font-family: "Arial Unicode MS" } |
| | 32 | --> |
| | 33 | </STYLE> |
| | 34 | </HEAD> |
| | 35 | <BODY LANG="de-DE" DIR="LTR"> |
| | 36 | <H2 CLASS="western">The Wonderful World of wxWidgets 3.0</H2> |
| | 37 | <H3 CLASS="western">What is wxWidgets?</H3> |
| | 38 | <P ALIGN=JUSTIFY>Although it is quite unlikely that you'll read this |
| | 39 | document if you don't know what wxWidgets is, let's just briefly |
| | 40 | mention that wxWidgets is a C++ framework for building rich GUI |
| | 41 | applications from a single source which can then be compiled on |
| | 42 | different operating systems, resulting in a native application on |
| | 43 | each system. wxWidgets uses native controls (or widgets) and other |
| | 44 | native functions whereever possible so that the resulting |
| | 45 | applications will look and feel as native as possible, and they are |
| | 46 | usually not distinguishable from applications written using single |
| | 47 | platform toolkits such as MFC for Windows, GTK+ for Linux or Cocoa |
| | 48 | under OS X. In some areas (such as graphics art or the installer), |
| | 49 | adaptations to the individual platforms have to be made in order to |
| | 50 | achieve perfect integration with that platform.</P> |
| | 51 | <P ALIGN=JUSTIFY>The major operating system for which wxWidgets |
| | 52 | supports are Windows (Windows 95, NT, 2000, XP, Vista) including its |
| | 53 | mobile variants (Windows CE, PocketPC, Windows Mobile), Linux and |
| | 54 | Unix using the GTK+ 2 toolkit (minimum version is GTK+ 2.4, more |
| | 55 | recent features are used when available) and Mac OS X (minimum |
| | 56 | version 10.4 Tiger, both Intel, PPC and the Universal Binaries for |
| | 57 | both are supported). wxWidgets includes many code pieces for |
| | 58 | optimising dialog and general layout for small screens such as those |
| | 59 | of the recent netbooks and mobile phones and tablets.</P> |
| | 60 | <P ALIGN=JUSTIFY>There is varying support for other platforms or |
| | 61 | toolkits such as OS/2, Motif, GTK 1.2, PalmOS and various mobile |
| | 62 | Linux variants using GTK+ or the Hildon framework and also a version |
| | 63 | for OS X using the Cocoa API and even the iPhone SDK.</P> |
| | 64 | <H3 CLASS="western">Documentation in Doxygen</H3> |
| | 65 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Until wxWidgets 3.0 all |
| | 66 | documentation was written in a customized LaTeX variant created for |
| | 67 | the project years ago. Although there were tools which could parse |
| | 68 | classes automatically and create a documentation skeleton, class |
| | 69 | documentation was troublesome to update and therefore often outdated. |
| | 70 | In order to improve this situation, the entire documentation |
| | 71 | including references and overviews was converted to a customized |
| | 72 | Doxygen format inlined in a special set of headers. Although many |
| | 73 | classes were converted in a single automated step, every class |
| | 74 | documentation had to be corrected by hand making this effort one of |
| | 75 | the biggest in the development cycle leading up wxWidgets 3.0. |
| | 76 | Additionally, tools were written to automatically compare the |
| | 77 | signature of the many class methods to the documentation. The result |
| | 78 | is more correct documentation with better formating and built-in |
| | 79 | searching and screenshots of many controls. Since Doxygen is a |
| | 80 | wide-spread format and easy to learn, the new documentation is much |
| | 81 | easier to edit, correct and read. See the <A HREF="http://docs.wxwidgets.org/trunk/index.html">wxWidgets |
| | 82 | on-line documentation</A> to which this document refers to in many |
| | 83 | places.</P> |
| | 84 | <H3 CLASS="western">C++ features and template support</H3> |
| | 85 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">The wxWidgets project |
| | 86 | tries to both move with new developments of the C++ language as well |
| | 87 | as to support older compilers to an extent which does not inhibit |
| | 88 | further development and indeed the usefulness of the entire project. |
| | 89 | Since support for templates used to be limited to a few compilers and |
| | 90 | was often buggy even in them, wxWidgets initially stayed away from |
| | 91 | using templates entirely including the use of the Standard Template |
| | 92 | Library (STL). In the meantime nearly all compilers have gained solid |
| | 93 | template support and therefore wxWidgets is now using templates for |
| | 94 | container classes (such as <A HREF="http://docs.wxwidgets.org/trunk/classwx_vector_3_01_t_01_4.html">wxVector<T></A>), |
| | 95 | smart pointers (such as <A HREF="http://docs.wxwidgets.org/trunk/classwx_shared_ptr_3_01_t_01_4.html">wxSharedPtr<T></A>), |
| | 96 | weak references (see <A HREF="http://docs.wxwidgets.org/trunk/classwx_weak_ref_3_01_t_01_4.html">wxWeakRef<T></A>) |
| | 97 | and many other places where templates are useful. This means that |
| | 98 | very old compilers won't be able to compile wxWidgets anymore or only |
| | 99 | in a degraded way (such as Visual C++ 6.0).</P> |
| | 100 | <H3 CLASS="western">Platform features and backwards compatibility</H3> |
| | 101 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">In the same way wxWidgets |
| | 102 | tries to both make use of new features of the different operating |
| | 103 | systems and support older systems for as long as possible and as long |
| | 104 | as supporting them does not hinder development for up-to-date |
| | 105 | systems. This is especially true for OS X and GTK+ 2 and it was |
| | 106 | therefore decided that OS X versions older than 10.4 Tiger and GTK+ 2 |
| | 107 | version older than 2.4 are no longer supported. The wxWidgets team |
| | 108 | also realized that it could not do everything and that support for a |
| | 109 | cross-platform database API was beyond the scope and focus of the |
| | 110 | project so that its old wxODBC database connectivity classes were |
| | 111 | removed from the project. There are many cross-platform database |
| | 112 | libraries available and many of them are better than the old wxODBC |
| | 113 | and all of them are better maintained.</P> |
| | 114 | <H3 CLASS="western">Unicode: A Single Build for Everyone</H3> |
| | 115 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Until version 3.0 there |
| | 116 | have always been two different versions (or builds) of wxWidgets: one |
| | 117 | with full support for Unicode where each character was represented by |
| | 118 | a wchar_t internally (using two bytes under Windows and four bytes |
| | 119 | almost everywhere else) and another called the „ANSI“ build where |
| | 120 | each character was represented by a single byte. This model was |
| | 121 | chosen following the original Windows API model and at a point of |
| | 122 | time when Unicode support was hardly present anywhere else. In the |
| | 123 | meantime, the Windows world together with projects such as Java have |
| | 124 | chosen UTF-16 as the native representation for Unicode strings |
| | 125 | whereas much of the free software world including GTK+ and parts of |
| | 126 | Mac OS X have chosen UTF-8. It was therefore decided to drastically |
| | 127 | change the implementation of wxWidgets' string class and make it use |
| | 128 | UTF-16 under Windows (mostly as before) but UTF-8 elsewhere (instead |
| | 129 | of wide character strings using wchar_t) so that strings received |
| | 130 | from and sent to Unix and GTK+ library calls would no longer have to |
| | 131 | be converted back and forth between different Unicode representations |
| | 132 | (see <A HREF="http://docs.wxwidgets.org/trunk/classwx_string.html">wxString</A> |
| | 133 | and <A HREF="http://docs.wxwidgets.org/trunk/overview_unicode.html">Unicode |
| | 134 | overview</A>). Additionally, the „ANSI“ mode was removed and the |
| | 135 | wxString class as well as some other classes were modified to accept |
| | 136 | and return both Unicode and 8-bit string literals if required. The |
| | 137 | same was done to functions like wxPrintf() etc. Although this change |
| | 138 | will eventually not be seen by the end user of an application written |
| | 139 | using wxWidgets, it is such a fundamental change that it was the |
| | 140 | primary reason to give wxWidgets the new major version number 3.</P> |
| | 141 | <H3 CLASS="western">New 2D Drawing Code</H3> |
| | 142 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Although a 2D drawing API |
| | 143 | has always been part of wxWidgets (using so-called device contexts |
| | 144 | such as a window or a bitmap and pens and brushes to draw into them, |
| | 145 | see <A HREF="http://docs.wxwidgets.org/trunk/classwx_d_c.html">wxDC</A>, |
| | 146 | <A HREF="http://docs.wxwidgets.org/trunk/classwx_pen.html">wxPen</A>, |
| | 147 | <A HREF="http://docs.wxwidgets.org/trunk/classwx_brush.html">wxBrush</A>), |
| | 148 | it has not changed much since its initial inception and so the code |
| | 149 | was completely reorganized using a single set of frontend classes and |
| | 150 | different backends which will make maintainance much easier without |
| | 151 | having to care for binary backwards compatibility and it also helped |
| | 152 | isolate a number of subtle platform differences. The old drawing API |
| | 153 | is good enough for many tasks and reflects the drawing capabilites of |
| | 154 | the 1990's but it didn't make use of advanced features such as |
| | 155 | transparency, anti-aliasing and free matrix transforms of modern 2D |
| | 156 | graphics systems such as GDI+ on Windows, Cairo on Linux (and |
| | 157 | elsewhere) and CoreGraphics on OS X. Therefore a completely new |
| | 158 | drawing API (the so called graphics contexts, see <A HREF="http://docs.wxwidgets.org/trunk/classwx_graphics_context.html">wxGraphicsContext</A>) |
| | 159 | was added to wxWidgets making use of modern drawing engines. This is |
| | 160 | complemented by a bitmap class with alpha channel support and fast |
| | 161 | raw access to the bitmap's internal data representation. Additionally |
| | 162 | the API of all existing GDI class constants was corrected so that |
| | 163 | wxMODERN becomes wxFONTFAMILY_MODERN, wxSOLID becomes |
| | 164 | wxBRUSHSTYLE_SOLID etc. and the reference counting system was |
| | 165 | streamlined and made identical on all platforms.</P> |
| | 166 | <H3 CLASS="western">Changes to wxBase</H3> |
| | 167 | <P ALIGN=JUSTIFY>wxBase is the name of the non-GUI part of wxWidgets |
| | 168 | libary which provides basic class such as the aforementioned wxString |
| | 169 | class, container classes, as well as classes for threading, |
| | 170 | networking, XML parsing, path and configuration management, logging, |
| | 171 | debugging etc. These functions and classes have been separated into |
| | 172 | their own library both for being able to write non-GUI apps as well |
| | 173 | as to make maintainance easier through reduced interdependence. |
| | 174 | </P> |
| | 175 | <P ALIGN=JUSTIFY>Many of the changes to wxString and the container |
| | 176 | classes are located in wxBase, but on top of that support to wxBase |
| | 177 | was added for events loops, timers and sockets for writing |
| | 178 | event-based client or server apps with wxWidgets 3.0. The socket code |
| | 179 | itself has been reorganized removing a lot of duplicated code and |
| | 180 | dropping the previous implementation which was separated into a C and |
| | 181 | a C++ part.</P> |
| | 182 | <H3 CLASS="western">New controls and other major GUI additions for |
| | 183 | all ports</H3> |
| | 184 | <P ALIGN=JUSTIFY>This document cannot list every bug fix and minor |
| | 185 | change. Rather, this paragraph summarizes the most relevant changes |
| | 186 | to the GUI classes of wxWidgets. Given wxWidgets' nature as a GUI |
| | 187 | library, these changes are also most likely to be visible to the user |
| | 188 | and may thus be the most important changes from a user's perspective |
| | 189 | (although not necessarily from a developer's perspective): |
| | 190 | </P> |
| | 191 | <UL> |
| | 192 | <LI><P ALIGN=JUSTIFY>wxDataViewCtrl and wxDataViewTreeCtrl: this |
| | 193 | control can partially replace both wxListCtrl and wxTreeCtrl (for |
| | 194 | which there only was a native version of Windows and partially for |
| | 195 | OS X) but also extends and combines the classes by being able to |
| | 196 | display a hierarchy and list at the same time and by offering a much |
| | 197 | more flexible way to display and edit data on a per column basis. |
| | 198 | Reimplementing wxTreeCtrl and possibly wxListCtrl in terms of |
| | 199 | wxDataViewCtrl was considered, but this was dropped as certain |
| | 200 | special features are not available on all platforms (or |
| | 201 | differently). See also <A HREF="http://docs.wxwidgets.org/trunk/classwx_data_view_ctrl.html">wxDataViewCtrl</A>, |
| | 202 | <A HREF="http://docs.wxwidgets.org/trunk/classwx_data_view_list_ctrl.html">wxDataViewListCtrl</A> |
| | 203 | and <A HREF="http://docs.wxwidgets.org/trunk/classwx_data_view_tree_ctrl.html">wxDataViewTreeCtrl</A>.</P> |
| | 204 | <LI><P ALIGN=JUSTIFY>The tabular view of wxGrid has been improved |
| | 205 | including a native header control, which has been separated into a |
| | 206 | new control. See also <A HREF="http://docs.wxwidgets.org/trunk/classwx_grid.html">wxGrid</A> |
| | 207 | and <A HREF="http://docs.wxwidgets.org/trunk/classwx_header_ctrl.html">wxHeaderCtrl.</A></P> |
| | 208 | <LI><P ALIGN=JUSTIFY>Added wxPropertyGrid which is a big generic |
| | 209 | control used to display lists and hierarchies of name-value pairs. |
| | 210 | Like wxDataViewCtrl, it offers a number of ready-to-use editors for |
| | 211 | editing text, numbers, lists, fonts, file names etc. using in-place |
| | 212 | editing or using pop-up dialog and combo boxes. Developement of |
| | 213 | wxPropertyGrid has so far taken place outside of wxWidgets as a |
| | 214 | separate project, but it has not been included in wxWidgets per se. |
| | 215 | See also <A HREF="http://docs.wxwidgets.org/trunk/classwx_property_grid.html">wxPropertyGrid</A>.</P> |
| | 216 | <LI><P ALIGN=JUSTIFY>wxHyperlinkCtrl added, implemented natively |
| | 217 | under GTK+ and in a generic way on other platforms. It can be used |
| | 218 | to represent a hypertext link, for example to the homepage of the |
| | 219 | developer or company. See also <A HREF="http://docs.wxwidgets.org/trunk/classwx_hyperlink_ctrl.html">wxHyperlinkCtrl</A>.</P> |
| | 220 | <LI><P ALIGN=JUSTIFY>wxFileCtrl for constructing fully customized |
| | 221 | file dialogs. Complementary to this, the possibility to add custom |
| | 222 | control to wxFileDialog has been added. See <A HREF="http://docs.wxwidgets.org/trunk/classwx_file_ctrl.html">wxFileCtrl</A> |
| | 223 | and <A HREF="http://docs.wxwidgets.org/trunk/classwx_file_dialog.html">wxFileDialog</A>.</P> |
| | 224 | <LI><P ALIGN=JUSTIFY>Several enhancements to wxRichTextCtrl |
| | 225 | including support for super- and subscript and many speed-ups. See |
| | 226 | <A HREF="http://docs.wxwidgets.org/trunk/classwx_rich_text_ctrl.html">wxRichTextCtrl</A>.</P> |
| | 227 | <LI><P ALIGN=JUSTIFY>The possibility to display state icons has been |
| | 228 | added to wxTreeCtrl. This can also be used to implement check-box |
| | 229 | like behaviour. See <A HREF="http://docs.wxwidgets.org/trunk/classwx_tree_ctrl.html">wxTreeCtrl</A>.</P> |
| | 230 | <LI><P ALIGN=JUSTIFY>wxCalendarCtrl has been rewritten using native |
| | 231 | code under MSW and GTK+ and enhanced in many ways (for example |
| | 232 | displaying week numbers). See <A HREF="http://docs.wxwidgets.org/trunk/classwx_calendar_ctrl.html">wxCalendarCtrl</A>.</P> |
| | 233 | <LI><P ALIGN=JUSTIFY>Implemented support for auto-completion for |
| | 234 | wxTextCtrl and wxComboBox.</P> |
| | 235 | <LI><P ALIGN=JUSTIFY>Added wxAUIToolBar to the set of wxAUI classes, |
| | 236 | which is better integrated and more flexible than the standard |
| | 237 | wxToolBar.</P> |
| | 238 | <LI><P ALIGN=JUSTIFY>Reimplemented wxBitmapComboBox using native |
| | 239 | code under MSW and GTK+. See also <A HREF="http://docs.wxwidgets.org/trunk/classwx_bitmap_combo_box.html">wxBitmapComboBox</A>.</P> |
| | 240 | <LI><P ALIGN=JUSTIFY>Added wxBitmapToggleButton on all platforms. |
| | 241 | See also <A HREF="http://docs.wxwidgets.org/trunk/classwx_bitmap_toggle_button.html">wxBitmapToggleButton</A>.</P> |
| | 242 | <LI><P ALIGN=JUSTIFY>Added support for ellipsization on all |
| | 243 | platforms and for mark-up formatting under GTK+ to wxStaticText. See |
| | 244 | <A HREF="http://docs.wxwidgets.org/trunk/classwx_static_text.html">wxStaticText</A>.</P> |
| | 245 | <LI><P ALIGN=JUSTIFY>Rewritten the selection event emission logic of |
| | 246 | wxListBox on all platforms to more exactly match each other when |
| | 247 | selecting and deselecting certain items.</P> |
| | 248 | <LI><P ALIGN=JUSTIFY>Implemented wxCollapsiblePane natively for GTK |
| | 249 | and OS X. See <A HREF="http://docs.wxwidgets.org/trunk/classwx_collapsible_pane.html">wxCollapsiblePane</A>.</P> |
| | 250 | <LI><P ALIGN=JUSTIFY>Added a new sizer which can wrap across |
| | 251 | multiple lines. See <A HREF="http://docs.wxwidgets.org/trunk/classwx_wrap_sizer.html">wxWrapSizer</A>.</P> |
| | 252 | <LI><P ALIGN=JUSTIFY>Added multi-sample and anti-aliasing support |
| | 253 | the the OpenGL canvas and separated wxGLCanvas and wxGLContext. See |
| | 254 | <A HREF="http://docs.wxwidgets.org/trunk/classwx_g_l_canvas.html">wxGLCanvas</A>.</P> |
| | 255 | <LI><P ALIGN=JUSTIFY>Added wxNativeContainerWindow in order to |
| | 256 | construct a wxTopLevelWindow from a native window handle (MSW and |
| | 257 | GTK+).</P> |
| | 258 | <LI><P ALIGN=JUSTIFY>The <A HREF="http://docs.wxwidgets.org/trunk/classwx_v_scrolled_window.html">wxVScrolledWindow</A> |
| | 259 | class has been completely rewritten to accommodate the addition of |
| | 260 | the new horizontal scrolling variants (<A HREF="http://docs.wxwidgets.org/trunk/classwx_h_scrolled_window.html">wxHScrolledWindow</A> |
| | 261 | and <A HREF="http://docs.wxwidgets.org/trunk/classwx_h_v_scrolled_window.html">wxHVScrolledWindow</A>) |
| | 262 | while still providing complete backwards compatibility for |
| | 263 | wxVScrolledWindow.</P> |
| | 264 | </UL> |
| | 265 | <H3 CLASS="western">wxMac specific changes (now called wxOSX)</H3> |
| | 266 | <P ALIGN=JUSTIFY>One important change of the wxMac port is that the |
| | 267 | port is not called wxMac anymore. Instead, the more appropriate term |
| | 268 | wxOSX should be used as the operating system is called OS X nowadays |
| | 269 | and – more importantly – wxWidgets now has partial support for |
| | 270 | iPhone and iPod, and these are devices are clearly not Macs. Apart |
| | 271 | from the name change – wxMac has undergone the most fundamental |
| | 272 | changes of the three main ports, even if some of the changes were |
| | 273 | mostly reorganizing code instead of writing new code. The code has |
| | 274 | been reorganized into common code (common to Carbon, Cocoa and Cocoa |
| | 275 | Touch) including both general wrapping or front-end classes for much |
| | 276 | of the GUI code as well as a wrapper for the so called CoreFoundation |
| | 277 | classes of OS X, which are responsible on all OS X variants for |
| | 278 | string manipulation, font support, graphics and other basic |
| | 279 | functionality (CoreImage and CoreVideo have recently been added by |
| | 280 | Apple) and toolkit dependent code for the Carbon, Cocoa and Cocoa |
| | 281 | Touch API. The Carbon variant is the core of what used to be wxMac |
| | 282 | and is the most stable and mature version. The reason behind adding |
| | 283 | optional support for Cocoa and Cocoa Touch is that Carbon is not |
| | 284 | available on iPhones at all and that it has been deprecated for all |
| | 285 | 64-bit versions of OS X, which is likely to be the default a few |
| | 286 | years from now. So while present applications using wxOSX are advised |
| | 287 | to use the Carbon backend due its maturity, future developement will |
| | 288 | have to focus on the Cocoa backend.</P> |
| | 289 | <P ALIGN=JUSTIFY>As part of the restructuring, all remaining drawing |
| | 290 | code using the old QuickDraw API has been removed (it was only an |
| | 291 | option before) and drawing now always takes place using CoreGraphics. |
| | 292 | Likewise, all code using Carbon functions no longer present in OS X |
| | 293 | 10.4 has been removed to clean-up the code greatly. This is turn |
| | 294 | means, as mentioned above, that applications will require a minimum |
| | 295 | of OS X 10.4 in order to run, better yet OS X 10.5.</P> |
| | 296 | <P ALIGN=JUSTIFY>Apart from these large changes, these additional |
| | 297 | features can be noted:</P> |
| | 298 | <UL> |
| | 299 | <LI><P ALIGN=JUSTIFY>Better support for IconRef</P> |
| | 300 | <LI><P ALIGN=JUSTIFY>A fix for duplicate menu entries in non-English |
| | 301 | locales</P> |
| | 302 | <LI><P ALIGN=JUSTIFY>Accelerators allowed to be used for buttons</P> |
| | 303 | <LI><P ALIGN=JUSTIFY>wxLocale::GetInfo() implemented using CFLocale</P> |
| | 304 | </UL> |
| | 305 | <H3 CLASS="western">wxGTK specific changes</H3> |
| | 306 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">The task of the GTK+ port |
| | 307 | of wxWidgets is to keep up with the development of the GTK+ library |
| | 308 | since it has the habit of adding new controls or new APIs if the |
| | 309 | existing code is too limited and cannot be fixed in a backward |
| | 310 | compatible way. The main problem of this approach is that |
| | 311 | applications written using wxGTK should work with relatively old |
| | 312 | versions of GTK+ but should also make use of recent features. In some |
| | 313 | cases, supporting an old version of GTK+ hinders development so we |
| | 314 | decided to declare GTK+ 2.4 the minimum toolkit version that is |
| | 315 | supported. As an example, this made it possible to always use the |
| | 316 | GTK+ file dialog instead of the old generic file dialog which had to |
| | 317 | be used when GTK+ didn't have a usable file dialog. |
| | 318 | </P> |
| | 319 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Other parts of wxGTK that |
| | 320 | were rewritten or which underwent a major update include, but are not |
| | 321 | limited to:</P> |
| | 322 | <UL> |
| | 323 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">wxToolbar now uses |
| | 324 | the „new“ GTK+ toolbar API</P> |
| | 325 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">wxChoice now uses |
| | 326 | GtkComboBox instead of the deprecated GtkOptionMenu</P> |
| | 327 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">wxComboBox now |
| | 328 | always uses GtkComboBox instead of the deprecated GtkCombo class</P> |
| | 329 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">URL dragging using |
| | 330 | the „text/x-moz-url“ in wxURLDataObject</P> |
| | 331 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Added a completely |
| | 332 | new printing backend using with dialogs GtkPrint and Cairo</P> |
| | 333 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Rewritten idle event |
| | 334 | generation code</P> |
| | 335 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Tab traversal is now |
| | 336 | done natively by GTK+ instead of by wxWidgets</P> |
| | 337 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Rewrote layout of |
| | 338 | wxFrame's menubar, toolbar, client window and statusbar using a |
| | 339 | GtkVBox instead of our own calculation</P> |
| | 340 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Correctly |
| | 341 | implemented SetSize() and GetSize() for toplevel windows in spite of |
| | 342 | the dreaded problems with window decorations belonging to the Window |
| | 343 | Manager and not the window itself</P> |
| | 344 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Added an |
| | 345 | asynchronous API to wxClipboard to avoid having to call wxYield() |
| | 346 | from within it (which causes reentrance problems).</P> |
| | 347 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Some support for |
| | 348 | Hildon control from the Maemo platform used for Nokia tablets</P> |
| | 349 | <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Rewritten the |
| | 350 | wxTaskBarIconIcon class using GtkStatusIcon if available.</P> |
| | 351 | </UL> |
| | 352 | <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><BR> |
| | 353 | </P> |
| | 354 | <H3 CLASS="western">wxMSW specific changes</H3> |
| | 355 | <P STYLE="margin-bottom: 0cm">wxMSW is the most mature platform, |
| | 356 | mostly because it is used most often and thus has the biggest user, |
| | 357 | tester and developer base, but also because the underlying Windows |
| | 358 | system has been more successful at preserving backwards |
| | 359 | compatibility. Therefore, the list of wxMSW-specific changes is |
| | 360 | smaller and the changes usually minor details when compared to the |
| | 361 | changes of the other two main ports:</P> |
| | 362 | <UL> |
| | 363 | <LI><P STYLE="margin-bottom: 0cm">Implemented more native looking |
| | 364 | wxCheckListBox and add ability to store client data in it</P> |
| | 365 | <LI><P STYLE="margin-bottom: 0cm">Allow longer tooltips</P> |
| | 366 | <LI><P STYLE="margin-bottom: 0cm">Support for multiline labels in |
| | 367 | wxCheckBox and wxToggleButton</P> |
| | 368 | <LI><P STYLE="margin-bottom: 0cm">More precise print preview</P> |
| | 369 | <LI><P STYLE="margin-bottom: 0cm">Show resize gripper in resizable |
| | 370 | dialogs</P> |
| | 371 | </UL> |
| | 372 | <P STYLE="margin-bottom: 0cm"><BR> |
| | 373 | </P> |
| | 374 | <P STYLE="margin-bottom: 0cm"><BR> |
| | 375 | </P> |
| | 376 | <P STYLE="margin-bottom: 0cm"><BR> |
| | 377 | </P> |
| | 378 | </BODY> |
| | 379 | </HTML> |
projects / wxWidgets.git / blame_incremental