docs/publicity/WoWoW30.html

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