wxruby3 0.9.0.pre.rc.2 → 0.9.0

data/lib/wx/doc/cursor.rb

@@ -1,16 +1,24 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
 
-class Wx::Cursor
+
+class Wx
 
   # Searches for an art file with basename 'name' and creates a Cursor if found.
   # Raises an ArgumentError if not found.
   # Wx::ArtLocator::find_art is used to look up the art file using ::Kernel#caller_locations to
-  # determine the values for the 'art_path' and 'art_owner' arguments ('art_path' is set to the
-  # absolute path to the folder holding the caller's code and 'art_owner' to the basename of the
-  # caller's source file). The 'art_type' argument is set to <code>:icon</code>.
+  # determine the values for the 'art_path' and 'art_section' arguments if not specified here
+  # ('art_path' is set to the absolute path to the folder holding the caller's code and 'art_section'
+  # to the basename of the caller's source file). The 'art_type' argument is set to <code>:cursor</code>.
   # @param [String,Symbol] name base name of art file
   # @param [Wx::BitmapType,nil] bmp_type bitmap type for art file (nil means any supported type)
+  # @param [String,nil] art_path base path to look up the art file
+  # @param [String,nil] art_section optional owner folder name for art files
   # @return [Wx::Cursor]
   # @see Wx::ArtLocator::find_art
-  def self.Cursor(name, bmp_type = nil); end
+  def self.Cursor(name, bmp_type = nil, art_path: nil, art_section: nil); end
 
 end

data/lib/wx/doc/data_object.rb

@@ -1,3 +1,9 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
 
 module Wx
 

data/lib/wx/doc/datetime.rb

@@ -0,0 +1,16 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
+
+module Wx
+
+  # Default/Null time (mostly equates to `now`).
+  DEFAULT_DATE_TIME = nil
+
+  # Default/Null time (mostly equates to `now`).
+  DefaultDateTime = DEFAULT_DATE_TIME
+
+end

data/lib/wx/doc/dc.rb

@@ -1,3 +1,9 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
 
 module Wx
   class DC

data/lib/wx/doc/enum.rb

@@ -1,7 +1,14 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+
+
 ###
 # wxRuby3 Enum class
-# Copyright (c) M.J.N. Corino, The Netherlands
 ###
+# :startdoc:
+
 
 
 module Wx

data/lib/wx/doc/event.rb

@@ -1,3 +1,9 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
 
 module Wx
 
@@ -21,4 +27,10 @@ module Wx
 
   end
 
+  # Find a window with the focus, that is also a descendant of the given window.
+  # This is used to determine the window to initially send commands to.
+  # @param [Wx::Window] ancestor
+  # @return [Wx::Window,nil] descendant window of ancestor with focus
+  def self.find_focus_descendant(ancestor) end
+
 end

data/lib/wx/doc/event_blocker.rb

@@ -1,3 +1,9 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
 
 module Wx
 

data/lib/wx/doc/event_loop.rb

@@ -0,0 +1,13 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
+
+module Wx
+
+  # In wxRuby simply an alias for GUIEventLoop.
+  EventLoop = GUIEventLoop
+
+end

data/lib/wx/doc/events.rb

@@ -1,3 +1,9 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
 
 module Wx
 

data/lib/wx/doc/evthandler.rb

@@ -1,4 +1,12 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+
+
 # Additional event handler methods documentation stubs.
+# :startdoc:
+
 
 
 class Wx::EvtHandler

data/lib/wx/doc/extra/00_starting.md

@@ -18,9 +18,9 @@ is available for anyone to look at and use in any way they like. Also, anyone ca
 and enhancements to the project.
 
 Like wxWidgets wxRuby is a cross platform toolkit. This means that the same program will run on multiple platforms 
-without modification. Currently Supported platforms are Microsoft Windows and Linux or other 
-unix-like systems with GTK2 or GTK3 libraries. As wxWidgets also has stable releases for Mac OSX and Linux QT platforms
-it should not be to hard to support these. Contributions to achieve this are appreciated.
+without modification. Currently Supported platforms are Microsoft Windows, MacOSX and Linux or other 
+unix-like systems with GTK2 or GTK3 libraries. Contributions to achieve support for other wxWidgets supported platforms
+are appreciated.
 
 Since the programming language is Ruby, wxRuby programs are simple and easy to write and understand. To accomplish the
 full Ruby experience wxRuby has not ported the wxWidgets API 1 on 1 to Ruby but has made an effort to make the wxRuby
