WoWoW30.html 23 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375
  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 wherever 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.6, more
  55. recent features are used when available) and Mac OS X (minimum
  56. version 10.5 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 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&lt;T&gt;</A>),
  95. 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>),
  96. weak references (see <A HREF="http://docs.wxwidgets.org/trunk/classwx_weak_ref_3_01_t_01_4.html">wxWeakRef&lt;T&gt;</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.5 Leopard and GTK+ 2
  107. version older than 2.6 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. Development 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. to 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 and toolkit dependent code for the Carbon, Cocoa, and
  280. Cocoa Touch API. wxOSX/Carbon is the core of what used to be wxMac
  281. and is now deprecated in favour of wxOSX/Cocoa. Existing applications
  282. are encouraged to switch to wxOSX/Cocoa as Carbon is a deprecated OS X
  283. feature, not available for 64-bit GUI applications, and not available for
  284. iOS devices at all.</P>
  285. <P ALIGN=JUSTIFY>As part of the restructuring, all remaining drawing
  286. code using the old QuickDraw API has been removed (it was only an
  287. option before) and drawing now always takes place using CoreGraphics.
  288. Likewise, all code using Carbon functions no longer present in OS X
  289. 10.4 and 10.5 has been removed to clean-up the code greatly. This is turn
  290. means, as mentioned above, that applications will require a minimum
  291. of OS X 10.5 in order to run.</P>
  292. <P ALIGN=JUSTIFY>Apart from these large changes, these additional
  293. features can be noted:</P>
  294. <UL>
  295. <LI><P ALIGN=JUSTIFY>Better support for IconRef</P>
  296. <LI><P ALIGN=JUSTIFY>A fix for duplicate menu entries in non-English
  297. locales</P>
  298. <LI><P ALIGN=JUSTIFY>Accelerators allowed to be used for buttons</P>
  299. <LI><P ALIGN=JUSTIFY>wxLocale::GetInfo() implemented using CFLocale</P>
  300. </UL>
  301. <H3 CLASS="western">wxGTK specific changes</H3>
  302. <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">The task of the GTK+ port
  303. of wxWidgets is to keep up with the development of the GTK+ library
  304. since it has the habit of adding new controls or new APIs if the
  305. existing code is too limited and cannot be fixed in a backward
  306. compatible way. The main problem of this approach is that
  307. applications written using wxGTK should work with relatively old
  308. versions of GTK+ but should also make use of recent features. In some
  309. cases, supporting an old version of GTK+ hinders development so we
  310. decided to declare GTK+ 2.6 the minimum toolkit version that is
  311. supported. As an example, this made it possible to always use the
  312. GTK+ file dialog instead of the old generic file dialog which had to
  313. be used when GTK+ didn't have a usable file dialog.
  314. </P>
  315. <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Other parts of wxGTK that
  316. were rewritten or which underwent a major update include, but are not
  317. limited to:</P>
  318. <UL>
  319. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">wxToolbar now uses
  320. the „new“ GTK+ toolbar API</P>
  321. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">wxChoice now uses
  322. GtkComboBox instead of the deprecated GtkOptionMenu</P>
  323. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">wxComboBox now
  324. always uses GtkComboBox instead of the deprecated GtkCombo class</P>
  325. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">URL dragging using
  326. the „text/x-moz-url“ in wxURLDataObject</P>
  327. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Added a completely
  328. new printing backend using with dialogs GtkPrint and Cairo</P>
  329. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Rewritten idle event
  330. generation code</P>
  331. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Tab traversal is now
  332. done natively by GTK+ instead of by wxWidgets</P>
  333. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Rewrote layout of
  334. wxFrame's menubar, toolbar, client window and statusbar using a
  335. GtkVBox instead of our own calculation</P>
  336. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Correctly
  337. implemented SetSize() and GetSize() for toplevel windows in spite of
  338. the dreaded problems with window decorations belonging to the Window
  339. Manager and not the window itself</P>
  340. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Added an
  341. asynchronous API to wxClipboard to avoid having to call wxYield()
  342. from within it (which causes reentrance problems).</P>
  343. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Some support for
  344. Hildon control from the Maemo platform used for Nokia tablets</P>
  345. <LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Rewritten the
  346. wxTaskBarIconIcon class using GtkStatusIcon if available.</P>
  347. </UL>
  348. <P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><BR>
  349. </P>
  350. <H3 CLASS="western">wxMSW specific changes</H3>
  351. <P STYLE="margin-bottom: 0cm">wxMSW is the most mature platform,
  352. mostly because it is used most often and thus has the biggest user,
  353. tester and developer base, but also because the underlying Windows
  354. system has been more successful at preserving backwards
  355. compatibility. Therefore, the list of wxMSW-specific changes is
  356. smaller and the changes usually minor details when compared to the
  357. changes of the other two main ports:</P>
  358. <UL>
  359. <LI><P STYLE="margin-bottom: 0cm">Implemented more native looking
  360. wxCheckListBox and add ability to store client data in it</P>
  361. <LI><P STYLE="margin-bottom: 0cm">Allow longer tooltips</P>
  362. <LI><P STYLE="margin-bottom: 0cm">Support for multiline labels in
  363. wxCheckBox and wxToggleButton</P>
  364. <LI><P STYLE="margin-bottom: 0cm">More precise print preview</P>
  365. <LI><P STYLE="margin-bottom: 0cm">Show resize gripper in resizable
  366. dialogs</P>
  367. </UL>
  368. <P STYLE="margin-bottom: 0cm"><BR>
  369. </P>
  370. <P STYLE="margin-bottom: 0cm"><BR>
  371. </P>
  372. <P STYLE="margin-bottom: 0cm"><BR>
  373. </P>
  374. </BODY>
  375. </HTML>