@@ -75,7 +75,7 @@ require 'wx'
 Wx::App.run { puts 'Hello world!' }
 ```
 
-As you can there is no obligation to create an instance of the Wx::App class in wxRuby for
+As you can see there is no obligation to create an instance of the Wx::App class in wxRuby for
 (admittedly extremely) simple applications. Calling the #run class method with a block will suffice.<br>
 The class method will create an instance of the generic Wx::App class under the hood and use the 
 provided block as the #on_init callback. As the code inside the block returns a false-type value (#puts 
@@ -127,8 +127,8 @@ When creating #on_init/#on_exit methods it is important to understand that those
 with wxWidgets itself). The base Wx::App class actually does not define these methods so it's also not needed (even not possible)
 to call `super` in the implementation. The wxRuby application class implementation will call the wxWidget OnInit base implementation
 itself and after successful completion check for the existence of an #on_init method (which could also be 'automagicallly'
-created from a block passed to #run) and call that if available or terminate the application if not. For the
-exit sequence to executions are similar but reversed (first a possible #on_exit method and than the wxWidgets base OnExit).
+created from a block passed to #run) and call that if available or terminate the application if not. The
+exit sequence of executions are similar but reversed (first a possible #on_exit method and than the wxWidgets base OnExit).
 
 What remains though is that for a derived application class it is still not necessary to explicitly create a class instance.
 Simply calling the #run class method will suffice.

data/lib/wx/doc/extra/01_packages.md

@@ -56,117 +56,118 @@ Currently the following modules have been implemented.
 
 ### Core
 
-The core wxRuby package providing the toplevel `Wx` module.
+The core wxRuby package providing the toplevel {Wx} module.
 This package includes basic classes like:
 
-- `Wx::Object`
-- `Wx::EvtHandler`
-- `Wx::Event`
-- `Wx::CommandEvent`
-- `Wx::App`
-- `Wx::Window`
-- `Wx::NonOwnedWindow`
-- `Wx::ToplevelWindow`
-- `Wx::Frame`
-- `Wx::Dialog`
+- {Wx::Object}
+- {Wx::EvtHandler}
+- {Wx::Event}
+- {Wx::CommandEvent}
+- {Wx::App}
+- {Wx::Window}
+- {Wx::NonOwnedWindow}
+- {Wx::TopLevelWindow}
+- {Wx::Frame}
+- {Wx::Dialog}
 
 as well as most common window classes, control/widget classes, event classes, constant and enum definitions
 and global functions not part of any of the other packages.
 
 ### AUI - Advanced User Interface controls and related classes
 
-The wxRuby AUI package providing the `Wx::AUI` module.
+The wxRuby AUI package providing the {Wx::AUI} module.
 This package includes all classes, constants and enum definitions that are considered part of the 
 wxWidgets AUI framework like:
 
-- `Wx::AUI::AuiManager`
-- `Wx::AUI::AuiMDIParentFrame`
-- `Wx::AUI::AuiMDIChildFrame`
-- `Wx::AUI::AuiMDIClientWindow`
+- {Wx::AUI::AuiManager}
+- {Wx::AUI::AuiMDIParentFrame}
+- {Wx::AUI::AuiMDIChildFrame}
+- {Wx::AUI::AuiMDIClientWindow}
 - etc
 
 ### GRID - Grid control and related classes
 
-The wxRuby GRID package providing the `Wx::GRID` module.
+The wxRuby GRID package providing the {Wx::GRID} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxGrid control like:
 
-- `Wx::GRID::Grid`
-- `Wx::GRID::GridTableBase`
-- `Wx::GRID::GridCellEditor`
-- `Wx::GRID::GridCellRenderer`
-- `Wx::GRID::GridEvent`
+- {Wx::GRID::Grid}
+- {Wx::GRID::GridTableBase}
+- {Wx::GRID::GridCellEditor}
+- {Wx::GRID::GridCellRenderer}
+- {Wx::GRID::GridEvent}
 - etc
 
 ### HTML - Html framework classes
 
-The wxRuby HTML package providing the `Wx::HTML` module.
+The wxRuby HTML package providing the {Wx::HTML} module.
 This package includes all classes, constants and enum definitions that are considered part of the
 wxWidgets Html framework like:
 
-- `Wx::HTML::HtmlWindow`
-- `Wx::HTML::HtmlHelpWindow`
-- `Wx::HTML::HtmlHelpFrame`
-- `Wx::HTML::HtmlHelpController`
+- {Wx::HTML::HtmlWindow}
+- {Wx::HTML::HtmlHelpWindow}
+- {Wx::HTML::HtmlPrintout}
+- {Wx::HTML::HtmlHelpController}
+- {Wx::HTML::HtmlListBox}
 - etc
 
 ### PG - PropertyGrid control and related classes
 
-The wxRuby PG package providing the `Wx::PG` module.
+The wxRuby PG package providing the {Wx::PG} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxPropertyGrid control like:
 
-- `Wx::PG::PropertyGrid`
-- `Wx::PG::PropertyGridManager`
-- `Wx::PG::PGCell`
-- `Wx::PG::PGProperty`
-- `Wx::PG::PropertyGridEvent`
+- {Wx::PG::PropertyGrid}
+- {Wx::PG::PropertyGridManager}
+- {Wx::PG::PGCell}
+- {Wx::PG::PGProperty}
+- {Wx::PG::PropertyGridEvent}
 - etc
 
 ### PRT - Printing framework classes
 
-The wxRuby PRT package providing the `Wx::PRT` module.
+The wxRuby PRT package providing the {Wx::PRT} module.
 This package includes all classes, constants and enum definitions that are considered part of the
 wxWidgets Printing framework like:
 
-- `Wx::PRT::PreviewFrame`
-- `Wx::PRT::Printer`
-- `Wx::PRT::PrinterDC`
-- `Wx::PRT::PrintDialog`
+- {Wx::PRT::PreviewFrame}
+- {Wx::PRT::Printer}
+- {Wx::PRT::PrinterDC}
+- {Wx::PRT::PrintDialog}
 - etc
 
 ### RBN - Ribbon framework classes
 
-The wxRuby RBN package providing the `Wx::RBN` module.
+The wxRuby RBN package providing the {Wx::RBN} module.
 This package includes all classes, constants and enum definitions that are considered part of the
 wxWidgets Ribbon framework like:
 
-- `Wx::RBN::RibbonControl`
-- `Wx::RBN::RibbonGallery`
-- `Wx::RBN::RibbonPanel`
-- `Wx::RBN::RibbonPage`
-- `Wx::RBN::RibbonBar`
+- {Wx::RBN::RibbonControl}
+- {Wx::RBN::RibbonGallery}
+- {Wx::RBN::RibbonPanel}
+- {Wx::RBN::RibbonPage}
+- {Wx::RBN::RibbonBar}
 - etc
 
 ### RTC - RichText control and related classes
 
-The wxRuby RTC package providing the `Wx::RTC` module.
+The wxRuby RTC package providing the {Wx::RTC} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxRichTextCtrl control like:
 
-- `Wx::RTC::RichTextCtrl`
-- `Wx::RTC::RichTextEvent`
-- `Wx::RTC::RichTextBuffer`
+- {Wx::RTC::RichTextCtrl}
+- {Wx::RTC::RichTextEvent}
+- {Wx::RTC::RichTextBuffer}
 - etc
 
 ### STC - StyledText control and related classes
 
-The wxRuby STC package providing the `Wx::STC` module.
+The wxRuby STC package providing the {Wx::STC} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxStyledTextCtrl control (Scintilla integration) like:
 
-- `Wx::STC::StyledTextCtrl`
-- `Wx::STC::StyledTextEvent`
+- {Wx::STC::StyledTextCtrl}
+- {Wx::STC::StyledTextEvent}
 
 ## Feature dependencies
 

data/lib/wx/doc/extra/02_lifecycles.md

@@ -76,7 +76,7 @@ As mentioned above the wxWidgets GUI framework resources will only be fully init
 starts. Likewise the framework resources will be de-initialized (deleted) after `#on_exit` method ends which means that 
 your application should not attempt to access any of these resources (windows, fonts, colours etc.) after that moment.
 
-Also, largely because of the way the wxWidgets framework is designed but also because of that way this meshes with Ruby 
+Also, largely because of the way the wxWidgets framework is designed but also because of the way this meshes with Ruby 
 GC, there is no safe way to re-initialize the framework after an application instance ends it run. This means you 
 **cannot** safely attempt to start another application instance after a previous (first) one has ended. 
 
@@ -120,7 +120,7 @@ therefor provides special support to ease handling the destruction of these. See
 One of the trickier things to handle correctly in the kind of native extensions like wxRuby is maintaining object 
 identities i.e. keeping native instances synced with their Ruby wrapper counter parts.
 
-Whenever a native extension is allowed to call back into Ruby space we encounter the problem the we need to map any 
+Whenever a native extension is allowed to call back into Ruby space we encounter the problem that we need to map any 
 native object data provided for the call to the right Ruby types and when necessary to the right Ruby instance (object
 identity).
 
@@ -131,8 +131,8 @@ passing them on to Ruby space.
 For a lot of other objects though it is essential to not only map to the right **most derived** class type but also to
 the exact Ruby instance which was originally instantiated as wrapper for the native object if any exists (in case no
 Ruby instance existed yet a new instance of the correct **most derived** class should be instantiated at that point). 
-The reason this is important is 1. because the Ruby instance may have been used to identify, link to or otherwise 
-reference other data and/or functionality related to that specific Ruby/native pair and 2. the Ruby instance could 
+The reason this is important is **1.** because the Ruby instance may have been used to identify, link to or otherwise 
+reference other data and/or functionality related to that specific Ruby/native pair and **2.** the Ruby instance could 
 contain data elements (instance variables) related to that specific Ruby/native pair.<br>
 In the case of wxRuby Window instance for example it is common to derive custom Window classes with custom behaviour and
 corresponding instance variables that drive that behaviour. When an event handler or an overloaded native method is passed
@@ -155,11 +155,12 @@ There are however quite a lot of wrapped native objects in wxRuby for which *obj
 object tracking has been disabled for their classes. This means these kind of classes/object should **not** be derived from
 (if even possible and/or useful) to add functionality/information or their identity used as key to link other information.<br>
 These classes include:
-- classes considered POD types like Wx::Size, Wx::Point, Wx::RealPoint, Wx::Rect, Wx::GBSpan, Wx::GBPosition, Wx::BusyInfoFlags,
+* classes considered POD types like Wx::Size, Wx::Point, Wx::RealPoint, Wx::Rect, Wx::GBSpan, Wx::GBPosition, Wx::BusyInfoFlags,
 Wx::AboutDialogInfo
-- final non-instantiatable classes like the Wx::DC (Device Context) class family, Wx::GraphicsContext, Wx::WindowsDisabler,
+* final non-instantiatable classes like the Wx::DC (Device Context) class family, Wx::GraphicsContext, Wx::WindowsDisabler,
 Wx::EventBlocker, Wx::BusyInfo
-- classes with native singleton objects like Wx::Clipboard
-- the reference counted GDI objects like Wx::Pen, Wx::Brush, Wx::Colour, Wx::Cursor, Wx::Bitmap, Wx::Icon
+* classes with native singleton objects like Wx::Clipboard
+* the reference counted GDI objects like Wx::Pen, Wx::Brush, Wx::Colour, Wx::Cursor, Wx::Bitmap, Wx::Icon and similar 
+reference counted objects like Wx::Font
 
 The reference documentation will note untracked object classes.

data/lib/wx/doc/extra/05_event-handling.md

@@ -15,8 +15,9 @@ Instead wxRuby offers a dynamic solution that is just as easy to use and even of
 ## Event handlers
 
 Instead of the `EVT_XXX` event handler declaration macros used in wxWidgets wxRuby provides similarly named event handler 
-definition methods for each of the known event declarations which are inherited by **all** classes derived from `Wx::EvtHandler`
-(which includes all window classes, the `Wx::App` class and `Wx::Timer` as well as various other classes).<br>
+definition methods for each of the known event declarations which are inherited by **all** classes derived from {Wx::
+EvtHandler}
+(which includes all window classes, the {Wx::App} class and {Wx::Timer} as well as various other classes).<br>
 
 Naming is (mostly) identical but rubified. So `EVT_MENU` becomes `evt_menu`, `EVT_IDLE` becomes `evt_idle`, `EVT_UPDATE_UI`
 becomes `evt_update_ui` etc.
@@ -27,7 +28,7 @@ Like the event handler macros some of these methods require a single (window) id
 
 Event handler setup is typically something done during the initialization of an event handler object (like a window) but
 this is not required. As all event handlers are assigned dynamically in wxRuby you can setup (some) event handlers at a 
-later moment. You could also disconnect earlier activated handlers at any time (see `Wx::EvtHandler#disconnect`).
+later moment. You could also disconnect earlier activated handlers at any time (see {Wx::EvtHandler#disconnect}).
 
 In case of some frame class `MyForm` including a menu a wxWidgets static event handling table like:
 
@@ -96,7 +97,7 @@ will take care of checking and handling method arity.
 
 Custom event definitions are fully supported in wxRuby including the definition of new event types.
 
-New event classes can be registered with `Wx::EvtHandler#register_class` which returns the new event type for the event 
+New event classes can be registered with {Wx::EvtHandler#register_class} which returns the new event type for the event 
 class like this:
 
 ```ruby
@@ -125,27 +126,27 @@ Check the reference documentation [here](https://mcorino.github.io/wxRuby3/Wx/Ev
 
 ## Event processing
 
-In wxRuby overruling the normal chain of event handling has been limited to being able to override the default 
-`Wx::EvtHandler#try_before` and `Wx::EvtHandler#try_after` methods. These are the advised interception points for events
+In wxRuby overruling the normal chain of event handling has been limited to being able to override the default
+{Wx::EvtHandler#try_before} and {Wx::EvtHandler#try_after} methods. These are the advised interception points for events
 when you really need to do this.<br>
-Overriding `Wx::EvtHandler#process_event` is not considered to be efficient (or desired)
+Overriding {Wx::EvtHandler#process_event} is not considered to be efficient (or desired)
 for wxRuby applications and has therefor been blocked.
 
 ## Event insertion
 
-Use of `Wx::EvtHandler#process_event` or `Wx::EvtHandler#queue_event` and `Wx::EvtHandler#add_pending_event` in wxRuby to
+Use of {Wx::EvtHandler#process_event} or {Wx::EvtHandler#queue_event} and {Wx::EvtHandler#add_pending_event} in wxRuby to
 trigger event processing of user generated (possibly custom) events is fully supported.
 
-As with wxWidgets `Wx::EvtHandler#process_event` will trigger immediate processing of the given event, not returning before
+As with wxWidgets {Wx::EvtHandler#process_event} will trigger immediate processing of the given event, not returning before
 this has finished.<br>
-`Wx::EvtHandler#queue_event` and `Wx::EvtHandler#add_pending_event` on the other hand will post (append) the given event
+{Wx::EvtHandler#queue_event} and {Wx::EvtHandler#add_pending_event} on the other hand will post (append) the given event
 to the event queue and return immediately after that is done. The event will than be processed after any other events in
 the queue. Unlike in wxWidgets in wxRuby there is no practical difference between `queue_event` and `add_pending_event`.
 
 ## Asynchronous execution
 
-In addition to `Wx::EvtHandler#queue_event` and `Wx::EvtHandler#add_pending_event` to trigger asynchronous processing 
-wxRuby also supports `Wx::EvtHandler#call_after`.
+In addition to {Wx::EvtHandler#queue_event} and {Wx::EvtHandler#add_pending_event} to trigger asynchronous processing 
+wxRuby also supports {Wx::EvtHandler#call_after}.
 
 This method provides the means to trigger asynchronous execution of arbitrary code and because it has been rubified is
 easy and powerful to use. Like with event handler definition this method accepts a `Symbol` or `String` (identifying a 
@@ -164,3 +165,27 @@ evt_handler.call_after(->(txt) { Wx.log_info(txt) }, "Hello")
 # async call of block
 evt_handler.call_after('Call nr. %d', 1) { |fmt, num| Wx.log_info(fmt, num) }
 ```
+
+## Event life cycles!
+
+Like in C++ the wxRuby Event objects passed to the event handlers are (in general) references to **temporary** objects 
+which are only safe to access within the execution scope of the event handler that received the reference.
+If you *need* (really?) to store a reference to such an object do so to a cloned version (see {Wx::Event#clone}) and **not**
+to the original object otherwise you **will** run into 'Object already deleted' exceptions.
+
+Only user defined events instantiated in Ruby code (or cloned Event objects) will be subject to Ruby's normal life cycle 
+rules (GC).
+This means that when you instantiate a user defined event and pass it to {Wx::EvtHandler#process_event} it would be possible
+to directly store the reference to such an Event object passed to it's event handler. You have to **know** for sure though
+(see below). So, in case of doubt (or to be safe) use {Wx::Event#clone}.
+
+Another 'feature' to be aware of is the fact that when passing an (user instantiated) Event object to {Wx::
+EvtHandler#queue_event} 
+or {Wx::EvtHandler#add_pending_event} the Ruby event instance is unlinked from it's C++ counterpart (or in the case of user
+defined events a cloned instance is associated with it's C++ counterpart) before being queued and the C++ side now takes ownership 
+(and will delete the Event object when handled).  
+As a result this means that even in the case of a user defined Event object any event handler triggered by a asynchronously 
+processed event will be handling a temporary Event object.
+Additionally this also means that any Event object passed to {Wx::EvtHandler#queue_event} or {Wx::
+EvtHandler#add_pending_event}
+is essentially invalidated after these methods return and should not be referenced anymore.

data/lib/wx/doc/extra/06_geometry.md

@@ -19,13 +19,13 @@ Wx::Frame.new(nil, -1, 'title', Wx::Point.new(0,0), Wx::Size.new(500,400))
 which starts to feel awkward to specify what are in essence just pairs of integers.
 
 To provide a simpler, more compact and more Ruby-like, alternative the wxRuby API therefor supports specifying arrays
-of integer (or float in case of Wx::RealPoint) pairs in (almost) all cases where `Wx::Size` or `Wx::Point` 
-(or Wx::RealPoint) is expected. So the following code is equivalent to the previous code:
+of integer (or float in case of {Wx::RealPoint}) pairs in (almost) all cases where {Wx::Size} or {Wx::Point} 
+(or {Wx::RealPoint}) is expected. So the following code is equivalent to the previous code:
 ```ruby
 Wx::Frame.new(nil, -1, 'title', [0,0], [500,400])
 ```
 
-In addition `Wx::Size`, `Wx::Point` and `Wx::RealPoint` support parallel assignment semantics such that you can write code like
+In addition {Wx::Size}, {Wx::Point} and {Wx::RealPoint} support parallel assignment semantics such that you can write code like
 ```ruby
   win.paint do | dc |
     # ...    
@@ -47,12 +47,12 @@ instead of
 Instances of these classes can also be converted (back) to arrays with their `#to_ary` methods.
 
 Lastly wxRuby also extends the standard Ruby Array class with conversion methods to explicitly convert
-arrays to `Wx::Size`, `Wx::Point` or `Wx::RealPoint`; respectively the `#to_size`, `#to_point` and `#to_real_point` 
+arrays to {Wx::Size}, {Wx::Point} or {Wx::RealPoint}; respectively the `#to_size`, `#to_point` and `#to_real_point` 
 methods.
 
 ## Areas (Wx::Rect)
 
-Like `Wx::Size` and `Wx::Point` wxRuby supports parallel assignment for `Wx::Rect` such that you can write code like
+Like {Wx::Size} and {Wx::Point} wxRuby supports parallel assignment for {Wx::Rect} such that you can write code like
 ```ruby
 x, y, width, height = win.get_client_rect
 ```

data/lib/wx/doc/extra/07_colour_and_font.md

@@ -21,7 +21,7 @@ For the wxRuby API similar support has been achieved for various much used argum
 
 ## Colour
 
-Wherever a `Wx::Colour` object is expected as an argument wxRuby supports the specification of `String` or `Symbol`
+Wherever a {Wx::Colour} object is expected as an argument wxRuby supports the specification of `String` or `Symbol`
 values as a developer friendly alternative. This way the following code is equivalent:
 
 ```ruby
@@ -37,7 +37,7 @@ pen.set_colour(:CYAN)
 
 ## Font
 
-Wherever a `Wx::Font` object is expected as an argument wxRuby supports the specification of a `Wx::FontInfo` object.
+Wherever a {Wx::Font} object is expected as an argument wxRuby supports the specification of a {Wx::FontInfo} object.
 This way the following code is equivalent:
 
 ```ruby

data/lib/wx/doc/extra/09_exceptions.md

@@ -15,7 +15,7 @@ your own Ruby application code.
 
 Any exceptions raised from wxRuby wrapper code signal coding errors that need to be rectified.
 
-As far as handling application code exceptions is concerned the same advice applies as for wxWidgets itself; do **not**
+As far as handling application code exceptions is concerned the same advice applies as for wxWidgets itself; do **NOT**
 let exceptions escape your event handlers meaning that if you can reasonably expect application code to raise exceptions
 you should make sure to catch any such exceptions within the context of the event handler like:
 
@@ -50,5 +50,5 @@ end
 
 In wxRuby event handler code is executed in an exception safe way which will capture any leaking exceptions. As wxRuby 
 however has no idea why this exception was raised and how to handle it, the result will be an exit of the main event loop
-of the running `Wx::App` instance and re-raising the exception to be handled by Ruby like any unhandled application 
+of the running {Wx::App} instance and re-raising the exception to be handled by Ruby like any unhandled application 
 exception.

data/lib/wx/doc/extra/10_art.md

@@ -18,8 +18,8 @@ Art that is part of the application's design will preferably be stored with the
 is not standard for this nor is there any standard support for locating those files from the application
 code like there is for `require`-s of other code modules.
 
-The wxRuby framework provides a convenience module `Wx::ArtLocator` to assist in that respect.
-Wx::ArtLocator aims on the one side to standardize folder structures for storing art files and on the
+The wxRuby framework provides a convenience module {Wx::ArtLocator} to assist in that respect.
+{Wx::ArtLocator} aims on the one side to standardize folder structures for storing art files and on the
 other side to provide runtime support for locating those files from code.
 
 The main locator method provided is:
@@ -63,41 +63,47 @@ The first location can be skipped by specifying `nil` for 'art_type'.
 
 ## Bitmap types
 
-Based on platform and specified '<art_type>' (and optionally a specific Wx::BitmapType) art files with a specific
+Based on platform and specified '<art_type>' (and optionally a specific {Wx::BitmapType}) art files with a specific
 range of extensions will be tested in a specific order.
 For example for locating an `:icon` (<art_type>) on platform 'WXGTK' the locator will test the preferred extension
 '.xpm' followed by any of supported extensions of all other supported bitmap types.
 For platform 'WXMSW' however the same search would test only the extensions '.ico' and '.xpm' (in that
 order).
-Specifying a specific Wx::BitmapType for a search will restrict the search to testing only the extensions supported
-for the specified Wx::BitmapType.
+Specifying a specific {Wx::BitmapType} for a search will restrict the search to testing only the extensions supported
+for the specified {Wx::BitmapType}.
 
 ## Search paths
 
-To prevent having to specify base search path for every location request Wx::Locator provides 2 options.
+To prevent having to specify base search path for every location request {Wx::Locator} provides 2 options.
 
 When an explicit specification of a base search path ('art_path) is omitted from a location request the locator
 will determine one by using `Kernel#caller_locations` to extract the absolute path for the source file containing
 the caller's code. The result of `File.dirname(src_path)` is than used as base search path.
 If 'art_section' is also omitted the result of `File.basename(src_path, '.*')` will be used instead.
 
-This means that calling `Wx::ArtLocator.find_art` from some code in file `/some/lib/path/to/ruby/code.rb` without 
+This means that calling {Wx::ArtLocator.find_art} from some code in file `/some/lib/path/to/ruby/code.rb` without 
 specifying both 'art_path' and 'art_section' would result in looking for an art file with the base search path
 being `/some/lib/path/to/ruby/` and using `code` as 'art_section'.
 
-It is also possible to add 'application global' search paths with the method `Wx::ArtLocator.add_search_path`.
+It is also possible to add 'application global' search paths with the method {Wx::ArtLocator.add_search_path}.
 Search paths added in this way will be tested after failing to find any matching art file at the initial 'art_path'
 location. The same location steps apply to these search paths as with the initial 'art_path' (see above).
 
 ## Convenience methods
 
-Based on the Wx::ArtLocator implementation wxRuby additionally provides a number of convenience methods to
-easily create Icons, Bitmaps, Cursors and Images from simple ids (symbols).
+Based on the {Wx::ArtLocator} implementation wxRuby additionally provides a number of convenience methods to
+easily create Icons, Bitmaps, Cursors and Images from simple ids (symbols):
+
+- {Wx.Bitmap} 
+- {Wx.Cursor} 
+- {Wx.Icon} 
+- {Wx.Image}
+
 These methods mimic the ease of use of the `wxICON` and `wxBITMAP` macros used with C++ wxWidgets such that
-creating an Wx::Icon instance could be as easy as:
+creating an {Wx::Icon} instance could be as easy as:
 
 ```ruby
-    frame.icon = Wx::Icon(:sample)
+    frame.icon = Wx.Icon(:sample)
 ```
 
 As these methods apply the same search path 'automagic' as `Wx::ArtLocator.find_art` (see [Search paths](#Search-paths))