diff --git a/Manifest.txt b/Manifest.txt
index 2a2775f33c84ec5b7d8e82e41e937a1e9d0125f4..7222d3034d2c15bafed29a6ea5891d817b47fd89 100644
--- a/Manifest.txt
+++ b/Manifest.txt
@@ -919,100 +919,3 @@ test/stress1.rb
test/stress2.rb
test/stress3.rb
test/testcase.rb
-users_guide/Makefile
-users_guide/apes02.html
-users_guide/apes03.html
-users_guide/book.html
-users_guide/book.xml
-users_guide/bookinfo.xml
-users_guide/build.html
-users_guide/build.xml
-users_guide/ch03s02.html
-users_guide/ch03s03.html
-users_guide/ch03s04.html
-users_guide/ch03s05.html
-users_guide/ch04s02.html
-users_guide/ch04s03.html
-users_guide/ch04s04.html
-users_guide/ch05s02.html
-users_guide/ch05s03.html
-users_guide/changes.html
-users_guide/changes.xml
-users_guide/clipboardtut.html
-users_guide/clipboardtut.xml
-users_guide/custom-fo.xsl
-users_guide/custom-html.xsl
-users_guide/differences.html
-users_guide/differences.xml
-users_guide/dragdroptut.html
-users_guide/dragdroptut.xml
-users_guide/events.html
-users_guide/events.xml
-users_guide/examples.html
-users_guide/examples.xml
-users_guide/gems.html
-users_guide/gems.xml
-users_guide/goals.html
-users_guide/goals.xml
-users_guide/images/babelfish.png
-users_guide/images/browser.png
-users_guide/images/button.png
-users_guide/images/call-chain-example.dia
-users_guide/images/call-chain-example.png
-users_guide/images/colordialog.png
-users_guide/images/datatarget.png
-users_guide/images/dialog.png
-users_guide/images/dilbert.png
-users_guide/images/dirlist.png
-users_guide/images/dropsite-droprejected.png
-users_guide/images/foursplit.png
-users_guide/images/gltest.png
-users_guide/images/glviewer.png
-users_guide/images/groupbox.png
-users_guide/images/header.png
-users_guide/images/hello-with-button.png
-users_guide/images/hello-with-icon-1.png
-users_guide/images/hello-with-icon-2.png
-users_guide/images/hello-with-icon-3.png
-users_guide/images/hello-with-tooltip.png
-users_guide/images/hello-without-button.png
-users_guide/images/hello.png
-users_guide/images/hello2.png
-users_guide/images/iconlist-bigicons.png
-users_guide/images/iconlist-details.png
-users_guide/images/image.png
-users_guide/images/imageviewer.png
-users_guide/images/inheritance.dia
-users_guide/images/inheritance.png
-users_guide/images/mditest.png
-users_guide/images/raabrowser.png
-users_guide/images/scribble.png
-users_guide/images/shutter.png
-users_guide/images/splitter.png
-users_guide/images/tabbook.png
-users_guide/images/table.png
-users_guide/images/tutorial1.png
-users_guide/implementation.html
-users_guide/implementation.xml
-users_guide/infosources.html
-users_guide/infosources.xml
-users_guide/layout.xml
-users_guide/library.html
-users_guide/library.xml
-users_guide/maintainer.xml
-users_guide/opengl.html
-users_guide/opengl.xml
-users_guide/preface.xml
-users_guide/pt01.html
-users_guide/pt02.html
-users_guide/scintilla.html
-users_guide/scintilla.xml
-users_guide/style.css
-users_guide/subversion.html
-users_guide/subversion.xml
-users_guide/template.xml
-users_guide/todo.xml
-users_guide/tutorial1.html
-users_guide/tutorial1.xml
-users_guide/unicode.html
-users_guide/unicode.xml
diff --git a/Rakefile b/Rakefile
index d871ded1738cbac8e2fb25fb9fcdcc57dc2fdcc2..dbf51fdb339397bddc618696a38c33c143be8da1 100755
--- a/Rakefile
+++ b/Rakefile
@@ -37,7 +37,7 @@ task :test => [:compile]
# rdoc_files.reject! {|x| x == "ext/fox16" }
# Make sure that all of the package contents exist before we try to build the package
-#Rake::Task['package'].prerequisites.unshift("swig:swig", "fxruby:guide", "fxruby:setversions", "fxruby:generate_kwargs_lib")
+#Rake::Task['package'].prerequisites.unshift("swig:swig", "fxruby:setversions", "fxruby:generate_kwargs_lib")
# ... project specific tasks ...
@@ -162,13 +162,6 @@ namespace :fxruby do
setversions("doap.rdf")
end
- desc "Generate the user's guide"
- task :guide do
- Dir.chdir "users_guide" do
- system %{make}
- end
- end
-
def make_impl
Dir.chdir "ext/fox16" do
ruby "make_impl.rb"
diff --git a/users_guide/Makefile b/users_guide/Makefile
deleted file mode 100755
index b4fefeb10f6ff9665f99298250479ab01eaa5135..0000000000000000000000000000000000000000
--- a/users_guide/Makefile
+++ /dev/null
@@ -1,24 +0,0 @@
-########################################################################
-#
-# Generate the HTML documents from DocBook sources
-#
-########################################################################
-
-#SAXON = java -jar /Users/lyle/saxon-8.9/saxon8.jar
-SAXON = java -jar /Users/lyle/saxon-6.5.5/saxon.jar
-HTML_STYLESHEET = custom-html.xsl
-#FO_STYLESHEET = custom-fo.xsl
-FO_STYLESHEET = /Users/lyle/docbook/docbook5-xsl-1.72.0/fo/docbook.xsl
-FOP = /Users/lyle/fop-0.93/fop
-
-all: html
-
-html:
- $(SAXON) book.xml $(HTML_STYLESHEET)
-
-pdf:
- $(SAXON) book.xml $(FO_STYLESHEET) > book.fo
- $(FOP) book.fo book.pdf
-
-clean:
- @rm -f *.html book.fo book.pdf
diff --git a/users_guide/book.xml b/users_guide/book.xml
deleted file mode 100755
index e36a5527fe08ac318fa900348ec39e9c65f0be69..0000000000000000000000000000000000000000
--- a/users_guide/book.xml
+++ /dev/null
@@ -1,51 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE book
- PUBLIC "-//OASIS//DTD DocBook V5.0//EN"
- "file:/Users/lyle/docbook/xml/5.0/dtd/docbook.dtd" [
-<!ENTITY bookinfo.xml SYSTEM "bookinfo.xml">
-<!ENTITY build.xml SYSTEM "build.xml">
-<!ENTITY changes.xml SYSTEM "changes.xml">
-<!ENTITY subversion.xml SYSTEM "subversion.xml">
-<!ENTITY differences.xml SYSTEM "differences.xml">
-<!ENTITY clipboardtut.xml SYSTEM "clipboardtut.xml">
-<!ENTITY dragdroptut.xml SYSTEM "dragdroptut.xml">
-<!ENTITY examples.xml SYSTEM "examples.xml">
-<!ENTITY events.xml SYSTEM "events.xml">
-<!ENTITY gems.xml SYSTEM "gems.xml">
-<!ENTITY goals.xml SYSTEM "goals.xml">
-<!ENTITY implementation.xml SYSTEM "implementation.xml">
-<!ENTITY infosources.xml SYSTEM "infosources.xml">
-<!ENTITY layout.xml SYSTEM "layout.xml">
-<!ENTITY library.xml SYSTEM "library.xml">
-<!ENTITY opengl.xml SYSTEM "opengl.xml">
-<!ENTITY scintilla.xml SYSTEM "scintilla.xml">
-<!ENTITY tutorial1.xml SYSTEM "tutorial1.xml">
-<!ENTITY unicode.xml SYSTEM "unicode.xml">
-]>
-<book id="book" lang="en" xmlns="http://docbook.org/ns/docbook">
-&bookinfo.xml;
-<part label="I">
-<title>The Basics</title>
-&goals.xml;
-&build.xml;
-&gems.xml;
-&tutorial1.xml;
-&clipboardtut.xml;
-&dragdroptut.xml;
-&unicode.xml;
-&examples.xml;
-&events.xml;
-<!--&layout.xml;-->
-&infosources.xml;
-&changes.xml;
-</part>
-<part label="II">
-<title>Appendices</title>
-&opengl.xml;
-&scintilla.xml;
-&differences.xml;
-&library.xml;
-&implementation.xml;
-&subversion.xml;
-</part>
-</book>
diff --git a/users_guide/bookinfo.xml b/users_guide/bookinfo.xml
deleted file mode 100755
index 71bdb0464c4f1359100302ab2bab5bfb4072ab95..0000000000000000000000000000000000000000
--- a/users_guide/bookinfo.xml
+++ /dev/null
@@ -1,12 +0,0 @@
-<bookinfo>
- <title>Developing Graphical User Interfaces with FXRuby</title>
- <subtitle>Covers FXRuby Version 1.6</subtitle>
- <author>
- <surname>Johnson</surname>
- <firstname>Lyle</firstname>
- </author>
- <copyright>
- <year>2006</year>
- <holder>J. Lyle Johnson</holder>
- </copyright>
-</bookinfo>
diff --git a/users_guide/build.xml b/users_guide/build.xml
deleted file mode 100755
index 7eec0f577675fe5fb6f4be1c77b52c0f9d462e64..0000000000000000000000000000000000000000
--- a/users_guide/build.xml
+++ /dev/null
@@ -1,296 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="build">
- <title>Building from Source Code</title>
-
- <para>This chapter provides instructions for building and installing FXRuby
- directly from source, and not using some more direct means (such as
- installing a gem, or via some package manager).</para>
-
- <itemizedlist>
- <listitem>
- <para>If you're planning to use FXRuby on Windows, with the standard
- <ulink url="http://rubyinstaller.rubyforge.org">Ruby Installer for
- Windows</ulink>, you may wish to just download the pre-compiled binaries
- from the <ulink url="http://rubyforge.org/projects/fxruby">RubyForge
- project page</ulink> for FXRuby.</para>
- </listitem>
-
- <listitem>
- <para>If you're already using the <ulink
- url="http://www.macports.org/">MacPorts</ulink> version of ruby, you may
- wish to just install the <filename>rb-fxruby</filename> port.</para>
- </listitem>
- </itemizedlist>
-
- <simplesect>
- <title>Building From Source on Unix/Linux</title>
-
- <para>These instructions assume that you've already downloaded, compiled
- and installed FOX. Next, you'll need to download the FXRuby source code
- tarball and unpack it by typing:</para>
-
- <screen>$ <command>tar xzf FXRuby-1.6.13.tar.gz</command></screen>
-
- <para>This will create a new directory called <filename
- class="directory">FXRuby-1.6.13</filename>. Change to the top-level
- directory and configure the build by typing:</para>
-
- <screen>$ <command>ruby install.rb config</command></screen>
-
- <para>By default, the <filename>install.rb</filename> script will look for
- the FOX include files and library in the standard <filename
- class="directory">/usr/local/include/fox-1.6</filename> and <filename
- class="directory">/usr/local/lib</filename> directories, respectively. You
- can override these locations by passing a few additional arguments to
- <filename>install.rb</filename> during this step, e.g.</para>
-
- <screen>$ <command>ruby install.rb config -- \
- --with-fox-include=/home/lyle/fox-1.6.32/include \
- --with-fox-lib=/home/lyle/fox-1.6.32/src/.libs</command></screen>
-
- <para>Once the build has been configured, you can start the build by
- typing:</para>
-
- <screen>$ <command>ruby install.rb setup</command></screen>
-
- <para>It will take quite awhile to build FXRuby, even on a fast machine,
- so this might be a good time to take a coffee break. If you run into
- problems during the compilation, please check the <link
- linkend="tragedies">list of things that can go wrong</link> for
- workarounds for those problems.</para>
-
- <para>Once it's finished compiling, install FXRuby by typing:</para>
-
- <screen>$ <command>ruby install.rb install</command></screen>
-
- <para>As a quick sanity check, to make sure that all is well, you should
- probably fire up <filename>irb</filename> and try to import FXRuby:</para>
-
- <screen>$ <command>irb</command>
-irb(main):001:0> <userinput>require 'fox16'</userinput>
-true
-irb(main):002:0></screen>
-
- <para>If the import failed (usually with a message along the lines of
- "Cannot load library"), check the <link linkend="tragedies">list of things
- that can go wrong</link> for known problems. If that still doesn't solve
- your problem, drop me an e-mail or ask around on the Ruby newsgroup or
- mailing list; it's quite likely that someone else has run into this
- problem too. Once you do have a working FXRuby installation, you're ready
- to check out the example programs.</para>
- </simplesect>
-
- <simplesect>
- <title>Building From Source on Windows (Using Visual C++)</title>
-
- <para>This section describes how to compile FXRuby using Microsoft Visual
- C++, for use with a Ruby that was also compiled using Visual C++.</para>
-
- <para>This discussion assumes that you've built Ruby using the
- instructions and build files distributed with the standard Ruby source
- code. To review, you should have started by unpacking the source code
- tarball, changing into the top-level source code directory (e.g. <filename
- class="directory">C:\ruby-1.8.6</filename>) and then typing:</para>
-
- <screen>C:\ruby-1.8.6><command>win32\configure</command>
-type 'nmake' to make ruby for mswin32.
-C:\ruby-1.8.6><command>nmake</command></screen>
-
- <para>After the compilation finished, you installed Ruby somewhere by
- typing, e.g.,</para>
-
- <screen>C:\ruby-1.8.6><command>nmake DESTDIR=C:\ruby install</command></screen>
-
- <para>Similarly, I'm assuming that you built the FOX library using the
- Developer Studio project files distributed with the standard FOX source
- code distribution.</para>
-
- <para>Now you can configure the FXRuby build by typing:</para>
-
- <screen>C:\FXRuby-1.6.13><command>ruby install.rb config --make-prog=nmake -- \
- --with-fox-include=C:\fox-1.6.32\include \
- --with-fox-lib=C:\fox-1.6.32\lib</command></screen>
-
- <para>Once the build has been configured, you can start the build by
- typing:</para>
-
- <screen>C:\FXRuby-1.6.13> <command>ruby install.rb setup</command></screen>
-
- <para>It will take quite awhile to build FXRuby, even on a fast machine,
- so this might be a good time to take a coffee break. Because Visual C++ is
- such a strict compiler (usually a good thing), you will probably run into
- a few problems with non-ANSI declarations in the Ruby header files. If you
- do run into problems during the compilation, just check the next section
- for a list of things that could go wrong, and workarounds for those
- problems. None of them are showstoppers and none require you to restart
- the compile from scratch (just type <command>ruby install.rb
- setup</command> to pick up where you left off).</para>
-
- <para>Once it's finished compiling, install FXRuby by typing:</para>
-
- <screen>C:\FXRuby-1.6.13> <command>ruby install.rb install</command></screen>
-
- <para>As a quick sanity check, to make sure that all is well, you should
- probably fire up <filename>irb</filename> and try to import FXRuby:</para>
-
- <screen>C:\FXRuby-1.6.13> <command>irb</command>
-irb(main):001:0> <userinput>require 'fox16'</userinput>
-true
-irb(main):002:0></screen>
-
- <para>If the import failed (usually with a message along the lines of
- "Cannot load library"), check the list of things that can go wrong for
- known problems. If that still doesn't solve your problem, drop me an
- e-mail or ask around on the Ruby newsgroup or mailing list; it's quite
- likely that someone else has run into this problem too. Once you do have a
- working FXRuby installation, you're ready to check out the example
- programs.</para>
- </simplesect>
-
- <simplesect id="tragedies">
- <title>Things That Can Go Wrong</title>
-
- <para><emphasis>"Too many arguments to function..."</emphasis></para>
-
- <para>The include files for Ruby versions 1.6.7 and earlier still have
- several function prototypes in the older "K & R" C style, where the
- function's argument list is not included; for example, the function
- <function>rb_thread_wait_for()</function> takes a single argument of type
- <type>struct timeval</type>, but its prototype in
- <filename>intern.h</filename> is:</para>
-
- <programlisting format="linespecific">void rb_thread_wait_for();</programlisting>
-
- <para>Because FXRuby is written in C++, and C++ requires strict ANSI
- C-style function prototypes, code that attempts to call one of these
- functions will fail to compile under some compilers. For example, the
- error message from gcc will look something like this:</para>
-
- <screen>FXRbApp.cpp: In method `long int FXRbApp::onChoreThreads (FXObject *, unsigned int, void *)':
-/usr/local/lib/ruby/1.8/i686-linux/intern.h:172: too many arguments to function `void rb_thread_wait_for ()'
-FXRbApp.cpp:100: at this point in file
-make: *** [FXRbApp.o] Error 1</screen>
-
- <para>while the error message from Microsoft's Visual C++ compiler looks
- something like this:</para>
-
- <screen>FXRbApp.cpp(109): error C2660: 'rb_thread_wait_for' : function does not take 1 parameters
-NMAKE : fatal error U1077: 'cl' : return code '0x2'
-Stop.</screen>
-
- <para>This problem with the Ruby header files has been corrected for Ruby
- versions 1.6.8 (and later), but if you're building for an older version of
- Ruby you can do one of two things to work around the problem:</para>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>If you're using gcc version 2.95 or earlier, try modifying the
- compiler flags (<constant>CFLAGS</constant>) in the FXRuby
- <filename>Makefile</filename> to include the
- <option>-fno-strict-prototype</option> option; this should instruct
- the compiler to allow these kinds of discrepancies. Unfortunately,
- this flag is not supported in more recent versions of gcc.</para>
- </listitem>
-
- <listitem>
- <para>A more direct approach is to just fix the offending declarations
- in the Ruby include file(s), i.e. change the declaration for
- <function>rb_thread_wait_for()</function> in
- <filename>intern.h</filename> to read:</para>
-
- <programlisting format="linespecific">void rb_thread_wait_for(struct timeval);</programlisting>
-
- <para>and change the declaration for <function>rb_gc_mark()</function>
- in <filename>intern.h</filename> to read:</para>
-
- <programlisting format="linespecific">void rb_gc_mark(VALUE);</programlisting>
- </listitem>
- </itemizedlist>
-
- <para><emphasis>"Virtual Memory Exhausted"</emphasis></para>
-
- <para>For FXRuby releases earlier than version 0.99.173 it was common for
- the compiler to run out of memory trying to compile
- <filename>core_wrap.cpp</filename>, with an error message like:</para>
-
- <screen>core_wrap.cpp: In function 'void Init_core()':
-core_wrap.cpp:108596: virtual memory exhausted</screen>
-
- <para>This failure was due to the use of optimizations by the compiler;
- the FXRuby source code makes heavy use of C++ templates and some versions
- of gcc require a lot of memory to process these. Starting with FXRuby
- version 0.99.173, the <filename>extconf.rb</filename> script
- <emphasis>should</emphasis> disable compiler optimizations when it
- generates the FXRuby <filename>Makefile</filename>. If you suspect that
- it's not disabling optimizations (or can see this by watching the compile
- command lines), try modifying the compiler flags
- (<constant>CFLAGS</constant>) in the <filename>Makefile</filename> by hand
- to do so.</para>
-
- <para><emphasis>"Cannot load library"</emphasis></para>
-
- <para>On Linux and other Unix systems that support shared libraries, FOX
- is typically installed as a shared library named
- <filename>libFOX-1.6.so</filename>. After all of the source files for
- FXRuby are compiled, the last step is to link all of the FXRuby object
- files together with the FOX library (and possibly other system libraries)
- to produce a new shared library, named <filename>fox16.so</filename>, that
- Ruby can import as an extension module.</para>
-
- <para>There are a few things that can go wrong when you try to import this
- extension into Ruby. A common problem is that the operating system cannot
- locate the FOX shared library (<filename>libFOX-1.6.so</filename>) when it
- tries to dynamically load the FXRuby extension module; when this happens,
- the error message will look something like:</para>
-
- <screen>$ <command>irb</command>
-irb(main):001:0> <userinput>require 'fox16'</userinput>
-LoadError: libFOX-1.6.so: cannot open shared object file: No such file or directory - /usr/local/lib/ruby/1.8/i686-linux/fox16.so
- from (irb):1:in 'require'
- from (irb):1
- </screen>
-
- <para>One workaround for this problem is to modify the
- <constant>LD_LIBRARY_PATH</constant> environment variable to include the
- directory where <filename>libFOX-1.6.so</filename> is installed. For
- example, if <filename>libFOX-1.6.so</filename> is installed in <filename
- class="directory">/usr/local/lib</filename>, try setting:</para>
-
- <screen>$ <command>export LD_LIBRARY_PATH=/usr/local/lib</command>
-$ <command>irb</command>
-irb(main):001:0> <userinput>require 'fox16'</userinput>
-</screen>
-
- <para>If this works, you can of course permanently add the
- <constant>LD_LIBRARY_PATH</constant> setting to your login file(s) so that
- you don't have to remember to type it each time. Another approach that
- should work for Linux is to modify your
- <filename>/etc/ld.so.conf</filename> file to include the installation
- directory (e.g. <filename>/usr/local/lib</filename>). If you'd like to do
- this instead, you'll need to (as root):</para>
-
- <orderedlist numeration="arabic" spacing="compact">
- <listitem>
- <para>Edit your <filename>/etc/ld.so.conf</filename> file and add the
- directory where <filename>libFOX-1.6.so</filename> is installed;
- and,</para>
- </listitem>
-
- <listitem>
- <para>At the shell prompt, type <command>ldconfig</command> to reload
- the linker configuration.</para>
- </listitem>
- </orderedlist>
-
- <para><emphasis>"Undefined symbol..."</emphasis></para>
-
- <para>Another problem that has been reported by users of both Debian
- GNU/Linux and NetBSD 1.5 is an error message along the lines of:</para>
-
- <screen>/usr/lib/libstdc++.so.2: Undefined symbol "__vt_9exception"...</screen>
-
- <para>The fix for this problem is reported to be to modify the FXRuby
- <filename>Makefile</filename> and add <option>-lgcc</option> to the
- <constant>LIBS</constant> line.</para>
- </simplesect>
-</chapter>
\ No newline at end of file
diff --git a/users_guide/changes.xml b/users_guide/changes.xml
deleted file mode 100755
index b340299aefec9a23b63f574c009e92b1bfa85c96..0000000000000000000000000000000000000000
--- a/users_guide/changes.xml
+++ /dev/null
@@ -1,2003 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="changes">
- <title>Change History</title>
-
- <simplesect>
- <title>Changes For Version 1.6.20 (Unreleased)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The previous release of FXRuby couldn't be built from source against Ruby 1.9.1 final
- due to a change in some of the file-related utility libraries
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=23786&group_id=300&atid=1223">RubyForge
- Bug #23786</ulink>). This problem has been corrected.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.19 (March 6, 2009)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The previous release of FXRuby couldn't be built from source against Ruby 1.9.1 final
- due to a change in some of the file-related utility libraries
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=23786&group_id=300&atid=1223">RubyForge
- Bug #23786</ulink>). This problem has been corrected.</para>
- </listitem>
- <listitem>
- <para>The previous release of FXRuby couldn't be built from source against Ruby versions 1.8.5 or
- earlier (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=23967&group_id=300&atid=1223">RubyForge
- Bug #23967</ulink>). This problem has been corrected.</para>
- </listitem>
- <listitem>
- <para>A change in the return value for Ruby's <methodname>instance_variables</methodname> method broke
- some of the code related to message handling in FXRuby (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=23787&group_id=300&atid=1223">RubyForge
- Bug #23787</ulink>). This problem has been corrected.</para>
- </listitem>
- <listitem>
- <para>The <methodname>addAccel</methodname> method for the <classname>FXAccelTable</classname> class
- now accepts lambda functions (or any other objects that respond to <methodname>call</methodname>). See
- the <ulink url="http://www.fxruby.org/doc/api/classes/Fox/FXAccelTable.html">API documentation</ulink>
- for <classname>FXAccelTable</classname> for examples of how this works.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.18 (December 29, 2008)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Some users were having trouble building FXRuby on 64-bit operating systems
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=23375&group_id=300&atid=1223">RubyForge
- Bug #23375</ulink>). This problem has been corrected.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.17 (December 24, 2008)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The Ruby interpreter was generating a large number of warning messages about redefined methods
- in the <filename>kwargs.rb</filename> library
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=19231&group_id=300&atid=1223">RubyForge
- Bug #19231</ulink> and elsewhere). This problem has been corrected.</para>
- </listitem>
-
- <listitem>
- Due to recent changes in Ruby's garbage collection algorithm, FXRuby applications could under some circumstances
- crash for large numbers of table items
- (see RubyForge bugs <ulink url="http://rubyforge.org/tracker/index.php?func=detail&aid=21983&group_id=300&atid=1223">21983</ulink> and <ulink url="http://rubyforge.org/tracker/index.php?func=detail&aid=23188&group_id=300&atid=1223">23188</ulink>).
- This bug has been fixed.
- </listitem>
-
- <listitem>
- <para>The documentation for the <classname>FXTable</classname> class referred to the non-existent <methodname>setColumnX</methodname>
- and <methodname>setRowY</methodname> instance methods
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=21987&group_id=300&atid=1223">RubyForge
- Bug #21987</ulink>). These entries have been removed from the documentation.</para>
- </listitem>
-
- <listitem>
- <para>A number of instance methods for the <classname>FXTable</classname> class could crash an application if they
- were passed out-of-bounds index arguments
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=21987&group_id=300&atid=1223">RubyForge
- Bug #21987</ulink>). These methods now raise <classname>IndexError</classname> when they're passed out-of-bounds
- indexes.</para>
- </listitem>
-
- <listitem>
- <para>Due to a change in the URL scheme for the Dilbert web site, the <filename>dilbert.rb</filename> example
- program was no longer working properly
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=21538&group_id=300&atid=1223">RubyForge
- Bug #21538</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>lower</methodname> method for the <classname>FXRangef</classname> was returning
- <constant>self</constant> instead of an <classname>FXVec3f</classname> instance for the range's low
- bound
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=22488&group_id=300&atid=1223">RubyForge
- Bug #22488</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Made a number of minor fixes for compatibility with Ruby 1.9.1.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.16 (July 3, 2008)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Historically, if you called <methodname>create</methodname> on a
- window before its parent window was created, your application would
- crash (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=20702&group_id=300&atid=1223">RubyForge
- Bug #20702</ulink> and elsewhere). Now, the code should raise a
- <constant>RuntimeError</constant> with a message indicating the
- problem.</para>
- </listitem>
-
- <listitem>
- <para>The message data that the <classname>FXPicker</classname> widget
- sends along with its <constant>SEL_CHANGED</constant> and
- <constant>SEL_COMMAND</constant> messages wasn't being handled
- properly, and as a result, applications using this widget could crash
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=20780&group_id=300&atid=1223">RubyForge
- Bug #20780</ulink>). This problem has been fixed.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.15 (June 4, 2008)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>FXRuby applications could crash (with a segmentation fault) if
- <constant>nil</constant> was passed in as the first argument to
- <methodname>FXDialogBox.new</methodname> or
- <methodname>FXMainWindow.new</methodname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=14642&group_id=300&atid=1223">RubyForge
- Bug #14642</ulink>). These methods now raise an
- <constant>ArgumentError</constant> if <constant>nil</constant> is
- passed as the first argument.</para>
- </listitem>
-
- <listitem>
- <para>You should only ever construct one <classname>FXApp</classname>
- object per application, but there was no protection against doing so
- in the code (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=16275&group_id=300&atid=1223">RubyForge
- Bug #16275</ulink>). Now, <methodname>FXApp.new</methodname> will
- raise a <classname>RuntimeException</classname> if an
- <classname>FXApp</classname> object already exists.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>babelfish.rb</filename> example program, which
- previously depended on an external web service to perform translation
- between languages, was broken since that web service no longer exists
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=16962&group_id=300&atid=1223">RubyForge
- Bug #16962</ulink>). The example has now been updated to use Dr. Nic's
- <ulink url="http://tranexp.rubyforge.org/">Tranexp</ulink> library
- instead.</para>
- </listitem>
-
- <listitem>
- <para>The value of the <constant>MBOX_SAVE_CANCEL_DONTSAVE</constant>
- option (for the <classname>FXMessageBox</classname> class) wasn't
- wrapped properly and was unusable (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=17094&group_id=300&atid=1223">RubyForge
- Bug #17094</ulink>). There was also no constant corresponding to the
- <constant>MBOX_CLICKED_DONTSAVE</constant> return value. Both of these
- problems have been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The fields for new <classname>FXHiliteStyle</classname> objects
- were uninitialized and as a result sometimes gave unpredictable
- results (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=19637&group_id=300&atid=1223">RubyForge
- Bug #19637</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>columnHeaderFont</methodname> and
- <methodname>rowHeaderFont</methodname> attributes for
- <classname>FXTable</classname> weren't implemented properly (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=20142&group_id=300&atid=1223">RubyForge
- Bug #20142</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Ruby 1.8.7 adds a new <methodname>first</methodname> method to
- the <classname>Enumerable</classname> module, and this conflicts with
- the existing <methodname>first</methodname> method defined in the
- <classname>FXWindow</classname> base class for a number of FXRuby
- classes which mix in <classname>Enumerable</classname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=20418&group_id=300&atid=1223">RubyForge
- Bug #20418</ulink>). This problem has been resolved.</para>
- </listitem>
-
- <listitem>
- <para>Due to a bug in the <filename>extconf.rb</filename> script, the
- build was failing for Ruby 1.9.0 (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=20426&group_id=300&atid=1223">RubyForge
- Bug #20426</ulink>). This has been fixed.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.14 (March 29, 2008)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Updated the documentation for the <classname>FXImage</classname>
- class to indicate which methods call <methodname>render</methodname>
- after they're finished, and which ones do not.</para>
- </listitem>
-
- <listitem>
- <para>Corrected a little typo in the
- <filename>gembrowser.rb</filename> example program.</para>
- </listitem>
-
- <listitem>
- <para>Updated the <filename>dilbert.rb</filename> example program to
- use the more popular-and-likely-to-be-installed <ulink
- url="http://code.whytheluckystiff.net/hpricot/">Hpricot</ulink> HTML
- parser library instead of <ulink
- url="http://www.crummy.com/software/RubyfulSoup/">Rubyful
- Soup</ulink>.</para>
- </listitem>
-
- <listitem>
- <para>Re-added the documentation for the
- <constant>TOGGLEBUTTON_KEEPSTATE</constant> option, which had
- mysteriously disappeared (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2286&group_id=300&atid=1223">RubyForge
- Bug #2286</ulink>).</para>
- </listitem>
-
- <listitem>
- <para>Made a number of minor fixes to support building FXRuby against
- Ruby 1.9.</para>
- </listitem>
-
- <listitem>
- <para>Added a binary gem for OS X. This works with the Ruby that's
- included with OS X (Leopard).</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.32 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.13 (November 9, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Calls to the <methodname>extractText</methodname> method for the
- <classname>FXTable</classname> class were causing various
- memory-related errors on certain platforms (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=15444group_id=300&atid=1223">RubyForge
- Bug #15444</ulink>). This problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.28 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.12 (October 19, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The API documentation for <classname>FXMDIClient</classname>
- referred to the non-existent instance method
- <methodname>activeChild=</methodname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=10259&group_id=300&atid=1223">RubyForge
- Bug #10259</ulink>). This method has been added.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for <classname>FXMDIClient</classname>
- also referred to the non-existent instance methods
- <methodname>getMDIChildFirst</methodname> and
- <methodname>getMDIChildLast</methodname>. These entries have been
- removed.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for <classname>FXMDIChild</classname>
- referred to non-existent instance methods
- <methodname>getMDINext</methodname> and
- <methodname>getMDIPrev</methodname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=10436&group_id=300&atid=1223">RubyForge
- Bug #10436</ulink>). The documentation has been corrected.</para>
- </listitem>
-
- <listitem>
- <para>Added the <parameter>:repeat</parameter> parameter for the
- <methodname>addChore</methodname> and
- <methodname>addTimeout</methodname> methods. See the documentation for
- more details, and <filename>gltest.rb</filename> for an example of its
- use.</para>
- </listitem>
-
- <listitem>
- <para>Corrected a number of minor typos in the API
- documentation.</para>
- </listitem>
-
- <listitem>
- <para>Corrected a typo in the <filename>imageviewer.rb</filename>
- example.</para>
- </listitem>
-
- <listitem>
- <para>Modified the <filename>inputs.rb</filename> example program to
- use <methodname>Pipe.read_nonblock()</methodname> instead of
- <methodname>Pipe.read()</methodname>.</para>
- </listitem>
-
- <listitem>
- <para>Fixed a bug in the implementation of the
- <methodname>findText</methodname> method for the
- <classname>FXText</classname> class, when used with the
- <constant>SEARCH_REGEX</constant> option.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.28 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.11 (April 18, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Added <methodname>editable</methodname> as an alias for
- <methodname>FXTextField#editable?</methodname>.</para>
- </listitem>
-
- <listitem>
- <para>Added <methodname>each_child_recursive</methodname> instance
- method for the <classname>FXWindow</classname> class. This method
- performs a depth-first traversal of the widget tree starting at the
- receiver window.</para>
- </listitem>
-
- <listitem>
- <para>Corrected some errors in the keyword arguments support for the
- <classname>FXVec2d</classname>, <classname>FXVec2f</classname>,
- <classname>FXVec3d</classname>, <classname>FVec3f</classname>,
- <classname>FXVec4d</classname> and <classname>FXVec4f</classname>
- classes.</para>
- </listitem>
-
- <listitem>
- <para>Corrected an error in the keyword arguments support for the
- <classname>FXIconDict</classname> class.</para>
- </listitem>
-
- <listitem>
- <para>Modified the gem specification so that the RDoc generated during
- a gem install is consistent with that generated by other methods (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=10035&group_id=300&atid=1223">RubyForge
- Bug #10035</ulink>).</para>
- </listitem>
-
- <listitem>
- <para>Changes to the <filename>iterators</filename> library in version
- 1.6.6 introduced a bug in the <methodname>each</methodname> method for
- the <classname>FXFoldingList</classname>,
- <classname>FXTreeList</classname> and
- <classname>FXTreeListBox</classname> classes (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=10175&group_id=300&atid=1223">RubyForge
- Bug #10175</ulink>). This problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Applied submitted patches for building FXRuby against Ruby 1.9
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=10181&group_id=300&atid=1223">RubyForge
- Bug #10181</ulink>). Please note that building FXRuby against the Ruby
- 1.9 code base is still officially unsupported; however, I'm glad to
- accept patches that will help make this possible.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.25 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.9 (April 8, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>A bug was discovered in the keyword arguments library support
- for the <classname>FXMenuBar</classname> class (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=9927&group_id=300&atid=1223">RubyForge
- Bug #9927</ulink>). This problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.25 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.8 (April 5, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Due to an internal bookkeeping error, applications like the
- <filename>glviewer.rb</filename> example program which create multiple
- <classname>FXGLViewer</classname> instances could cause an assertion
- to fail. When this assertion fails on Windows, the program simply
- crashes (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=9775&group_id=300&atid=1223">RubyForge
- Bug #9775</ulink>). This problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The keyword arguments library, introduced in version 1.6.5, is
- now included automatically when you load FXRuby; it is no longer
- necessary to explicitly require it.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.25 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.7 (March 31, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.25 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.6 (February 10, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Somewhere along the way, the RAA browser example program got
- broken due to changes in the SOAP interface to RAA (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=7977&group_id=300&atid=1223">RubyForge
- Bug #7977</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Some debugging code that was meant to detect errors in FXRuby
- message data conversion was inadvertently causing some user
- applications to crash when running under Windows (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=8049&group_id=300&atid=1223">RubyForge
- Bug #8049</ulink>). This debugging code has been changed to avoid the
- problem.</para>
- </listitem>
-
- <listitem>
- <para>Modified the implementations of the each iterator methods for
- <classname>FXFoldingList</classname>,
- <classname>FXFoldingItem</classname>,
- <classname>FXTreeItem</classname>, <classname>FXTreeList</classname>
- and <classname>FXTreeListBox</classname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=8090&group_id=300&atid=1223">RubyForge
- Bug #8090</ulink>). The new implementation is a bit more robust in
- terms of modifications (such as deletion) of the iterated-over
- elements.</para>
- </listitem>
-
- <listitem>
- <para>A bug in the new keyword arguments library (introduced in
- version 1.6.5) caused the <methodname>initialize</methodname> method
- for the <classname>FXDCWindow</classname> class to do the wrong thing
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=8441&group_id=300&atid=1223">RubyForge
- Bug #8441</ulink>). This has been corrected.</para>
- </listitem>
-
- <listitem>
- <para>A different bug in the keyword arguments library caused the
- <methodname>initialize</methodname> method for the
- <classname>FXFont</classname> class to do the wrong thing (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=8517&group_id=300&atid=1223">RubyForge
- Bug #8517</ulink>). This also has been corrected.</para>
- </listitem>
-
- <listitem>
- <para>Yet another bug in the keyword arguments library broke the part
- of the code that used to yield <constant>self</constant> to an
- optional block attached to the call to <methodname>new</methodname>
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=8518&group_id=300&atid=1223">RubyForge
- Bug #8518</ulink>). This has been corrected.</para>
- </listitem>
-
- <listitem>
- <para>Most of the FXRuby example programs have been updated to use the
- keyword arguments library.</para>
- </listitem>
-
- <listitem>
- <para>Added a new "virtual" keyword argument
- <constant>:padding</constant> that can be used in place of (or in
- addition to) the <constant>:padLeft</constant>,
- <constant>:padRight</constant>, <constant>:padTop</constant> and
- <constant>:padBottom</constant> arguments for a constructor. When a
- <constant>:padding</constant> value is passed in to the arguments
- hash, that value will be used for any of the four regular padding
- values that aren't otherwise specified. See the example programs for,
- you know, examples.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.20 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.5 (January 20, 2007)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Clicking outside of the visible cells for an
- <classname>FXTable</classname> when there was no current selection
- caused the code to raise an exception (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5907&group_id=300&atid=1223">RubyForge
- Bug #5907</ulink>). This problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>hasTimeout?</methodname> method for the
- <classname>FXApp</classname> class was implemented incorrectly (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=7564&group_id=300&atid=1223">RubyForge
- Bug #7564</ulink>). This problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXFoldingList</classname> and
- <classname>FXFoldingItem</classname> classes did not have each
- iterator methods like most of the other list-based widgets (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=7978&group_id=300&atid=1225">RubyForge
- Patch #7978</ulink>). These have been added.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for <classname>FXMDIClient</classname>
- claimed that <classname>FXScrollArea</classname> was its base class
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=7979&group_id=300&atid=1223">RubyForge
- Bug #7979</ulink>). This has been corrected; the base class for
- <classname>FXMDIClient</classname> is
- <classname>FXComposite</classname>.</para>
- </listitem>
-
- <listitem>
- <para>There was a small typo in the documentation for the
- <classname>FXFoldingList</classname> class options (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=7981&group_id=300&atid=1223">RubyForge
- Bug #7981</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Added preliminary support for keyword-style arguments, as
- described in the <ulink
- url="http://www.fxruby.org/doc/differences.html">"Differences Between
- FOX and FXRuby"</ulink> section of the <ulink
- url="http://www.fxruby.org/doc/book.html">FXRuby User's
- Guide</ulink>.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.20 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.4 (November 30, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>A change made in Ruby 1.8.5 for cyclic requires led to a problem
- that caused the Ruby interpreter to emit a large number of warnings
- (see <ulink
- url="http://rubyforge.org/tracker/?func=detail&aid=5633&group_id=300&atid=1223">RubyForge
- Bug #5633</ulink>). This problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.16 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.3 (October 27, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Widgets of some classes (namely
- <classname>FXTopWindow</classname> and
- <classname>FXMDIChild</classname>) weren't properly sending a
- <constant>SEL_CLOSE</constant> message to their message targets (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5498&group_id=300&atid=1223">RubyForge
- Bug #5498</ulink>). Thanks to a change in FOX version 1.6.16, this
- problem has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>getControlFor</methodname> method for the
- <classname>FXComboTableItem</classname> class was coded incorrectly
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5906&group_id=300&atid=1223">RubyForge
- Bug #5906</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>There was a minor typo in the API documentation for the
- <application><classname>FXTriStateButton</classname></application>
- class (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5962&group_id=300&atid=1223">RubyForge
- Bug #5962</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>each_row</methodname> and
- <methodname>each_column</methodname> iterator methods for the
- <classname>FXTable</classname> class were incorrectly coded (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=6036&group_id=300&atid=1223">RubyForge
- Bug #6036</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>new</methodname> class methods for
- <classname>FXColorItem</classname>, <classname>FXDirItem</classname>,
- <classname>FXFileItem</classname>,
- <classname>FXFoldingItem</classname>,
- <classname>FXHeaderItem</classname>,
- <classname>FXIconItem</classname>, <classname>FXListItem</classname>
- and <classname>FXTreeItem</classname> were all raising exceptions when
- a non-<constant>nil</constant> value was passed in for the last
- argument (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=6197&group_id=300&atid=1223">RubyForge
- Bug #6197</ulink>). A similar problem was present for various instance
- methods in the <classname>FXColorList</classname>,
- <classname>FXListBox</classname> and
- <classname>FXMDIClient</classname> classes. These problems have been
- fixed.</para>
- </listitem>
-
- <listitem>
- <para>A few problems were discovered for the
- <filename>inputs.rb</filename> example program (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=6209&group_id=300&atid=1223">RubyForge
- Bug #6209</ulink>). These problems have been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Several instance methods for the <classname>FXTable</classname>
- class were not actually present under their documented names (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=6211&group_id=300&atid=1223">RubyForge
- Bug #6211</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The build script was not compatible with changes made in the
- recently-released FXScintilla 1.71 (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=6313&group_id=300&atid=1223">RubyForge
- Bug #6313</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.16 and
- FXScintilla version 1.71.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.2 (September 13, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The <methodname>expandTree()</methodname> and
- <methodname>collapseTree()</methodname> methods for the
- <classname>FXFoldingList</classname> class were incorrectly identified
- as <methodname>expandFolding()</methodname> and
- <methodname>collapseFolding()</methodname> in the API documentation
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5354&group_id=300&atid=1223">RubyForge
- Bug #5354</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXDockTitle</classname> class was not supported
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5632&group_id=300&atid=1223">RubyForge
- Bug #5632</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXGLCanvas</classname>
- class claimed it had a <methodname>shared?</methodname> method, but it
- didn't (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5591&group_id=300&atid=1223">RubyForge
- Bug #5591</ulink>). Now it does.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXGradientBar</classname> class was not supported
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5746&group_id=300&atid=1223">RubyForge
- Bug #5746</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.14 and
- FXScintilla version 1.67 (from CVS).</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.7 (September 13, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The <methodname>children</methodname> instance method for the
- <classname>FXWindow</classname> class always returned an array of
- <classname>FXWindow</classname> instances, even if the actual types
- should have been instances of subclasses of
- <classname>FXWindow</classname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4342&group_id=300&atid=1223">RubyForge
- Bug #4342</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>dilbert.rb</filename> example program was broken
- due to a change in the Dilbert.com web site structure (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4597&group_id=300&atid=1223">RubyForge
- Bug #4597</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>expandTree()</methodname> and
- <methodname>collapseTree()</methodname> methods for the
- <classname>FXFoldingList</classname> class were incorrectly identified
- as <methodname>expandFolding()</methodname> and
- <methodname>collapseFolding()</methodname> in the API documentation
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5354&group_id=300&atid=1223">RubyForge
- Bug #5354</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXDockTitle</classname> class was not supported
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5632&group_id=300&atid=1223">RubyForge
- Bug #5632</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXGLCanvas</classname>
- class claimed it had a <methodname>shared?</methodname> method, but it
- didn't (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5591&group_id=300&atid=1223">RubyForge
- Bug #5591</ulink>). Now it does.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXGradientBar</classname> class was not supported
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5746&group_id=300&atid=1223">RubyForge
- Bug #5746</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.4.34 and
- FXScintilla version 1.63.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.1 (July 21, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The message data sent along for the
- <constant>SEL_INSERTED</constant>, <constant>SEL_DELETED</constant>
- and <constant>SEL_REPLACED</constant> messages from an a
- <classname>FXText</classname> widget to its target was not being
- converted properly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4666&group_id=300&atid=1223">RubyForge
- Bug #4666</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The code related to the localization of application messages in
- FOX wasn't implemented properly in FXRuby, and as a result,
- constructing certain dialogs (like the color dialog) could cause a
- program to crash (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5000&group_id=300&atid=1223">RubyForge
- Bug #5000</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The "Stop Spin" button in the gltest.rb example program didn't
- stop the cubes from spinning after either the "Spin Timer" or "Spin
- Chore" option was selected (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5001&group_id=300&atid=1223">RubyForge
- Bug #5001</ulink>). This was actually a symptom of a larger problem,
- that FXRuby wasn't properly handling timers and chores. These problems
- have been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Setting the current item for an
- <classname>FXComboBox</classname> to -1 (to indicate that there's no
- current item) would cause FXRuby to erroneously raise an
- <classname>IndexError</classname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5007&group_id=300&atid=1223">RubyForge
- Bug #5007</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The documentation for the <methodname>reparent</methodname>
- instance method for the <classname>FXWindow</classname> class was
- incorrect (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=5035&group_id=300&atid=1223">RubyForge
- Bug #5035</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>textedit.rb</filename> example program was not up
- to date with some of the changes for FOX 1.6. This example has been
- updated.</para>
- </listitem>
-
- <listitem>
- <para>The new <methodname>font</methodname> method for the
- <classname>FXFont</classname> class was not documented. This has been
- fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>dilbert.rb</filename> example program has been
- modified to use the RubyfulSoup HTML library instead of the
- html-parser library.</para>
- </listitem>
-
- <listitem>
- <para>As discussed in various forums (see for example <ulink
- url="http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/182827">this
- post</ulink>), the <methodname>autorequire</methodname> directive for
- RubyGems specifications is now deprecated. As a result, this has been
- removed from the FXRuby gem specification. This change will break any
- code that was using a statement like:<programlisting>require_gem 'fxruby'</programlisting>as
- the sole means for loading FXRuby. Such programs should instead
- use:<programlisting>require 'fox16'</programlisting>which will work
- for either gem based or non-gem based installations.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.8 and
- FXScintilla version 1.67 (from CVS).</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.6.0 (May 29, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>This is the first release of FXRuby compatible with FOX version
- 1.6. One of the most signficant changes for FOX 1.6 has been the
- addition of Unicode support; all FOX widgets and internal string
- processing routines are now Unicode aware. For a comprehensive
- overview of the changes made to FOX since version 1.4 (including those
- made in the FOX 1.5 development series), please refer to the <ulink
- url="http://www.fox-toolkit.com/news.html">News archives</ulink> at
- the FOX web site.</para>
- </listitem>
-
- <listitem>
- <para>Added the <methodname>allowSide</methodname>,
- <methodname>disallowSide</methodname> and
- <methodname>allowedSide?</methodname> methods for the
- <classname>FXDockBar</classname> class, as complements to the
- <methodname>allowedSides</methodname> accessor methods (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2307&group_id=300&atid=1226">RubyForge
- Feature Request #2307</ulink>).</para>
- </listitem>
-
- <listitem>
- <para>Added the <methodname>visible=</methodname> and
- <methodname>visible?</methodname> accessor methods for the
- <classname>FXWindow</classname> class, as complements to the
- <methodname>show</methodname>, <methodname>hide</methodname> and
- <methodname>shown?</methodname> methods (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3579&group_id=300&atid=1226">RubyForge
- Feature Request #3579</ulink>).</para>
- </listitem>
-
- <listitem>
- <para>The <filename>browser.rb</filename> example was making use of a
- deprecated API (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4325&group_id=300&atid=1223">RubyForge
- Bug #4325</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>children</methodname> instance method for the
- <classname>FXWindow</classname> class always returned an array of
- <classname>FXWindow</classname> instances, even if the actual types
- should have been instances of subclasses of
- <classname>FXWindow</classname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4342&group_id=300&atid=1223">RubyForge
- Bug #4342</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>dilbert.rb</filename> example program was broken
- due to a change in the Dilbert.com web site structure (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4597&group_id=300&atid=1223">RubyForge
- Bug #4597</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.6.5 and
- FXScintilla version 1.67 (from CVS).</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.6 (April 26, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>FXRuby would not compile properly on some x86-64 systems (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3729&group_id=300&atid=1223">RubyForge
- Bug #3729</ulink>). This error has been corrected. Thanks to Javier
- Goizueta for initially reporting this problem, and especially to
- Tobias Peters for providing a patch.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXIconDict</classname> widget was accidentally
- "lost" in the transition between FXRuby versions 1.2 and 1.4 (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4117&group_id=300&atid=1223">RubyForge
- Bug #4117</ulink>). This error has been corrected. Thanks to Manfred
- Usselmann for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXSwitcher</classname> widget was not sending the
- appropriate message data to its message target for the
- <constant>SEL_COMMAND</constant> message type (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4157&group_id=300&atid=1223">RubyForge
- Bug #4157</ulink>). This error has been corrected. Thanks to Manfred
- Usselmann for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXSeparator</classname> class wasn't implemented
- properly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4158&group_id=300&atid=1223">RubyForge
- Bug #4158</ulink>). This error has been corrected. Thanks to Gerard
- Menochet for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>findItemByData</methodname> method was
- implemented incorrectly for the <classname>FXComboBox</classname>,
- <classname>FXFoldingList</classname>,
- <classname>FXIconList</classname>, <classname>FXList</classname> and
- <classname>FXListBox</classname> classes (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4172&group_id=300&atid=1223">RubyForge
- Bug #4172</ulink>). This error has been corrected. Thanks to Gerard
- Menochet for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXListBox</classname> widget was not sending the
- appropriate message data to its message target for the
- <constant>SEL_COMMAND</constant> message type (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4255&group_id=300&atid=1223">RubyForge
- Bug #4255</ulink>). This error has been corrected. Thanks to Gerard
- Menochet for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.4.29 and
- FXScintilla version 1.63.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.5 (April 10, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The <classname>FXTextField</classname> class was not properly
- responding to the <constant>ID_INSERT_STRING</constant> command (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3320&group_id=300&atid=1223">RubyForge
- Bug #3320</ulink>). This error has been corrected. Thanks to Uwe Hartl
- for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>text</methodname> and
- <methodname>getText</methodname> methods for the
- <classname>FXMenuCaption</classname> class were returning
- <constant>nil</constant> instead of the actual value (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3458&group_id=300&atid=1223">RubyForge
- Bug #3458</ulink>). This error has been corrected. Thanks to Meinrad
- Recheis (Henon) for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXMDIChild</classname>
- class erroneously listed <constant>SEL_CLOSEALL</constant> as one of
- the message types that an MDI child window might send to its message
- target (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3508&group_id=300&atid=1223">RubyForge
- Bug #3508</ulink>). This error has been corrected. Thanks to Meinrad
- Recheis (Henon) for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Calling the <methodname>selectRange</methodname> method for
- class <classname>FXTable</classname> would cause a fatal error instead
- of merely raising an <classname>IndexError</classname> exception (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3615&group_id=300&atid=1223">RubyForge
- Bug #3615</ulink>). This error has been corrected. Thanks to Meinrad
- Recheis (Henon) for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Due to an error in the SWIG interface files, the
- <classname>FXChoiceBox</classname> class was basically unusable (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3676&group_id=300&atid=1223">RubyForge
- Bug #3676</ulink>). This error has been corrected. Thanks to Uwe Hartl
- for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the
- <classname>FXRealSlider</classname> and
- <classname>FXRealSpinner</classname> classes erroneously claimed that
- the message data for the <constant>SEL_COMMAND</constant> and
- <constant>SEL_CHANGED</constant> messages sent by these widgets to
- their targets were integers (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3749&group_id=300&atid=1223">RubyForge
- Bug #3749</ulink>). Along the same lines, the message data for those
- widgets wasn't being converted correctly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3750&group_id=300&atid=1223">RubyForge
- Bug #3750</ulink>). Both of these errors have been corrected. Thanks
- to Meinrad Recheis (Henon) for reporting these problems.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the Fox module incorrectly listed the
- names of the <methodname>FXSELTYPE</methodname> and
- <methodname>FXSELID</methodname> methods as
- <methodname>SELTYPE</methodname> and <methodname>SELID</methodname>
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3940&group_id=300&atid=1223">RubyForge
- Bug #3940</ulink>). This error has been corrected. Thanks to Joel
- VanderWerf for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <classname>FXTableItem</classname> constructor was supposed
- to (optionally) accept a reference to an arbitrary Ruby object as its
- third argument, but this wasn't working properly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=4005&group_id=300&atid=1223">RubyForge
- Bug #4005</ulink>). This error has been corrected. Thanks to Mark
- Volkman for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.4.29 and
- FXScintilla version 1.63.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.4 (January 21, 2006)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The build instructions for Unix platforms had not been updated
- recently and as such contained some errors (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3014&group_id=300&atid=1223">RubyForge
- Bug #3014</ulink>). These errors have been corrected. Thanks to Dave
- Burns for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>extendSelection</methodname> method for the
- <classname>FXTable</classname> class was raising an exception if an
- out of bounds row or column index was passed in (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3050&group_id=300&atid=1223">RubyForge
- Bug #3050</ulink>). This has been changed so that
- <methodname>extendSelection</methodname> instead returns false for out
- of bounds arguments. Thanks to Leonid Moiseichuk for reporting this
- problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>each_child</methodname> iterator method for the
- <classname>FXWindow</classname> class would fail if the child window
- was destroyed in the block (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3134&group_id=300&atid=1223">RubyForge
- Bug #3134</ulink>). Thanks to Liam Irish for reporting this problem
- and providing a patch.</para>
- </listitem>
-
- <listitem>
- <para>The message data for the <constant>SEL_REPLACED</constant>
- message sent by the <classname>FXTable</classname> class to its target
- was not being handled properly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=3244&group_id=300&atid=1223">RubyForge
- Bug #3244</ulink>). There were also problems with the message data for
- the <constant>SEL_SELECTED</constant> and
- <constant>SEL_DESELECTED</constant> messages. Furthermore, the
- <constant>SEL_REPLACED</constant> message was not documented in the
- RDoc documentation for the <classname>FXTable</classname> class. All
- of these problems have been corrected. Thanks to _blackdog for
- reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.4.29 and
- FXScintilla version 1.63.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.3 (November 7, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The <constant>TOGGLEBUTTON_KEEPSTATE</constant> option for the
- <classname>FXToggleButton</classname> class was not documented (see
- <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2286&group_id=300&atid=1223">RubyForge
- Bug #2286</ulink>). This oversight has been corrected. Thanks to Tim
- Smith for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>scintilla.rb</filename> library file was not up to
- date with the latest FXScintilla release, and as a result it was
- missing some methods (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2479&group_id=300&atid=1223">RubyForge
- Bug #2479</ulink>). This oversight has been corrected. Thanks to Maxim
- Kulkin for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Due to changes in the APIs for timers and chores, the mechanisms
- for removing chores and timeouts were broken (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2563&group_id=300&atid=1223">RubyForge
- Bug #2563</ulink>). This bug has been fixed. Thanks to "moinker" for
- reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>An error in the test setup caused all of the tests for the
- <classname>FXList</classname> class to fail (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2564&group_id=300&atid=1223">RubyForge
- Bug #2564</ulink>). This bug has been fixed. Thanks to Peter for
- reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Due to a bug in the test suite runner script, not all test cases
- were being exercised (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2565&group_id=300&atid=1223">RubyForge
- Bug #2565</ulink>). This bug has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>Calling the <methodname>getPixel</methodname> method for the
- <classname>FXImage</classname> class when the client-side pixel buffer
- for the image has already been released would cause a program to crash
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2611&group_id=300&atid=1223">RubyForge
- Bug #2611</ulink>). Now, <methodname>getPixel</methodname> will raise
- an exception if it's called after the pixel buffer has been released.
- The documentation for <methodname>getPixel</methodname> has been
- updated accordingly. Thanks to Gonzalo Garramuno for reporting this
- problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>makePositionVisible</methodname> method for the
- <classname>FXTable</classname> class was raising an exception when
- passed out-of-bounds values for the row or column index (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2660&group_id=300&atid=1223">RubyForge
- Bug #2660</ulink>). This could happen, for example, if you were to
- click in a table area outside of the regular cells (which indirectly
- triggers a call to <methodname>makePositionVisible</methodname>). This
- was actually inconsistent with standard FOX behavior, which simply
- ignores out of bounds values for that method's arguments. This bug has
- been fixed, and the documentation for
- <methodname>makePositionVisible</methodname> has been updated
- accordingly. Thanks to Ralf Jonas for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.4.21 and
- FXScintilla version 1.63.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.2 (August 22, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Due to a bug in the implementation, the
- <methodname>checked?</methodname> method for the
- <classname>FXCheckButton</classname> class always returned
- <constant>false</constant> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1852&group_id=300&atid=1223">RubyForge
- Bug #1852</ulink>). This bug has been fixed. Thanks to Meinrad Recheis
- for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXTable</classname>
- class listed several obsolete attributes (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1928&group_id=300&atid=1223">RubyForge
- Bug #1928</ulink>). Those errors have been corrected. Thanks to Pavel
- Sokolov for reporting these problems.</para>
- </listitem>
-
- <listitem>
- <para>There were a number of bugs in the
- <filename>textedit.rb</filename> example program (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1979&group_id=300&atid=1223">RubyForge
- Bug #1979</ulink>), and those bugs have been fixed. Thanks to Claude
- Marinier for reporting these problems.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXTreeList</classname>
- class' <methodname>new</methodname> method still showed the number of
- visible items (<parameter>nvis</parameter>) as its second argument
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2171&group_id=300&atid=1223">RubyForge
- Bug #2171</ulink>). This problem has been corrected. Thanks to Bill
- Atkins for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXTopWindow</classname>
- class had a number of errors (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2269&group_id=300&atid=1223">RubyForge
- Bug #2269</ulink>). This problem has been corrected.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXTreeList</classname>
- class still listed the obsolete <methodname>reparentItem</methodname>
- method (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2270&group_id=300&atid=1223">RubyForge
- Bug #2270</ulink>). This problem has been corrected. Thanks to Jacob
- Hansen for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Due to a bug in how the SWIG typemaps for the
- <type>FXlong</type> type were defined, some methods for the
- <classname>FXFileStream</classname> class were broken (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=2275&group_id=300&atid=1223">RubyForge
- Bug #2275</ulink>). This problem has been corrected. Thanks to Gonzalo
- Garramuno for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Merged in all of the fixes for FXRuby 1.2.6.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.4.17 and
- FXScintilla version 1.63.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.1 (August 20, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>This is the second release of FXRuby which is compatible with
- FOX 1.4, and as such should be considered an "unstable" release. For a
- history of the changes made during the FOX 1.3 and 1.4 development,
- see the <ulink url="http://www.fox-toolkit.com/news.html">News</ulink>
- page at the FOX Web site.</para>
- </listitem>
-
- <listitem>
- <para>The unit tests (in the <filename>tests</filename> subdirectory)
- had not been updated to require the <constant>fox14</constant>
- feature, and were still looking at <constant>fox12</constant>. This
- has been corrected.</para>
- </listitem>
-
- <listitem>
- <para>A number of minor problems were corrected for the Windows build
- of FXRuby.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.4.17 and
- FXScintilla version 1.63.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.4.0 (August 19, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>This is the first release of FXRuby which is compatible with FOX
- 1.4, and as such should be considered an "unstable" release. For a
- history of the changes made during the FOX 1.3 and 1.4 development,
- see the <ulink url="http://www.fox-toolkit.com/news.html">News</ulink>
- page at the FOX Web site.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.2.6 (April 15, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Some additional problems related to calling the
- <methodname>setTableSize</methodname> method for an
- <classname>FXTable</classname> were discovered (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1597&group_id=300&atid=1223">RubyForge
- Bug #1597</ulink>). This problem has been corrected. Thanks to Joel
- VanderWerf for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>iconlist.rb</filename> example program had a
- "Sort" pulldown menu filled with a number of commands that didn't
- really do anything, including sorting the items (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1654&group_id=300&atid=1223">RubyForge
- Bug #1654</ulink>). This pulldown menu has been removed from that
- example.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXDC</classname> class
- erroneously referred to the <methodname>font</methodname> attribute as
- <methodname>textFont</methodname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1667&group_id=300&atid=1223">RubyForge
- Bug #1667</ulink>). This problem has been corrected. Thanks to Meinrad
- Recheis for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>checked?</methodname>,
- <methodname>unchecked?</methodname> and
- <methodname>maybe?</methodname> methods for the
- <classname>FXMenuCheck</classname> class were missing (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1677&group_id=300&atid=1223">RubyForge
- Bug #1677</ulink>). This problem has been corrected. Thanks to Oliver
- Smith for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the
- <classname>FXScrollArea</classname> class incorrectly spelled the
- names of the <methodname>horizontalScrollBar</methodname> and
- <methodname>verticalScrollBar</methodname> methods as
- <methodname>horizontalScrollbar</methodname> and
- <methodname>verticalScrollbar</methodname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1678&group_id=300&atid=1223">RubyForge
- Bug #1678</ulink>). The documentation has been corrected. Thanks to
- Jannis Pohlmann for reporting this mistake.</para>
- </listitem>
-
- <listitem>
- <para>Some code in the <filename>groupbox.rb</filename> example
- program was calling the <methodname>getRootWindow</methodname> method,
- but that method has been renamed to <methodname>getRoot</methodname>
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1692&group_id=300&atid=1223">RubyForge
- Bug #1692</ulink>). This problem has been corrected. Thanks to
- Jaroslav Stika for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>hasChar?</methodname> method for the
- <classname>FXFont</classname> class was spelled without a trailing
- question mark, but it seems more Ruby-like that it should, so we've
- added an alias for that (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1714&group_id=300&atid=1223">RubyForge
- Bug #1714</ulink>). This method also now accepts a string of size 1
- (i.e. a single character) as its input, as an alternative to an
- ordinal value. Thanks to Meinrad Recheis for these suggestions.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the <classname>FXImage</classname>
- class mistakenly listed <constant>IMAGE_ALPHA</constant> as a valid
- image rendering hint, but this flag is no longer needed since FOX
- images now always contain an alpha channel (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1715&group_id=300&atid=1223">RubyForge
- Bug #1715</ulink>). The documentation has been corrected. Thanks to
- Meinrad Recheis for reporting this mistake.</para>
- </listitem>
-
- <listitem>
- <para>Due to an error in the SWIG interface files, the
- <methodname>data</methodname> method for the
- <classname>FXSettings</classname> class was not being wrapped
- properly. As a result, this method was unavailable and in turn led to
- other dependent methods (like <methodname>each_section</methodname>)
- to be unavailable as well (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1771&group_id=300&atid=1223">RubyForge
- Bug #1771</ulink>). This error has been corrected. Thanks to Jannis
- Pohlmann for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.2.16 and
- FXScintilla version 1.62.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.2.5 (March 1, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The change made for FXRuby version 1.2.4 regarding garbage
- collection for table items corrected only one of the problems
- described in <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1445&group_id=300&atid=1223">RubyForge
- Bug #1445</ulink>; There was still a problem related to the
- "destructive" effects of the <methodname>setTableSize</methodname>
- method for the <classname>FXTable</classname> class. This problem has
- now been corrected as well. Thanks to David Peoples, Jamey Cribbs and
- Joel VanderWerf for their assistance in helping me to track down this
- problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>extractText</methodname> and
- <methodname>overlayText</methodname> methods for the
- <classname>FXTable</classname> class were implemented incorrectly and
- weren't listed in the API documentation. These problems have been
- corrected.</para>
- </listitem>
-
- <listitem>
- <para>The checks for out-of-bounds indices in the
- <methodname>getColumnX</methodname>,
- <methodname>setColumnX</methodname>, <methodname>getRowY</methodname>,
- <methodname>setRowY</methodname> and
- <methodname>updateRange</methodname> methods for the
- <classname>FXTable</classname> class were incorrect. These have been
- fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>setTableSize</methodname> method for the
- <classname>FXTable</classname> class now raises
- <classname>ArgError</classname> if either the number of rows or
- columns passed in as arguments is less than zero.</para>
- </listitem>
-
- <listitem>
- <para>A typo in one of the source files was causing the build to fail
- when compiled against Ruby versions 1.8.1 or earlier (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1551&group_id=300&atid=1223">RubyForge
- Bug #1551</ulink>). This error has been corrected. Thanks to Alex
- McGuire for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>selectItem</methodname> method for the
- <classname>FXTable</classname> class was removed in FOX 1.2, so we've
- added a convenience method for this that just calls the
- <methodname>selectRange</methodname> method under the hood (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1562&group_id=300&atid=1223">RubyForge
- Bug #1562</ulink>). Thanks to Joel VanderWerf for this
- suggestion.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.2.13 and
- FXScintilla version 1.62.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.2.4 (February 23, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Due to a change in some of the internal Ruby C APIs, a
- compile-time error for FXRuby was introduced in some of the Ruby 1.8.2
- preview releases (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1039&group_id=300&atid=1223">RubyForge
- Bug #1039</ulink>). One should not see any compile-time errors when
- compiling FXRuby (versions 1.2.3 or later) against the Ruby 1.8.2
- final release, but I've neverthless made a change to how those
- internal APIs are used, to avoid any potential problems. Thanks to the
- many users who pointed out this problem.</para>
- </listitem>
-
- <listitem>
- <para>Joel VanderWerf suggested some enhancements to the
- <filename>image.rb</filename> example program in order to improve its
- startup time (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1281&group_id=300&atid=1223">RubyForge
- Bug #1281</ulink>). Those changes have been incorporated. Thanks to
- Joel for this suggestion.</para>
- </listitem>
-
- <listitem>
- <para>One change for the <classname>FXImage</classname> class between
- FOX versions 1.0 and 1.2 is the nature of the pixel buffer that's
- passed to the <classname>FXImage</classname> constructor. Previously,
- this pixel buffer was expected to be a string of bytes; now it's
- expected to be an array of <type>FXColor</type> values. This
- modification was not implemented correctly for FXRuby versions 1.2.3
- and earlier (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1427&group_id=300&atid=1223">RubyForge
- Bug #1427</ulink>). This bug has been corrected, and the example
- program (<filename>image.rb</filename>) and test cases have been
- updated as well. Thanks to Oliver Smith and others for reporting this
- problem.</para>
- </listitem>
-
- <listitem>
- <para>A couple of different problems, reported by Patrick Fernie and
- David Peoples, exposed a flaw in how FXRuby manages the links between
- FOX objects and their Ruby peers when the FOX objects are destroyed
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1445&group_id=300&atid=1223">RubyForge
- Bug #1445</ulink>). Without going into all the gory details, let's
- just say that since we have no explicit control over when Ruby's
- garbage collector decides to "collect" those Ruby peers that point to
- C++ objects that have been destroyed, we need to take steps to
- neutralize those Ruby peer objects so that they can't cause your
- application to crash in the meantime; I've implemented a fix to take
- care of this situation. Thanks to Patrick and David for reporting
- these problems.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for FXRuby 1.2 still contained references
- to the old "spellings" of the <methodname>fxparseAccel</methodname>
- and <methodname>fxparseHotKey</methodname> method names, which were
- all lowercase (i.e. <methodname>fxparseaccel</methodname> and
- <methodname>fxparsehotkey</methodname>). (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1470&group_id=300&atid=1223">RubyForge
- Bug #1470</ulink>). These errors have been corrected.</para>
- </listitem>
-
- <listitem>
- <para>Added the <methodname>FXScrollArea#scrollCorner</methodname>
- method, which returns a reference to the scroll corner for any window
- derived from <classname>FXScrollArea</classname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=843&group_id=300&atid=1226">RubyForge
- Feature Request #1226</ulink>). Thanks to Brian Sheehan for this
- suggestion.</para>
- </listitem>
-
- <listitem>
- <para>Added the <methodname>FXMemoryBuffer#to_a</methodname> method,
- which is just an alias for the <methodname>data</methodname> accessor
- method that returns a copy of the data buffer as an array (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1295&group_id=300&atid=1226">RubyForge
- Feature Request #1295</ulink>). Thanks to Meinrad Recheis for this
- suggestion.</para>
- </listitem>
-
- <listitem>
- <para>Added the <methodname>appendRows</methodname> and
- <methodname>appendColumns</methodname> methods to the
- <classname>FXTable</classname> class (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1426&group_id=300&atid=1226">RubyForge
- Feature Request #1295</ulink>). Thanks to Brett Hallett for this
- suggestion.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.2.13 and
- FXScintilla version 1.62.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.2.3 (January 22, 2005)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>Since group boxes containing radio buttons no longer enforce the
- radio behavior of radio buttons (i.e. keeping only one radio button
- selected at a time), some of the example programs were no longer
- working as desired (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=751&group_id=300&atid=1223">RubyForge
- Bug #751</ulink> and <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1280&group_id=300&atid=1223">RubyForge
- Bug #1280</ulink>). This problem has been corrected. Thanks to Yuri
- Leikind and Barry DeZonia for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Bob Sidebotham reported a little typo in the
- <filename>table.rb</filename> example program (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=990&group_id=300&atid=1223">RubyForge
- Bug #990</ulink>). This has been corrected.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for <classname>FXList</classname> did not
- reflect the changes for FOX 1.2; the
- <methodname>retrieveItem()</methodname> has been renamed to
- <methodname>getItem()</methodname> and
- <methodname>insertItem()</methodname> has been renamed to
- <methodname>setItem()</methodname> (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1037&group_id=300&atid=1223">RubyForge
- Bug #1037</ulink> and <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1257&group_id=300&atid=1223">RubyForge
- Bug #1257</ulink>). This has been corrected. Thanks to Remy Drouilhet
- and Stephan Kamper for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The Windows installer was missing some of the documentation
- files (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1139&group_id=300&atid=1223">RubyForge
- Bug #1139</ulink>). This has been corrected. Thanks to Curt Hibbs and
- Mark Smith for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>browser.rb</filename> example program was broken
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1146&group_id=300&atid=1223">RubyForge
- Bug #1146</ulink>). This has been corrected. Thanks to Stefan Lang for
- reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The attribute setter for
- <methodname>FXHeaderItem#justification</methodname> was defined
- incorrectly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1276&group_id=300&atid=1223">RubyForge
- Bug #1276</ulink>). This has been corrected. Thanks to Joel VanderWerf
- for reporting this problem (and providing a patch to fix it).</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>filenames</methodname> alias for the
- <methodname>FXFileDialog#getFilenames()</methodname> instance method
- was missing (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1277&group_id=300&atid=1223">RubyForge
- Bug #1277</ulink>). This error has been corrected. Thanks to Barry
- DeZonia for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the
- <classname>FXFileDialog</classname> class methods
- <methodname>getOpenFilenames()</methodname>,
- <methodname>getOpenDirectory()</methodname>,
- <methodname>getOpenFilename()</methodname> and
- <methodname>getSaveFilename()</methodname> was extremely inadequate
- (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1279&group_id=300&atid=1223">RubyForge
- Bug #1279</ulink>). This documentation has been improved. Thanks to
- Barry DeZonia for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Brett Hallett contributed a Ruby port of the "ratio" example
- program from the regular FOX distribution, for demonstrating the use
- of the new <classname>FXSpring</classname> layout manager (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1282&group_id=300&atid=1223">RubyForge
- Bug #1282</ulink>). Many thanks to Brett for this addition!</para>
- </listitem>
-
- <listitem>
- <para>Joel VanderWerf contributed code to simplify how programs
- interact with modal and non-modal dialog boxes (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1283&group_id=300&atid=1223">RubyForge
- Bug #1283</ulink>). See the API documentation for the new
- <methodname>FXDialogBox#execute_modal</methodname> and
- <methodname>FXDialogBox#execute_nonmodal</methodname> methods for
- examples of their use.</para>
- </listitem>
-
- <listitem>
- <para>The attribute setters for
- <methodname>FXRealSpinner#selBackColor</methodname> and
- <methodname>FXSpinner#selBackColor</methodname> were defined
- incorrectly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1297&group_id=300&atid=1223">RubyForge
- Bug #1297</ulink>). These have been corrected. Thanks to Meinrad
- Recheis for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>tooltipPause</methodname> attribute reader for
- the <classname>FXApp</classname> class was missing (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1306&group_id=300&atid=1225">RubyForge
- Patch #1306</ulink>). Thanks to Joel VanderWerf for reporting this
- omission and providing a patch to fix it.</para>
- </listitem>
-
- <listitem>
- <para>The API documentation for the
- <classname>FXToolBarTab</classname> class was missing (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1322&group_id=300&atid=1223">RubyForge
- Bug #1322</ulink>). Thanks to Joel VanderWerf for reporting this
- omission.</para>
- </listitem>
-
- <listitem>
- <para>The attribute accessors for
- <methodname>FXText#visibleRows</methodname> and
- <methodname>FXText#visibleColumns</methodname> were defined and
- documented incorrectly (see <ulink
- url="http://rubyforge.org/tracker/index.php?func=detail&aid=1325&group_id=300&atid=1223">RubyForge
- Bug #1325</ulink>). These have been corrected. Thanks to Karl El-Koura
- for reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.2.13 and
- FXScintilla version 1.62.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.2.2 (October 1, 2004)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>In order to avoid versioning problems when dealing with a mix of
- applications based on either FXRuby 1.0 or 1.2, the feature name for
- FXRuby has been changed from "fox" to "fox12". For most application
- developers, this means that you will need to modify the source code
- for applications targeted at FXRuby 1.2 to begin with the line</para>
-
- <para><programlisting>require 'fox12'</programlisting>Note that no
- changes should be required for legacy applications targeted at FXRuby
- 1.0.</para>
- </listitem>
-
- <listitem>
- <para>Made a number of updates to the documentation, to reflect API
- changes for FXRuby 1.2.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.2.9 and
- FXScintilla version 1.61.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.2a2 (July 10, 2004)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>This is the second "alpha" release of FXRuby 1.2. This release
- should be compatible with any FOX library version 1.2; it is not
- compatible with any previous FOX library versions. As this is an alpha
- release, users should expect a certain amount of instability, bugs,
- etc.</para>
- </listitem>
-
- <listitem>
- <para>For this release, all of the FOX 1.2 classes are available with
- the exception of the <classname>FXBitmapView</classname> class. There
- is a small problem with how the <classname>FXBitmapView</classname>
- class is declared in the FOX 1.2 header files, and I'm trying to
- decide how best to resolve that problem. The goal is to have this
- problem resolved by the next alpha release of FXRuby.</para>
- </listitem>
-
- <listitem>
- <para>For this release, all of the RDoc-based online documentation has
- been brought up to date with the new APIs.</para>
- </listitem>
-
- <listitem>
- <para>Portions of the FXRuby User's Guide were still out of date with
- respect to the new APIs (see <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=988623&group_id=20243&atid=120243">SourceForge
- Bug #988623</ulink>). This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>mditest.rb</filename> example program was not up
- to date with the new APIs. This has been fixed.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>glviewer.rb</filename> example program was not up
- to date with the new APIs (see <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=986479&group_id=20243&atid=120243">SourceForge
- Bug #986479</ulink>). This has been fixed. Thanks to Remy Drouilhet
- for reporting this problem and suggesting the fixes.</para>
- </listitem>
-
- <listitem>
- <para>The <methodname>FXGLGroup#bounds</methodname> method was defined
- incorrectly (see <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=986476&group_id=20243&atid=120243">SourceForge
- Bug #986476</ulink>). This has been fixed. Thanks to Remy Drouilhet
- for reporting this problem and suggesting the fix.</para>
- </listitem>
-
- <listitem>
- <para>The <filename>scintilla-test.rb</filename> example program was
- not up to date with the new APIs (see <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=986172&group_id=20243&atid=120243">SourceForge
- Bug #986172</ulink>). This has been fixed. Thanks to Peter Watkins for
- reporting this problem and submitting a corrected version of the
- program.</para>
- </listitem>
-
- <listitem>
- <para>There was a small typo in the table.rb example program (see
- <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=988152&group_id=20243&atid=120243">SourceForge
- Bug #988152</ulink>). This has been fixed. Thanks to Jamey Cribbs for
- reporting this problem and suggesting the fix.</para>
- </listitem>
-
- <listitem>
- <para>Due to an oversight on my part, one of the overloaded
- constructors for the <classname>FXRegion</classname> class wasn't
- wrapped properly (see <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=986181&group_id=20243&atid=120243">SourceForge
- Bug #986181</ulink>). This has been fixed. Thanks to Bil Bas for
- reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>Removed some obsolete aliases for the old leading and trailing
- rows and columns for the <classname>FXTable</classname> class (see
- <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=986181&group_id=20243&atid=120243">SourceForge
- Bug #988038</ulink>). Thanks to Yuri Leikind for reporting this
- problem.</para>
- </listitem>
-
- <listitem>
- <para>Added <classname>FXTable</classname> instance methods
- <methodname>horizontalGridShown=()</methodname> and
- <methodname>verticalGridShown=()</methodname> to complement the
- already available <methodname>horizontalGridShown?</methodname> and
- <methodname>verticalGridShown?</methodname> methods.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for the 1.2a1 release on Windows didn't have PNG
- or JPEG image support built-in (see <ulink
- url="http://sourceforge.net/tracker/index.php?func=detail&aid=986180&group_id=20243&atid=120243">SourceForge
- Bug #986180</ulink>). This has been fixed. Thanks to Bil Bas for
- reporting this problem.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.2.7 and
- FXScintilla version 1.61.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Changes For Version 1.2a1 (June 28, 2004)</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>This is the first "alpha" release of FXRuby 1.2. This release
- should be compatible with any FOX library version 1.2; it is not
- compatible with any previous FOX library versions. As this is an alpha
- release, users should expect a certain amount of instability, bugs,
- etc.</para>
-
- <para>The intent of this first alpha release is twofold. The primary
- intent is allow application developers who have current projects based
- on FXRuby 1.0 to begin the process of updating their applications for
- compatibility with FXRuby 1.2. For this release, all of the classes
- that existed in FXRuby 1.0 have been updated for compatibility with
- FOX 1.2, and so developers should at least be able to begin to "port"
- their applications forward now. Note that there have been a number of
- changes for FOX 1.2 and FXRuby 1.2, both in terms of API changes and
- less obvious "behavioral" changes. For a detailed summary of these
- changes, please see <ulink
- url="http://www.knology.net/~lyle/fox/1.2/WhatsNew.html">"What's New
- in FOX 1.2"</ulink> (also available as a <ulink
- url="http://www.knology.net/~lyle/fox/1.2/WhatsNew.pdf">PDF</ulink>).
- Note that few, if any, of the new classes introduced in FOX 1.2 are
- available in this first alpha release of FXRuby 1.2. Support for those
- new classes should come along quickly in subsequent alpha releases of
- FXRuby 1.2.</para>
-
- <para>The secondary intent of this first alpha release is to introduce
- the new <ulink
- url="http://rubygems.rubyforge.org">RubyGems</ulink>-based packaging
- of FXRuby and to begin to work out the inevitable kinks in that
- system.</para>
- </listitem>
-
- <listitem>
- <para>The binary gem for Windows was built with FOX version 1.2.4 and
- FXScintilla version 1.57.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-</chapter>
diff --git a/users_guide/clipboardtut.xml b/users_guide/clipboardtut.xml
deleted file mode 100755
index 92836a0f5ff3dcc5e1306e43213e1563f8486c2a..0000000000000000000000000000000000000000
--- a/users_guide/clipboardtut.xml
+++ /dev/null
@@ -1,321 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="clipboardtut">
- <title>Working With the Clipboard</title>
-
- <para>Two of the standard FOX widgets, <classname>FXText</classname> and
- <classname>FXTextField</classname>, provide clipboard support out of the
- box. For example, you can select some text in an
- <classname>FXTextField</classname> and then press Ctrl+C to copy that text
- to the system clipboard. You can also press Ctrl+X to "cut" the selected
- text to the clipboard, or Ctrl+V to paste text from the clipboard into an
- <classname>FXText</classname> or <classname>FXTextField</classname> widget.
- The purpose of this tutorial is to demonstrate how to interact with the
- clipboard programmatically, so that you can integrate additional clipboard
- support into your FXRuby applications.</para>
-
- <section>
- <title>Basic Application</title>
-
- <para>In order to illustrate how to integrate cut and paste operations
- into your application, we'll start from a simple FXRuby application that
- doesn't yet provide any clipboard support. This application simply
- presents a list of customers (from some external source).</para>
-
- <programlisting format="linespecific">require 'fox16'
-require 'customer'
-
-include Fox
-
-class ClipMainWindow < FXMainWindow
- def initialize(anApp)
- # Initialize base class first
- super(anApp, "Clipboard Example", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Place the list in a sunken frame
- sunkenFrame = FXVerticalFrame.new(self,
- LAYOUT_FILL_X|LAYOUT_FILL_Y|FRAME_SUNKEN|FRAME_THICK, :padding => 0)
-
- # Customer list
- customerList = FXList.new(sunkenFrame, :opts => LIST_BROWSESELECT|LAYOUT_FILL_X|LAYOUT_FILL_Y)
- $customers.each do |customer|
- customerList.appendItem(customer.name, nil, customer)
- end
- end
-
- def create
- super
- show(PLACEMENT_SCREEN)
- end
-end
-
-if __FILE__ == $0
- FXApp.new("ClipboardExample", "FXRuby") do |theApp|
- ClipMainWindow.new(theApp)
- theApp.create
- theApp.run
- end
-end
-</programlisting>
-
- <para>We're assuming that the "customer" module defines a
- <classname>Customer</classname> class and a global array
- <varname>$customers</varname> that contains the list of customers. For a
- real world application, you might access this information from a database
- or some other source, but for this example we'll just use a hard-coded
- array:</para>
-
- <programlisting format="linespecific"># customer.rb
-
-Customer = Struct.new("Customer", :name, :address, :zip)
-
-$customers = []
-$customers << Customer.new("Reed Richards", "123 Maple, Central City, NY", 010111)
-$customers << Customer.new("Sue Storm", "123 Maple, Anytown, NC", 12345)
-$customers << Customer.new("Benjamin J. Grimm", "123 Maple, Anytown, NC", 12345)
-$customers << Customer.new("Johnny Storm", "123 Maple, Anytown, NC", 12345)
-</programlisting>
-
- <para>The goals for the next few sections are to extend this application
- so that users can select a customer from the list and copy that customer's
- information to the clipboard, and subsequently paste that information into
- another copy of the program (or some other clipboard-aware
- application).</para>
- </section>
-
- <section>
- <title>Acquiring the Clipboard</title>
-
- <para>Let's begin by augmenting the GUI to include a row of buttons along
- the bottom of the main window for copying and pasting:</para>
-
- <programlisting format="linespecific">require 'fox16'
-require 'customer'
-
-include Fox
-
-class ClipMainWindow < FXMainWindow
- def initialize(anApp)
- # Initialize base class first
- super(anApp, "Clipboard Example", :opts => DECOR_ALL, :width => 400, :height => 300)
-<emphasis role="bold">
- # Horizontal frame contains buttons
- buttons = FXHorizontalFrame.new(self, LAYOUT_SIDE_BOTTOM|LAYOUT_FILL_X|PACK_UNIFORM_WIDTH)
-</emphasis><emphasis role="bold">
- # Cut and paste buttons
- copyButton = FXButton.new(buttons, "Copy")
- pasteButton = FXButton.new(buttons, "Paste")
-</emphasis>
- # Place the list in a sunken frame
- sunkenFrame = FXVerticalFrame.new(self,
- LAYOUT_FILL_X|LAYOUT_FILL_Y|FRAME_SUNKEN|FRAME_THICK, :padding => 0)
-
- # Customer list
- customerList = FXList.new(sunkenFrame, :opts => LIST_BROWSESELECT|LAYOUT_FILL_X|LAYOUT_FILL_Y)
- $customers.each do |customer|
- customerList.appendItem(customer.name, nil, customer)
- end
- end
-
- def create
- super
- show(PLACEMENT_SCREEN)
- end
-end
-
-if __FILE__ == $0
- FXApp.new("ClipboardExample", "FXRuby") do |theApp|
- ClipMainWindow.new(theApp)
- theApp.create
- theApp.run
- end
-end
-</programlisting>
-
- <para>Note that the lines which appear in bold face are those which have
- been added (or changed) since the previous source code listing.</para>
-
- <para>The clipboard is a kind of shared resource in the operating system.
- Copying (or cutting) data to the clipboard begins with some window in your
- application requesting "ownership" of the clipboard by calling the
- <methodname>acquireClipboard()</methodname> instance method. Let's add a
- handler for the "Copy" button press which does just that:</para>
-
- <programlisting format="linespecific"># User clicks Copy
-copyButton.connect(SEL_COMMAND) do
- customer = customerList.getItemData(customerList.currentItem)
- types = [ FXWindow.stringType ]
- if acquireClipboard(types)
- @clippedCustomer = customer
- end
-end
-</programlisting>
-
- <para>The <methodname>acquireClipboard()</methodname> method takes as its
- input an array of drag types. A <emphasis>drag type</emphasis> is just a
- unique value, assigned by the window system, that identifies a particular
- kind of data. In this case, we're using one of FOX's pre-registered drag
- types (<constant>stringType</constant>) to indicate that we have some
- string data to place on the clipboard. Later, we'll see how to register
- customized, application-specific drag types as well.</para>
-
- <para>The <methodname>acquireClipboard()</methodname> method returns
- <constant>true</constant> on success; since we called
- <methodname>acquireClipboard()</methodname> on the main window, this means
- that the main window is now the clipboard owner. At this time, we want to
- save a reference to the currently selected customer in the
- <varname>@clippedCustomer</varname> instance variable so that if its value
- is requested later, we'll be able to return the
- <emphasis>correct</emphasis> customer's information.</para>
- </section>
-
- <section>
- <title>Sending Data to the Clipboard</title>
-
- <para>Whenever some other window requests the clipboard's contents (e.g.
- as a result of a "paste" operation) FOX will send a
- <constant>SEL_CLIPBOARD_REQUEST</constant> message to the current
- clipboard owner. Remember, the clipboard owner is the window that called
- <methodname>acquireClipboard()</methodname>. For our example, the main
- window is acting as the clipboard owner and so it needs to handle the
- <constant>SEL_CLIPBOARD_REQUEST</constant> message:</para>
-
- <programlisting format="linespecific"># Handle clipboard request
-self.connect(SEL_CLIPBOARD_REQUEST) do
- setDNDData(FROM_CLIPBOARD, FXWindow.stringType, Fox.fxencodeStringData(@clippedCustomer.to_s))
-end
-</programlisting>
-
- <para>The <methodname>setDNDData()</methodname> method takes three
- arguments. The first argument tells FOX which kind of data transfer we're
- trying to accomplish; as it turns out, this method can be used for
- drag-and-drop (<constant>FROM_DRAGNDROP</constant>) and X11 selection
- (<constant>FROM_SELECTION</constant>) data transfer as well. The second
- argument to <methodname>setDNDData()</methodname> is the drag type for the
- data and the last argument is the data itself, a binary string.</para>
-
- <para>If you're wondering why we need to call the
- <methodname>fxencodeStringData()</methodname> module method to preprocess
- the string returned by the call to <methodname>Customer#to_s</methodname>,
- that's a reasonable thing to wonder about. In order for FOX to play nice
- with other clipboard-aware applications, it must be able to store string
- data on the clipboard in the format expected by those applications.
- Unfortunately, that expected format is platform-dependent and does not
- always correspond directly to the format that Ruby uses internally to
- store its string data. The <methodname>fxencodeStringData()</methodname>
- method (and the corresponding
- <methodname>fxdecodeStringData()</methodname> method) provide you with a
- platform-independent way of sending (or receiving) string data with the
- <constant>stringType</constant> drag type.</para>
-
- <para>If you run the program as it currently stands, you should now be
- able to select a customer from the list, click the "Copy" button and then
- paste the selected customer data (as a string) into some other
- application. For example, if you're trying this tutorial on a Windows
- machine, try pasting into a copy of Notepad or Microsoft Word. The pasted
- text should look something like:</para>
-
- <programlisting format="linespecific">#<struct Struct::Customer name="Joe Smith", address="123 Maple, Anytown, NC", zip=12345>
-</programlisting>
- </section>
-
- <section>
- <title>Pasting Data from the Clipboard</title>
-
- <para>We've seen one side of the equation, copying string data to the
- clipboard. But before we can "round-trip" that customer data and paste it
- back into another copy of our customer list application, we're clearly
- going to need to transfer the data in some more useful format. That is to
- say, if we were to receive the customer data in the format that it's
- currently stored on the clipboard:</para>
-
- <programlisting format="linespecific">#<struct Struct::Customer name="Joe Smith", address="123 Maple, Anytown, NC", zip=12345>
-</programlisting>
-
- <para>We'd have to parse that string and try to extract the relevant data
- from it. We can do better than that. The approach we'll use instead is to
- serialize and deserialize the objects using YAML. First, make sure that
- the YAML module is loaded by adding this line:</para>
-
- <programlisting format="linespecific">require 'yaml'</programlisting>
-
- <para>somewhere near the top of the program. Next, register a custom drag
- type for <classname>Customer</classname> objects. We can do that by adding
- one line to our main window's <methodname>create</methodname> instance
- method:</para>
-
- <programlisting format="linespecific">def create
- super
-<emphasis role="bold"> @customerDragType = getApp().registerDragType("application/x-customer")
-</emphasis> show(PLACEMENT_SCREEN)
- end
-</programlisting>
-
- <para>Note that by convention, the name of the drag type is the MIME type
- for the data, but any unique string will do. In our case, we'll use the
- string "application/x-customer" to identify the drag type for our
- YAML-serialized <classname>Customer</classname> objects.</para>
-
- <para>With that in place, we can now go back and slightly change some of
- our previous code. When we acquire the clipboard, we'd now like to be able
- to offer the selected customer's information either as plain text (i.e.
- the previous format) <emphasis>or</emphasis> as a YAML document, so we'll
- include <emphasis>both</emphasis> of these types in the array of drag
- types passed to <methodname>acquireClipboard()</methodname>:</para>
-
- <programlisting format="linespecific"># User clicks Copy
-copyButton.connect(SEL_COMMAND) do
- customer = customerList.getItemData(customerList.currentItem)
-<emphasis role="bold"> types = [ FXWindow.stringType, @customerDragType ]
-</emphasis> if acquireClipboard(types)
- @clippedCustomer = customer
- end
-end
-</programlisting>
-
- <para>Similarly, when we're handling the
- <constant>SEL_CLIPBOARD_REQUEST</constant> message, we now need to pay
- attention to which drag type (i.e. which data format) the requestor
- specified. We can do that by inspecting the
- <methodname>target</methodname> attribute of the
- <classname>FXEvent</classname> instance passed along with the
- <constant>SEL_CLIPBOARD_REQUEST</constant> message:</para>
-
- <programlisting format="linespecific"># Handle clipboard request
-self.connect(SEL_CLIPBOARD_REQUEST) do |sender, sel, event|
- case event.target
- when FXWindow.stringType
- setDNDData(FROM_CLIPBOARD, FXWindow.stringType, Fox.fxencodeStringData(@clippedCustomer.to_s))
- when @customerDragType
- setDNDData(FROM_CLIPBOARD, @customerDragType, @clippedCustomer.to_yaml)
- else
- # Ignore requests for unrecognized drag types
- end
-end
-</programlisting>
-
- <para>With these changes in place, we can now add a handler for the
- "Paste" button which requests the clipboard data in YAML format,
- deserializes it, and then adds an item to the customer list:</para>
-
- <programlisting format="linespecific"># User clicks Paste
-pasteButton.connect(SEL_COMMAND) do
- data = getDNDData(FROM_CLIPBOARD, @customerDragType)
- if data
- customer = YAML.load(data)
- customerList.appendItem(customer.name, nil, customer)
- end
-end
-</programlisting>
-
- <para>The <methodname>getDNDData()</methodname> method used here is the
- inverse of the <methodname>setDNDData()</methodname> method we used
- earlier to push data to some other application requesting our clipboard
- data. As with <methodname>setDNDData()</methodname>, the arguments to
- <methodname>getDNDData()</methodname> indicate the kind of data transfer
- we're performing (e.g. <constant>FROM_CLIPBOARD</constant>) and the drag
- type for the data we're requesting. If some failure occurs (usually,
- because the clipboard owner can't provide its data in the requested
- format) <methodname>getDNDData()</methodname> will simply return
- <constant>nil</constant>.</para>
- </section>
-</chapter>
\ No newline at end of file
diff --git a/users_guide/custom-fo.xsl b/users_guide/custom-fo.xsl
deleted file mode 100755
index 039868c83ae21c67d3303b20cf6ec232044e9d8e..0000000000000000000000000000000000000000
--- a/users_guide/custom-fo.xsl
+++ /dev/null
@@ -1,10 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- version='1.0'
- xmlns="http://www.w3.org/TR/xhtml1/transitional"
- exclude-result-prefixes="#default">
-<xsl:import href="/Users/lyle/docbook/docbook5-xsl-1.72.0/fo/docbook.xsl"/>
-<!--xsl:param name="use.extensions" select="1"/-->
-<xsl:param name="fop.extensions" select="1"/>
-<xsl:param name="shade.verbatim" select="1"/>
-</xsl:stylesheet>
diff --git a/users_guide/custom-html.xsl b/users_guide/custom-html.xsl
deleted file mode 100755
index aa8dd7fe57651d3c7a9320b15d8abb15a4c78dfe..0000000000000000000000000000000000000000
--- a/users_guide/custom-html.xsl
+++ /dev/null
@@ -1,17 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- version='1.0'
- xmlns="http://www.w3.org/TR/xhtml1/transitional"
- exclude-result-prefixes="#default">
-
-<xsl:import href="/Users/lyle/docbook/docbook5-xsl-1.72.0/html/chunk.xsl"/>
-
-<xsl:variable name="root.filename">book</xsl:variable>
-<xsl:param name="html.stylesheet.type">text/css</xsl:param>
-<xsl:param name="html.stylesheet">style.css</xsl:param>
-<xsl:attribute-set name="shade.verbatim.style">
- <xsl:attribute name="width">100%</xsl:attribute>
-</xsl:attribute-set>
-<xsl:variable name="use.id.as.filename">1</xsl:variable>
-
-</xsl:stylesheet>
diff --git a/users_guide/differences.xml b/users_guide/differences.xml
deleted file mode 100755
index c9d21787321cf215e7836e03d92d35ba0af0f9bf..0000000000000000000000000000000000000000
--- a/users_guide/differences.xml
+++ /dev/null
@@ -1,566 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<appendix id="differences">
- <title>Differences between FOX and FXRuby</title>
-
- <para>The FXRuby API follows the FOX API very closely and for the most part,
- you should be able to use the standard FOX class documentation as a
- reference. In some cases, however, fundamental differences between Ruby and
- C++ necessitated slight changes in the API. For some other cases, FOX
- classes were enhanced to take advantage of Ruby language features (such as
- iterators). The purpose of this chapter is to identify some of the
- differences between the C++ and Ruby interfaces to FOX.</para>
-
- <para>One difference that should be easy to cope with is the substitution of
- Ruby Strings for FXStrings. Any function that would normally expect an
- <type>FXString</type> input argument insteads takes a Ruby String.
- Similarly, functions that would return an <type>FXString</type> will instead
- return a Ruby string. For functions that would normally accept a
- <constant>NULL</constant> or empty string argument, just pass
- <constant>nil</constant> or an empty string ("").</para>
-
- <simplesect>
- <title>Functions that expect arrays of objects</title>
-
- <para>One common pattern in FOX member function argument lists is to
- expect a pointer to an array of values, followed by an integer indicating
- the number of values in the array. This of course isn't necessary in Ruby,
- where <classname>Array</classname> objects "know" their lengths. As a
- result, functions such as
- <methodname>FXWindow::acquireClipboard()</methodname>, whose C++
- declaration looks like this:</para>
-
- <programlisting format="linespecific">FXbool acquireClipboard(const FXDragType *types, FXuint numTypes);</programlisting>
-
- <para>are called from Ruby code by passing in a single
- <classname>Array</classname> argument, e.g.</para>
-
- <programlisting format="linespecific">myWindow.acquireClipboard(typesArray)</programlisting>
- </simplesect>
-
- <simplesect>
- <title>Functions that return values by reference</title>
-
- <para>Many FOX methods take advantage of the C++ language feature of
- returning values by reference. For example, the
- <methodname>getCursorPos()</methodname> member function for class
- <classname>FXWindow</classname> has the declaration:</para>
-
- <programlisting format="linespecific">FXint getCursorPos(FXint& x, FXint& y, FXint& buttons) const;</programlisting>
-
- <para>which indicates that the function takes references to three integers
- (x, y and buttons). To call this function from a C++ program, you'd write
- code like this:</para>
-
- <programlisting>FXint x, y;
-FXuint buttons;
-
-if (window->getCursorPosition(x, y, buttons))
- fprintf(stderr, "Current position is (%d, %d)\n", x, y);</programlisting>
-
- <para>Since this idiom doesn't translate well to Ruby, some functions'
- interfaces have been slightly modified. For example, the FXRuby
- implementation of <methodname>getCursorPos()</methodname> returns the
- three values as an <classname>Array</classname>, e.g.:</para>
-
- <programlisting format="linespecific">x, y, buttons = aWindow.getCursorPos()</programlisting>
-
- <para>The following table shows how these kinds of functions are
- implemented in FXRuby:</para>
-
- <informaltable>
- <tgroup cols="2">
- <thead>
- <row>
- <entry align="center">Instance Method</entry>
-
- <entry align="center">Return Value</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><methodname>FXDial#range</methodname></entry>
-
- <entry>Returns a <classname>Range</classname> instance.</entry>
- </row>
-
- <row>
- <entry><methodname>FXDial#range=(aRange)</methodname></entry>
-
- <entry>Accepts a <classname>Range</classname> instance as its
- input.</entry>
- </row>
-
- <row>
- <entry><methodname>FXFontDialog#fontSelection</methodname></entry>
-
- <entry>Returns the <classname>FXFontDesc</classname>
- instance</entry>
- </row>
-
- <row>
- <entry><methodname>FXFontSelector#fontSelection</methodname></entry>
-
- <entry>Returns the <classname>FXFontDesc</classname>
- instance</entry>
- </row>
-
- <row>
- <entry><methodname>FXGLObject#bounds(range)</methodname></entry>
-
- <entry>Takes an <classname>FXRange</classname> instance as its
- input and returns a (possibly modified)
- <classname>FXRange</classname> instance.</entry>
- </row>
-
- <row>
- <entry><methodname>FXGLViewer#eyeToScreen(eye)</methodname></entry>
-
- <entry>Takes an array of eye coordinates (floats) as its input and
- returns the screen point coordinate as an array of integers [sx,
- sy]</entry>
- </row>
-
- <row>
- <entry><methodname>FXGLViewer#getBoreVector(sx,
- sy)</methodname></entry>
-
- <entry>Returns the endpoint and direction vector as an array of
- arrays [point, dir]</entry>
- </row>
-
- <row>
- <entry><methodname>FXGLViewer#light</methodname></entry>
-
- <entry>Returns a <classname>FXLight</classname> instance</entry>
- </row>
-
- <row>
- <entry><methodname>FXGLViewer#viewport</methodname></entry>
-
- <entry>Returns an <classname>FXViewport</classname>
- instance.</entry>
- </row>
-
- <row>
- <entry><methodname>FXPrinterDialog#printer</methodname></entry>
-
- <entry>Returns the <classname>FXPrinter</classname>
- instance</entry>
- </row>
-
- <row>
- <entry><methodname>FXScrollArea#position</methodname></entry>
-
- <entry>Returns the position as an array of integers [x, y]</entry>
- </row>
-
- <row>
- <entry><methodname>FXSlider#range</methodname></entry>
-
- <entry>Returns a <classname>Range</classname> instance.</entry>
- </row>
-
- <row>
- <entry><methodname>FXSlider#range=(aRange)</methodname></entry>
-
- <entry>Accepts a <classname>Range</classname> instance as its
- input.</entry>
- </row>
-
- <row>
- <entry><methodname>FXSpinner#range</methodname></entry>
-
- <entry>Returns a <classname>Range</classname> instance.</entry>
- </row>
-
- <row>
- <entry><methodname>FXSpinner#range=(aRange)</methodname></entry>
-
- <entry>Accepts a <classname>Range</classname> instance as its
- input.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#appendText(text,
- notify=false)</methodname></entry>
-
- <entry>Append text to the end of the buffer.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#appendStyledText(text, style=0,
- notify=false)</methodname></entry>
-
- <entry>Append styled text to the end of the buffer.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#extractText(pos, n)</methodname></entry>
-
- <entry>Extracts <emphasis>n</emphasis> characters from the buffer
- beginning at position <emphasis>pos</emphasis> and returns the
- result as a String.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#extractStyle(pos,
- n)</methodname></entry>
-
- <entry>Extracts <emphasis>n</emphasis> style characters from the
- buffer beginning at position <emphasis>pos</emphasis> and returns
- the result as a String.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#insertText(pos, text,
- notify=false)</methodname></entry>
-
- <entry>Insert <emphasis>text</emphasis> at position
- <emphasis>pos</emphasis> in the buffer.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#insertStyledText(pos, text, style=0,
- notify=false)</methodname></entry>
-
- <entry>Insert <emphasis>text</emphasis> at position
- <emphasis>pos</emphasis> in the buffer.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#replaceText(pos, m, text,
- notify=false)</methodname></entry>
-
- <entry>Replace <emphasis>m</emphasis> characters at
- <emphasis>pos</emphasis> by <emphasis>text</emphasis>.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#replaceStyledText(pos, m, text, style=0,
- notify=false)</methodname></entry>
-
- <entry>Replace <emphasis>m</emphasis> characters at
- <emphasis>pos</emphasis> by <emphasis>text</emphasis>.</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#setDelimiters(delimiters)</methodname></entry>
-
- <entry>Change delimiters of words (<emphasis>delimiters</emphasis>
- is a string).</entry>
- </row>
-
- <row>
- <entry><methodname>FXText#getDelimiters()</methodname></entry>
-
- <entry>Return word delimiters as a string.</entry>
- </row>
-
- <row>
- <entry><methodname>FXWindow#cursorPosition</methodname></entry>
-
- <entry>Returns an array of integers [x, y, buttons]</entry>
- </row>
-
- <row>
- <entry><methodname>FXWindow#translateCoordinatesFrom(window, x,
- y)</methodname></entry>
-
- <entry>Returns the translated coordinates as an array [x,
- y]</entry>
- </row>
-
- <row>
- <entry><methodname>FXWindow#translateCoordinatesTo(window, x,
- y)</methodname></entry>
-
- <entry>Returns the translated coordinates as an array [x,
- y]</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </simplesect>
-
- <simplesect>
- <title>Iterators</title>
-
- <para>Several classes have been extended with an
- <methodname>each</methodname> method to provide Ruby-style iterators.
- These classes include <classname>FXComboBox</classname>,
- <classname>FXGLGroup</classname>, <classname>FXHeader</classname>,
- <classname>FXIconList</classname>, <classname>FXList</classname>,
- <classname>FXListBox</classname>, <classname>FXTreeItem</classname>,
- <classname>FXTreeList</classname> and
- <classname>FXTreeListBox</classname>. These classes also mix-in Ruby's
- <classname>Enumerable</classname> module so that you can take full
- advantage of the iterators.</para>
-
- <para>The block parameters passed to your code block vary depending on the
- class. For example, iterating over an <classname>FXList</classname>
- instance yields <classname>FXListItem</classname> parameters:</para>
-
- <programlisting format="linespecific">aList.each { |aListItem|
- puts "text for this item = #{aListItem.getText()}"
-}</programlisting>
-
- <para>whereas iterating over an <classname>FXComboBox</classname> instance
- yields two parameters, the item text (a string) and the item data:</para>
-
- <programlisting format="linespecific">aComboBox.each { |itemText, itemData|
- puts "text for this item = #{itemText}"
-}</programlisting>
-
- <para>The following table shows the block parameters for each of these
- classes' iterators:</para>
-
- <informaltable>
- <tgroup cols="2">
- <thead>
- <row>
- <entry align="center">Class</entry>
-
- <entry align="center">Block Parameters</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><classname>FXComboBox</classname></entry>
-
- <entry>the item text (a string) and user data</entry>
- </row>
-
- <row>
- <entry><classname>FXGLGroup</classname></entry>
-
- <entry>an <classname>FXGLObject</classname> instance</entry>
- </row>
-
- <row>
- <entry><classname>FXHeader</classname></entry>
-
- <entry>an <classname>FXHeaderItem</classname> instance</entry>
- </row>
-
- <row>
- <entry><classname>FXIconList</classname></entry>
-
- <entry>an <classname>FXIconItem</classname> instance</entry>
- </row>
-
- <row>
- <entry><classname>FXList</classname></entry>
-
- <entry>an <classname>FXListItem</classname> instance</entry>
- </row>
-
- <row>
- <entry><classname>FXListBox</classname></entry>
-
- <entry>the item text (a string), icon (an
- <classname>FXIcon</classname> instance) and user data</entry>
- </row>
-
- <row>
- <entry><classname>FXTreeItem</classname></entry>
-
- <entry>an <classname>FXTreeItem</classname> instance</entry>
- </row>
-
- <row>
- <entry><classname>FXTreeList</classname></entry>
-
- <entry>an <classname>FXTreeItem</classname> instance</entry>
- </row>
-
- <row>
- <entry><classname>FXTreeListBox</classname></entry>
-
- <entry>an <classname>FXTreeItem</classname> instance</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </simplesect>
-
- <simplesect>
- <title>Attribute Accessors</title>
-
- <para>FOX strictly handles access to all object attributes through member
- functions, e.g. <methodname>setBackgroundColor</methodname> and
- <methodname>getBackgroundColor</methodname> or
- <methodname>setText</methodname> and <methodname>getText</methodname>.
- FXRuby exposes all of these functions but also provides aliases that look
- more like regular Ruby attribute accessors. The names for these accessors
- are based on the FOX method names; for example,
- <methodname>setBackgroundColor</methodname> and
- <methodname>getBackgroundColor</methodname> are aliased to
- <methodname>backgroundColor=</methodname> and
- <methodname>backgroundColor</methodname>, respectively.</para>
-
- <para>In many cases these aliases allow you to write more compact and
- legible code. For example, consider this code snippet:</para>
-
- <programlisting format="linespecific">aLabel.setText(aLabel.getText() + " (modified)")</programlisting>
-
- <para>Now consider a different code snippet, using the aliased accessor
- method names:</para>
-
- <programlisting format="linespecific">aLabel.text += " (modified)"</programlisting>
-
- <para>While these two are functionally equivalent, the latter is a bit
- easier to read and understand at first glance.</para>
- </simplesect>
-
- <simplesect>
- <title>Message Passing</title>
-
- <para>FOX message maps are implemented as static C++ class members. With
- FXRuby, you just associate messages with message handlers in the class
- <methodname>initialize</methodname> method using the
- <methodname>FXMAPFUNC()</methodname>,
- <methodname>FXMAPTYPE()</methodname>,
- <methodname>FXMAPTYPES()</methodname> or
- <methodname>FXMAPFUNCS()</methodname> methods. See almost any of the
- example programs for examples of how this is done.</para>
-
- <para>As in C++ FOX, the last argument passed to your message handler
- functions contains message-specific data. For instance, all
- <constant>SEL_PAINT</constant> messages pass an
- <classname>FXEvent</classname> object through this argument to give you
- some information about the size of the exposed rectangle. On the other
- hand, a <constant>SEL_COMMAND</constant> message from an
- <classname>FXHeader</classname> object passes the index of the selected
- header item through this argument. Instead of guessing what's in this last
- argument, your best bet is to instead invoke a member function on the
- sending object to find out what you need, instead of relying on the data
- passed through this pointer. For example, if you get a
- <constant>SEL_COMMAND</constant> message from an
- <classname>FXColorWell</classname> object, the data passed through that
- last argument is supposed to be the new RGB color value. Instead of trying
- to interpret the argument's contents, just turn around and call the color
- well's <methodname>getRGBA()</methodname> member function to retrieve its
- color. Similarly, if you get a <constant>SEL_COMMAND</constant> message
- from a tree list, call its <methodname>getCurrentItem()</methodname>
- method to find out which item was selected.</para>
- </simplesect>
-
- <simplesect>
- <title>Catching Operating System Signals</title>
-
- <para>The <methodname>FXApp#addSignal</methodname> and
- <methodname>FXApp#removeSignal</methodname> methods have been enhanced to
- accept either a string or integer as their first argument. If it's a
- string (e.g. "SIGINT" or just "INT") the code will determine the
- corresponding signal number for you (similar to the standard Ruby
- library's <methodname>Process.kill</methodname> module method). For
- examples of how to use this, see the <filename>datatarget.rb</filename> or
- <filename>imageviewer.rb</filename> example programs.</para>
- </simplesect>
-
- <simplesect>
- <title>Support for Multithreaded Applications</title>
-
- <para>There is some support for multithreaded FXRuby applications, but
- it's not wonderful. The current implementation does what is also done in
- Ruby/GTK; it turns over some idle processing time to the Ruby thread
- scheduler to let other threads do their thing. As I learn more about
- Ruby's threading implementation I may try something different, but this
- seems to work OK for now. For a simple example, see the
- <filename>groupbox.rb</filename> example program, in which the clock label
- that appears in the lower right-hand corner is continuously updated (by a
- separate thread).</para>
-
- <para>If you suspect that FXRuby's threads support is interfering with
- your application's performance, you may want to try tweaking the amount of
- time that the main application thread "sleeps" during idle processing; do
- this by setting the <classname>FXApp</classname> object's
- <structfield>sleepTime</structfield> attribute. The default value for
- <structfield>FXApp#sleepTime</structfield> is 100 milliseconds. You can
- also disable the threads support completely by calling
- <methodname>FXApp#threadsEnabled=false</methodname> (and subsequently
- re-enable it with
- <methodname>FXApp#threadsEnabled=true</methodname>).</para>
- </simplesect>
-
- <simplesect>
- <title>Keyword-Style Arguments</title>
-
- <para>FXRuby 1.6.5 introduced preliminary, experimental support for using
- keyword-style arguments in FXRuby method calls. The current implementation
- of this feature only works for class constructors (i.e. the "new" class
- methods), but the intent is to gradually extend this feature so that it
- covers all FXRuby methods.</para>
-
- <para>What this means in practice is that for calls to methods that have
- one or more optional arguments, you can replace all of the optional
- arguments with a hash that sets only the values for which the default
- isn't appropriate. So, for example, consider a typical call to
- <methodname>FXMainWindow.new</methodname>:</para>
-
- <programlisting>main = FXMainWindow.new(app, "Title Goes Here", nil, nil, DECOR_ALL, 0, 0, 800, 600)</programlisting>
-
- <para>In this case, the programmer wants to set the initial window width
- and height to 800 and 600. In order to do that (with the current release
- of FXRuby), however, she's required to fill in all of the optional
- arguments in between the window title string and the width and height
- values. As anyone who's worked with FXRuby for any amount of time will
- tell you, it's easy to accidentally leave out one of those intermediate
- arguments and it can be difficult to figure out what's wrong
- afterwards.</para>
-
- <para>Now consider how this method call could be written using the new
- keyword arguments support. First, the programmer would need to require the
- keyword arguments library:</para>
-
- <programlisting>require 'fox16/kwargs'</programlisting>
-
- <para>Then she would look up the API documentation for the
- <methodname>FXMainWindow#initialize</methodname> method (e.g. <ulink
- url="http://www.fxruby.org/doc/api/classes/Fox/FXMainWindow.html">here</ulink>)
- and see that the names of the width and height arguments are, in fact,
- "width" and "height". Armed with that information, she would be able to
- rewrite the previous code as:</para>
-
- <programlisting>main = FXMainWindow.new(app, "Title Goes Here", :width => 800, :height => 600)</programlisting>
-
- <para>Here, the programmer has omitted the intermediate optional arguments
- (thus accepting their default values) and specified only the width and
- height values. This code is obviously a lot more readable and
- maintainable.</para>
-
- <para>It is important to observe the difference between required and
- optional arguments when using this feature. If the API documentation for a
- particular method doesn't indicate that an argument has a default value,
- then it is by definition not an optional argument. So one could
- <emphasis>not</emphasis> write the example as, e.g.</para>
-
- <programlisting>main = FXMainWindow.new(app, :width => 800, :title => "Title Goes Here", :height => 600)</programlisting>
-
- <para>This example is incorrect because the title argument is required,
- and it must be the second argument in the call. Obviously, this means that
- the optional arguments in a method call (if they're specified) will always
- follow all of the required arguments.</para>
-
- <para>Finally, note that the keyword arguments feature has been
- implemented so that it's backwards-compatible with the original positional
- arguments scheme (or it's intended to be, at any rate). What that means is
- that you can immediately start making use of this feature in your existing
- code, even if you don't have time to update all of the method calls to use
- keyword arguments.</para>
- </simplesect>
-
- <simplesect>
- <title>Debugging Tricks</title>
-
- <para>As a debugging tool, you can optionally catch exceptions raised in
- message handlers. To turn on this feature, call the
- <methodname>setIgnoreExceptions(true)</methodname> module method. When
- this is enabled, any exceptions raised in message handler functions will
- cause a standard stack trace to be dumped to the standard output, but then
- your application will, for better or worse, proceed normally. Thanks to
- Ted Meng for this suggestion.</para>
- </simplesect>
-</appendix>
\ No newline at end of file
diff --git a/users_guide/dragdroptut.xml b/users_guide/dragdroptut.xml
deleted file mode 100755
index 5db5d2f4076d473115898f5bc76c6cf9953ca545..0000000000000000000000000000000000000000
--- a/users_guide/dragdroptut.xml
+++ /dev/null
@@ -1,803 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="dragdroptut">
- <title>Drag and Drop</title>
-
- <para>One of the more powerful features available to FOX applications is
- drag-and-drop. It's also one of the more complicated to understand. For more
- background, see the standard FOX documentation on <ulink
- url="http://www.fox-toolkit.com/draganddrop.html">Drag and
- Drop</ulink>.</para>
-
- <section>
- <title>Drop Sites</title>
-
- <para>We're going to start by presenting a skeleton application consisting
- of a main window widget (a <classname>DropSite</classname> instance) that
- parents an <classname>FXCanvas</classname> widget:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-class DropSite < FXMainWindow
- def initialize(anApp)
- # Initialize base class
- super(anApp, "Drop Site", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
- end
-
- def create
- # Create the main window and canvas
- super
-
- # Show the main window
- show(PLACEMENT_SCREEN)
- end
-end
-
-if __FILE__ == $0
- FXApp.new("DropSite", "FXRuby") do |theApp|
- DropSite.new(theApp)
- theApp.create
- theApp.run
- end
-end
-</programlisting>
-
- <para>Since the main program (i.e. the part at the end) won't change for
- the rest of the tutorial, I won't show that code anymore. Since an
- <classname>FXCanvas</classname> widget relies on some other object (its
- message target) to draw its contents, we need to handle
- <constant>SEL_PAINT</constant> messages generated by the canvas. We'll do
- that by adding a handler that clears the canvas to its current background
- color:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-class DropSite < FXMainWindow
- def initialize(anApp)
- # Initialize base class
- super(anApp, "Drop Site", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
-
-<emphasis role="bold"> # Handle expose events on the canvas
- @canvas.connect(SEL_PAINT) do |sender, sel, event|
- FXDCWindow.new(@canvas, event) do |dc|
- dc.foreground = @canvas.backColor
- dc.fillRectangle(event.rect.x, event.rect.y, event.rect.w, event.rect.h)
- end
- end</emphasis>
- end
-
- def create
- # Create the main window and canvas
- super
-
- # Show the main window
- show(PLACEMENT_SCREEN)
- end
-end
-</programlisting>
-
- <para>Run this basic version of the program to be sure that it's working
- properly so far. You should simply see an empty window with a white
- background.</para>
-
- <para>Now, on to the fun stuff. Our goal is to be able to drag color data
- from some other window, such as an <classname>FXColorWell</classname>
- widget, and drop it onto the canvas in order to change the canvas'
- background color. In order for a FOX widget to be able to accept drops at
- all, we need to first call its <methodname>dropEnable</methodname>
- method:</para>
-
- <programlisting format="linespecific">def initialize(anApp)
- # Initialize base class
- super(anApp, "Drop Site", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
-
- # Handle expose events on the canvas
- @canvas.connect(SEL_PAINT) do |sender, sel, event|
- FXDCWindow.new(@canvas, event) do |dc|
- dc.foreground = @canvas.backColor
- dc.fillRectangle(event.rect.x, event.rect.y, event.rect.w, event.rect.h)
- end
- end
-
-<emphasis role="bold"> # Enable canvas for drag-and-drop messages
- @canvas.dropEnable
-</emphasis>end
-</programlisting>
-
- <para>At this point, let's try a little test to see if the program does
- anything interesting yet. Start by running some other FOX or FXRuby
- program to use as a drag source for the color data. You should be able to
- use any program that displays an FXColorWell widget, and this includes the
- standard color dialog box shown here:</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/colordialog.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
-
- <para>Each of the small colored boxes near the bottom of the color dialog
- box are color wells, and the large box on the left-hand side of the color
- dialog box is also a color well. Now start your drag-and-drop test program
- and try to drag a color from one of these color wells onto this window. At
- this point, the mouse pointer should turn into a stop sign, indicating
- that the canvas isn't accepting drops of color data yet.</para>
-
- <para>To correct this problem, we need to use the canvas'
- <methodname>acceptDrop</methodname> method to indicate whether or not
- we'll accept certain kinds of drops. You can call
- <methodname>acceptDrop</methodname> any time after receiving the initial
- <constant>SEL_DND_ENTER</constant> message, but it's usually done in
- response to a <constant>SEL_DND_MOTION</constant> message. Let's add a
- handler for <constant>SEL_DND_MOTION</constant> messages from the canvas
- in DropSite's <methodname>initialize</methodname> method. For now, we'll unconditionally accept
- drops from any drag source, regardless of what kind of data they're
- offering:</para>
-
- <programlisting format="linespecific">def initialize(anApp)
- # Initialize base class
- super(anApp, "Drop Site", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
-
- # Handle expose events on the canvas
- @canvas.connect(SEL_PAINT) do |sender, sel, event|
- FXDCWindow.new(@canvas, event) do |dc|
- dc.foreground = @canvas.backColor
- dc.fillRectangle(event.rect.x, event.rect.y, event.rect.w, event.rect.h)
- end
- end
-
- # Enable canvas for drag-and-drop messages
- @canvas.dropEnable
-
-<emphasis role="bold"> # Handle SEL_DND_MOTION messages from the canvas
- @canvas.connect(SEL_DND_MOTION) do
- # Accept drops unconditionally (for now)
- @canvas.acceptDrop
- end
-</emphasis>end
-</programlisting>
-
- <para>Now try the previous test again. This time, when you try to drag
- from a color well to the drop-enabled canvas, you should see the mouse
- pointer turn into a small filled square. This is a visual cue to the user
- indicating that the canvas will accept a drop of the drag-and-drop
- data.</para>
-
- <para>Now it's time to get more specific about what kind of data is being
- dragged between these applications, and how to process that data. So far,
- our drop-enabled canvas merely knows that you're dragging some kind of
- data from a drag source, but it doesn't know what kind of data it is. We
- really need to be more exclusive about what kinds of data are acceptable.
- FOX uses unique drag types to distinguish between different kinds of
- "draggable" data. As you'll see later, you have the freedom to define drag
- types for any kind of application-specific data that you need; but for
- now, we're going to use FOX's built-in drag type for color data.</para>
-
- <para>Drag types (even the standard ones) must be registered before they
- can be used, and so we'll start by adding a few lines to
- <classname>DropSite</classname>'s <methodname>create</methodname> method
- to register the drag type for color data:</para>
-
- <programlisting format="linespecific">def create
- # Create the main window and canvas
- super
-
-<emphasis role="bold"> # Register the drag type for colors
- FXWindow.colorType = getApp().registerDragType(FXWindow.colorTypeName)
-
-</emphasis> # Show the main window
- show(PLACEMENT_SCREEN)
-end
-</programlisting>
-
- <para>Note that the first time that
- <methodname>registerDragType</methodname> is called for a particular
- drag type name (such as <methodname>FXWindow.colorTypeName</methodname>)
- it will generate a unique identifier for that drag type. Subsequent calls
- to <methodname>registerDragType</methodname> for the same drag type name
- will just return the previously-generated drag type. Now, we want to
- modify our <constant>SEL_DND_MOTION</constant> handler so that it's a
- little more picky about which kinds of drops it will accept:</para>
-
- <programlisting format="linespecific"># Handle SEL_DND_MOTION messages from the canvas
-@canvas.connect(SEL_DND_MOTION) do
-<emphasis role="bold"> if @canvas.offeredDNDType?(FROM_DRAGNDROP, FXWindow.colorType)
- @canvas.acceptDrop
- end
-</emphasis>end
-</programlisting>
-
- <para>Here, we call the canvas' <methodname>offeredDNDType?</methodname>
- method to ask if the drag source can provide its data in the requested
- format. Only if <methodname>offeredDNDType?</methodname> returns true will
- we call <methodname>acceptDrop</methodname> as before.</para>
-
- <para>The last step is to actually handle the drop, and for that we add a
- handler for the <constant>SEL_DND_DROP</constant> message:</para>
-
- <programlisting format="linespecific"><emphasis role="bold"># Handle SEL_DND_DROP message from the canvas
-@canvas.connect(SEL_DND_DROP) do
- # Try to obtain the data as color values first
- data = @canvas.getDNDData(FROM_DRAGNDROP, FXWindow.colorType)
- unless data.nil?
- # Update canvas background color
- @canvas.backColor = Fox.fxdecodeColorData(data)
- end
-end</emphasis></programlisting>
-
- <para>Assuming that the drag source is able to provide its data in the
- requested format, the <methodname>getDNDData</methodname> method will
- return a string (which for our purposes is just a byte buffer). If you've
- defined your own application-specific drag types, this data can of course
- be anything, and we'll see examples of this in a later tutorial. But the
- data for standard drag types like
- <methodname>FXWindow.colorType</methodname> can be decoded using the
- appropriate built-in library functions. In this case, we use the
- <methodname>fxdecodeColorData</methodname> method to convert the bytes
- into a color value that we can use.</para>
-
- <para>Now comes the moment of truth. Try running your test program again
- (one that displays a color well). Now, when you drag a color from a color
- well and drop it onto the <classname>DropSite</classname> window, the
- canvas should change its background color accordingly.</para>
-
- <para>The complete program is listed below, and is included in the
- <filename class="directory">examples</filename> directory under the file
- name <filename>dropsite.rb</filename>.</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-class DropSite < FXMainWindow
- def initialize(anApp)
- # Initialize base class
- super(anApp, "Drop Site", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
-
- # Handle expose events on the canvas
- @canvas.connect(SEL_PAINT) do |sender, sel, event|
- FXDCWindow.new(@canvas, event) do |dc|
- dc.foreground = @canvas.backColor
- dc.fillRectangle(event.rect.x, event.rect.y, event.rect.w, event.rect.h)
- end
- end
-
- # Enable canvas for drag-and-drop messages
- @canvas.dropEnable
-
- # Handle SEL_DND_MOTION messages from the canvas
- @canvas.connect(SEL_DND_MOTION) do
- if @canvas.offeredDNDType?(FROM_DRAGNDROP, FXWindow.colorType)
- @canvas.acceptDrop
- end
- end
-
- # Handle SEL_DND_DROP message from the canvas
- @canvas.connect(SEL_DND_DROP) do
- # Try to obtain the data as color values first
- data = @canvas.getDNDData(FROM_DRAGNDROP, FXWindow.colorType)
- unless data.nil?
- # Update canvas background color
- @canvas.backColor = Fox.fxdecodeColorData(data)
- end
- end
- end
-
- def create
- # Create the main window and canvas
- super
-
- # Register the drag type for colors
- FXWindow.colorType = getApp().registerDragType(FXWindow.colorTypeName)
-
- # Show the main window
- show(PLACEMENT_SCREEN)
- end
-end
-
-if __FILE__ == $0
- FXApp.new("DropSite", "FXRuby") do |theApp|
- DropSite.new(theApp)
- theApp.create
- theApp.run
- end
-end
-</programlisting>
- </section>
-
- <section>
- <title>Drag Sources</title>
-
- <para>As before, we're going to start by presenting a skeleton application
- consisting of a main window widget (a <classname>DragSource</classname>
- instance) that parents an <classname>FXCanvas</classname> widget:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-class DragSource < FXMainWindow
- def initialize(anApp)
- # Initialize base class
- super(anApp, "Drag Source", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
- @canvas.backColor = "red"
-
- # Handle expose events on the canvas
- @canvas.connect(SEL_PAINT) do |sender, sel, event|
- FXDCWindow.new(@canvas, event) do |dc|
- dc.foreground = @canvas.backColor
- dc.fillRectangle(event.rect.x, event.rect.y, event.rect.w, event.rect.h)
- end
- end
- end
-
- def create
- # Create the main window and canvas
- super
-
- # Register the drag type for colors
- FXWindow.colorType = getApp().registerDragType(FXWindow.colorTypeName)
-
- # Show the main window
- show(PLACEMENT_SCREEN)
- end
-end
-
-if __FILE__ == $0
- FXApp.new("DragSource", "FXRuby") do |theApp|
- DragSource.new(theApp)
- theApp.create
- theApp.run
- end
-end
-
-</programlisting>
-
- <para>Since the main program (i.e. the part at the end) won't change for
- the rest of the tutorial, I won't show that code anymore. Furthermore, the
- <classname>DragSource</classname> class has a few things in common with
- the <classname>DropSite</classname> class from the previous example,
- namely:</para>
-
- <itemizedlist>
- <listitem>
- <para>We've defined a <constant>SEL_PAINT</constant> handler for the
- canvas widget that just clears the canvas to its current background
- color; and,</para>
- </listitem>
-
- <listitem>
- <para>The drag type for colors
- (<constant>FXWindow.colorType</constant>) is registered in the
- <classname>DragSource</classname>'s <methodname>create</methodname>
- method.</para>
- </listitem>
- </itemizedlist>
-
- <para>As before, you may want to run this basic version of the program to
- be sure that it's working properly so far. You should simply see an empty
- window with a red background.</para>
-
- <para>Now for this application, we want a drag operation to begin when the
- user presses the left mouse button inside the canvas and starts "dragging"
- away from the canvas. So the first change we need to make is to add a
- handler for the <constant>SEL_LEFTBUTTONPRESS</constant> message from the
- canvas:</para>
-
- <programlisting format="linespecific">@canvas.connect(SEL_LEFTBUTTONPRESS) do
- #
- # Capture (grab) the mouse when the button goes down, so that all future
- # mouse events will be reported to this widget, even if those events occur
- # outside of this widget.
- #
- @canvas.grab
-
- # Advertise which drag types we can offer
- dragTypes = [FXWindow.colorType]
- @canvas.beginDrag(dragTypes)
-end
-</programlisting>
-
- <para>Note that there are usually two things you're going to want to do in
- the <constant>SEL_LEFTBUTTONPRESS</constant> handler for a drag source.
- The first is to call <methodname>grab</methodname> on the window that
- acts as the drag source. Calling <methodname>grab</methodname>
- "captures" the mouse in the sense that subsequent mouse motion events will
- be reported as if they occurred inside the grab window. This is important,
- since in our case we're going to be dragging from this window to some
- other window, possibly a window in a different application
- altogether.</para>
-
- <para>The second thing you'll want to do in the
- <constant>SEL_LEFTBUTTONPRESS</constant> handler for a drag source is to
- call <methodname>beginDrag</methodname>. This not only kicks the
- application into drag-and-drop mode, but also provides a way for you to
- inform the system about the formats of data (i.e. the drag types) that
- this drag source is able to provide. For this example, the drag source is
- just going to offer one drag type.</para>
-
- <para>Since releasing the left mouse button should end the drag operation,
- it's important to also add a handler for the
- <constant>SEL_LEFTBUTTONRELEASE</constant> message:</para>
-
- <programlisting format="linespecific">@canvas.connect(SEL_LEFTBUTTONRELEASE) do
- @canvas.ungrab
- @canvas.endDrag
-end
-</programlisting>
-
- <para>This is pretty much the mirror image of our
- <constant>SEL_LEFTBUTTONPRESS</constant> handler. We call
- <methodname>ungrab</methodname> to release the mouse capture, and
- <methodname>endDrag</methodname> to clean up the drag-and-drop
- state.</para>
-
- <para>The next change is to add a <constant>SEL_MOTION</constant> handler,
- to handle mouse motion events during the drag operation:</para>
-
- <programlisting format="linespecific">@canvas.connect(SEL_MOTION) do |sender, sel, event|
- if @canvas.dragging?
- @canvas.handleDrag(event.root_x, event.root_y)
- unless @canvas.didAccept == DRAG_REJECT
- @canvas.dragCursor = getApp().getDefaultCursor(DEF_SWATCH_CURSOR)
- else
- @canvas.dragCursor = getApp().getDefaultCursor(DEF_DNDSTOP_CURSOR)
- end
- end
-end
-</programlisting>
-
- <para>The <methodname>dragging?</methodname> method returns true if we're
- in the middle of a drag-and-drop operation for the drag source window,
- i.e. after the call to <methodname>beginDrag</methodname> but before the
- call to <methodname>endDrag</methodname>. If we're not currently
- processing a drag operation, we're not really interested in mouse motion
- events for the canvas.</para>
-
- <para>If we <emphasis>are</emphasis> processing a drag operation, however,
- we need to call <methodname>handleDrag</methodname> on the drag source
- window. FOX uses this information to send drag-and-drop messages (such as
- <constant>SEL_DND_ENTER</constant>, <constant>SEL_DND_MOTION</constant>
- and <constant>SEL_DND_LEAVE</constant>) to the window that the mouse is
- currently over. Note that the coordinates passed to
- <methodname>handleDrag</methodname> are root window coordinates, and not
- window-local coordinates.</para>
-
- <para>Another good thing to consider doing here is to change the shape of
- the cursor depending on the drop site's response to the drag-and-drop
- messages from the drag source. For this example, we change the drag cursor
- to one of FOX's built-in cursor shapes
- (<constant>DEF_SWATCH_CURSOR</constant>) if we get any response other than
- <constant>DRAG_REJECT</constant> from the drop site. If the drop site
- rejects this drag source's overtures, we instead change the drag cursor to
- a cursor that resembles a stop sign
- (<constant>DEF_DNDSTOP_CURSOR</constant>).</para>
-
- <para>I've purposely avoided suggesting that you run the program for the
- last couple of changes, since until now there wasn't going to be any
- visual indication that anything interesting was happening. But now you
- should be able to run the application in its current state and see a few
- things.</para>
-
- <para>A first test is to confirm that the cursor shape changes to the
- "stop" sign when you attempt to drag over some window that isn't willing
- to accept a drop of the <constant>FXWindow.colorType</constant> drag type.
- Start up one of the other FXRuby example programs (such as the
- <filename>scribble.rb</filename> example) alongside your drag source
- program, and then try "dragging" from the drag source's canvas onto the
- Scribble program's canvas. During the drag attempt, the cursor should
- maintain its shape as a "stop" sign since the canvas in the
- <filename>scribble.rb</filename> example isn't drop-enabled.</para>
-
- <para>Your next test can confirm that the cursor shape changes to the
- "swatch" cursor (a small square) when you attempt to drag over a window
- that is drop-enabled, and which is willing to accepts drops of this drag
- type. The obvious choice is the example from the previous section (the
- dropsite.rb program), but you should have success with any FXRuby example
- program that displays color wells. Start up one of these drop-enabled
- programs alongside your drag source program, and then try "dragging" from
- the drag source's canvas onto the drop site. While the mouse pointer is
- over a drop-enabled window, the cursor should change its shape.</para>
-
- <para>The last (and most important) step is to actually complete the data
- transfer. At any time during a drag-and-drop operation, a drop site may
- request a copy of the drag-and-drop data by calling the
- <methodname>getDNDData</methodname> method (as described in the previous
- section). When this happens, FOX sends a
- <constant>SEL_DND_REQUEST</constant> message to the current drag source
- window, and so we now add a handler for that message:</para>
-
- <programlisting format="linespecific">@canvas.connect(SEL_DND_REQUEST) do |sender, sel, event|
- if event.target == FXWindow.colorType
- @canvas.setDNDData(FROM_DRAGNDROP, FXWindow.colorType, Fox.fxencodeColorData(@canvas.backColor))
- end
-end
-</programlisting>
-
- <para>The first important thing to note here is that the
- <varname>target</varname> field of the <classname>FXEvent</classname>
- instance will contain the drag type requested by the drop site. If your
- drag source offers its data in multiple formats, you definitely need to
- check this in order to know how to package-up the data for transfer.
- However, even if you're only offering the data in a single format (as in
- this example) it's still a good idea to check the requested type, since a
- rogue drop site could ask for the data in some unexpected format.</para>
-
- <para>Assuming that the drag type is as expected, the last step is send
- the data to the drop site by calling
- <methodname>setDNDData</methodname>. As with the call to
- <methodname>getDNDData</methodname> for our previous drop site program,
- you want to be sure to specify the origin of the data
- (<constant>FROM_DRAGNDROP</constant>), the drag type
- (<constant>FXWindow.colorType</constant>) and the data itself as a binary
- string.</para>
-
- <para>As a final test of the completed program, try dragging from this
- window to some drop-enabled window (as described earlier). Now, when you
- release the left mouse button to complete the "drop", the drop site should
- change its color to red.</para>
-
- <para>The complete program is listed below, and is included in the
- <filename class="directory">examples</filename> directory under the file
- name <filename>dragsource.rb</filename>.</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-class DragSource < FXMainWindow
- def initialize(anApp)
- # Initialize base class
- super(anApp, "Drag Source", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
- @canvas.backColor = "red"
-
- # Handle expose events on the canvas
- @canvas.connect(SEL_PAINT) do |sender, sel, event|
- FXDCWindow.new(@canvas, event) do |dc|
- dc.foreground = @canvas.backColor
- dc.fillRectangle(event.rect.x, event.rect.y, event.rect.w, event.rect.h)
- end
- end
-
- # Handle left button press
- @canvas.connect(SEL_LEFTBUTTONPRESS) do
- #
- # Capture (grab) the mouse when the button goes down, so that all future
- # mouse events will be reported to this widget, even if those events occur
- # outside of this widget.
- #
- @canvas.grab
-
- # Advertise which drag types we can offer
- dragTypes = [FXWindow.colorType]
- @canvas.beginDrag(dragTypes)
- end
-
- # Handle mouse motion events
- @canvas.connect(SEL_MOTION) do |sender, sel, event|
- if @canvas.dragging?
- @canvas.handleDrag(event.root_x, event.root_y)
- unless @canvas.didAccept == DRAG_REJECT
- @canvas.dragCursor = getApp().getDefaultCursor(DEF_SWATCH_CURSOR)
- else
- @canvas.dragCursor = getApp().getDefaultCursor(DEF_DNDSTOP_CURSOR)
- end
- end
- end
-
- # Handle left button release
- @canvas.connect(SEL_LEFTBUTTONRELEASE) do
- @canvas.ungrab
- @canvas.endDrag
- end
-
- # Handle request for DND data
- @canvas.connect(SEL_DND_REQUEST) do |sender, sel, event|
- if event.target == FXWindow.colorType
- @canvas.setDNDData(FROM_DRAGNDROP, FXWindow.colorType, Fox.fxencodeColorData(@canvas.backColor))
- end
- end
- end
-
- def create
- # Create the main window and canvas
- super
-
- # Register the drag type for colors
- FXWindow.colorType = getApp().registerDragType(FXWindow.colorTypeName)
-
- # Show the main window
- show(PLACEMENT_SCREEN)
- end
-end
-
-if __FILE__ == $0
- FXApp.new("DragSource", "FXRuby") do |theApp|
- DragSource.new(theApp)
- theApp.create
- theApp.run
- end
-end
-
-</programlisting>
- </section>
-
- <section>
- <title>Putting It All Together</title>
-
- <para>We've studied drag-and-drop enabled applications from two points of
- view, that of a drag source and that of a drop site. But for most
- applications, you'll want a window to act as both a drag source
- <emphasis>and</emphasis> a drop site. As it turns out, this is just a
- simple combination of the techniques we've already seen in the previous
- sections.</para>
-
- <para>If we use our completed drag source example program from the
- previous section as a starting point, and then compare it to the drop site
- example from the first section, it is apparent that the only "pieces"
- missing are:</para>
-
- <itemizedlist>
- <listitem>
- <para>A call to <methodname>dropEnable</methodname>, to make
- <classname>DragSource</classname>'s canvas drop-enabled;</para>
- </listitem>
-
- <listitem>
- <para>A handler for the <constant>SEL_DND_MOTION</constant> message;
- and,</para>
- </listitem>
-
- <listitem>
- <para>A handler for the <constant>SEL_DND_DROP</constant>
- message.</para>
- </listitem>
- </itemizedlist>
-
- <para>If you merge those three short bits of code from
- <filename>dropsite.rb</filename> into <filename>dragsource.rb</filename>,
- you should end up with a program that can act as both a drag source and a
- drop site. To test this program, you should be able to start up two
- separate copies side-by-side and then drag from one to the other. Since,
- as written, both copies will start up with a red background, you might
- want to modify one of them to have a different initial backgroud color.
- Another interesting possibility is to start up a third program (such as an
- FXRuby example that has displays a color dialog) and drag colors back and
- forth between all three programs. You could spend days doing this and
- never leave the house.</para>
-
- <para>The complete program is listed below, and is included in the
- <filename class="directory">examples</filename> directory under the file
- name <filename>dragdrop.rb</filename>.</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-class DragDropWindow < FXMainWindow
- def initialize(anApp)
- # Initialize base class
- super(anApp, "Drag and Drop", :opts => DECOR_ALL, :width => 400, :height => 300)
-
- # Fill main window with canvas
- @canvas = FXCanvas.new(self, :opts => LAYOUT_FILL_X|LAYOUT_FILL_Y)
- @canvas.backColor = "red"
-
- # Enable canvas for drag-and-drop messages
- @canvas.dropEnable
-
- # Handle expose events on the canvas
- @canvas.connect(SEL_PAINT) do |sender, sel, event|
- FXDCWindow.new(@canvas, event) do |dc|
- dc.foreground = @canvas.backColor
- dc.fillRectangle(event.rect.x, event.rect.y, event.rect.w, event.rect.h)
- end
- end
-
- # Handle left button press
- @canvas.connect(SEL_LEFTBUTTONPRESS) do
- #
- # Capture (grab) the mouse when the button goes down, so that all future
- # mouse events will be reported to this widget, even if those events occur
- # outside of this widget.
- #
- @canvas.grab
-
- # Advertise which drag types we can offer
- dragTypes = [FXWindow.colorType]
- @canvas.beginDrag(dragTypes)
- end
-
- # Handle mouse motion events
- @canvas.connect(SEL_MOTION) do |sender, sel, event|
- if @canvas.dragging?
- @canvas.handleDrag(event.root_x, event.root_y)
- unless @canvas.didAccept == DRAG_REJECT
- @canvas.dragCursor = getApp().getDefaultCursor(DEF_SWATCH_CURSOR)
- else
- @canvas.dragCursor = getApp().getDefaultCursor(DEF_DNDSTOP_CURSOR)
- end
- end
- end
-
- # Handle SEL_DND_MOTION messages from the canvas
- @canvas.connect(SEL_DND_MOTION) do
- if @canvas.offeredDNDType?(FROM_DRAGNDROP, FXWindow.colorType)
- @canvas.acceptDrop
- end
- end
-
- # Handle left button release
- @canvas.connect(SEL_LEFTBUTTONRELEASE) do
- @canvas.ungrab
- @canvas.endDrag
- end
-
- # Handle SEL_DND_DROP message from the canvas
- @canvas.connect(SEL_DND_DROP) do
- # Try to obtain the data as color values first
- data = @canvas.getDNDData(FROM_DRAGNDROP, FXWindow.colorType)
- unless data.nil?
- # Update canvas background color
- @canvas.backColor = Fox.fxdecodeColorData(data)
- end
- end
-
- # Handle request for DND data
- @canvas.connect(SEL_DND_REQUEST) do |sender, sel, event|
- if event.target == FXWindow.colorType
- @canvas.setDNDData(FROM_DRAGNDROP, FXWindow.colorType, Fox.fxencodeColorData(@canvas.backColor))
- end
- end
- end
-
- def create
- # Create the main window and canvas
- super
-
- # Register the drag type for colors
- FXWindow.colorType = getApp().registerDragType(FXWindow.colorTypeName)
-
- # Show the main window
- show(PLACEMENT_SCREEN)
- end
-end
-
-if __FILE__ == $0
- FXApp.new("DragDrop", "FXRuby") do |theApp|
- DragDropWindow.new(theApp)
- theApp.create
- theApp.run
- end
-end
-
-</programlisting>
- </section>
-</chapter>
\ No newline at end of file
diff --git a/users_guide/events.xml b/users_guide/events.xml
deleted file mode 100755
index f348bbddbab76883e29f8bb3cf64d85fc0431a52..0000000000000000000000000000000000000000
--- a/users_guide/events.xml
+++ /dev/null
@@ -1,102 +0,0 @@
-<chapter id="events">
- <title>FXRuby's Message-Target System</title>
- <simplesect>
- <title>Background</title>
- <para>One of the biggest flaws with earlier releases of FXRuby was its strict reproduction of FOX's process for mapping GUI events (messages) to instance methods (handlers). That process involved four distinct steps:</para>
- <orderedlist numeration="arabic" spacing="compact">
- <listitem><para>Initializing a <emphasis>message identifier</emphasis>, an integer that helps to disambiguate the sender of the message and/or its purpose.</para></listitem>
- <listitem><para>Mapping a specific message type and identifier to an instance method for the message target object.</para></listitem>
- <listitem><para>Implementing the actual handler method in the message target.</para></listitem>
- <listitem><para>Registering the message target and message identifier with the widget that's going to send the messages.</para></listitem>
- </orderedlist>
- <para>So, for example, let's say you wanted to create a button widget that, when pressed, prints the string "Ouch!" to the terminal. In the old scheme of things, you'd need to identify some object to act as the target for any messages generated by this button. To keep things simple, let's say that the application's main window (<emphasis>mainWindow</emphasis>) is designated as the target for the button. We'll need to generate a unique identifier associated with the button:</para>
- <programlisting format="linespecific"><![CDATA[class MyMainWindow < FXMainWindow
-
- include Responder
-
- ID_BUTTON = FXMainWindow::ID_LAST
-
- ... other stuff ...
-end]]></programlisting>
- <para>Next, you'd want to specify the mapping for a specific message type to the target's instance method that handles that message:</para>
- <programlisting format="linespecific"><![CDATA[FXMAPFUNC(SEL_COMMAND, MyMainWindow::ID_BUTTON, 'onCmdButton')]]></programlisting>
- <para>Finally, you'd need to implement the instance method (<methodname>onCmdButton</methodname>) named in the call to <methodname>FXMAPFUNC</methodname>:</para>
- <programlisting format="linespecific"><![CDATA[def onCmdButton(sender, sel, ptr)
- puts "Ouch!"
-end]]></programlisting>
- <para>The last step is to tell the button who it's message target is, and which message identifier to use when sending messages to that target:</para>
- <programlisting format="linespecific"><![CDATA[aButton = FXButton.new(parent, "Push Me", nil, mainWindow, ID_BUTTON)]]></programlisting>
- <para>This was an extremely tedious process, especially for programmers who are used to Ruby/Tk's or Ruby/GTK's approach for connecting signals (events) to blocks that handle the signal. After some discussions at RubyConf 2001 and subsequent discussions on the Ruby newsgroup, a new model was proposed and hashed out on the RubyGarden Wiki. This new model was introduced with the FXRuby-0.99.179 release.</para>
- </simplesect>
- <simplesect>
- <title>Event Model</title>
- <para>FXRuby implements a new, simplified approach to this built on top of the old model. It more or less mimics the syntax used in Ruby/GTK; you can attach a message handler block to a widget using a new <methodname>connect</methodname> instance method, e.g.</para>
- <programlisting format="linespecific"><![CDATA[aButton = FXButton.new(parent, "Push Me")
-aButton.connect(SEL_COMMAND) { |sender, sel, ptr|
- puts "Ouch!"
-}]]></programlisting>
- <para>Alternate forms of the <methodname>FXObject#connect</methodname> method can take either a <classname>Method</classname> or <classname>Proc</classname> instance as a second argument (i.e. instead of attaching a block), e.g.</para>
- <programlisting format="linespecific"><![CDATA[def push(sender, sel, ptr)
- puts "Ouch!"
-end
-
-aButton = FXButton.new(parent, "Push Me")
-aButton.connect(SEL_COMMAND, method(:push))]]></programlisting>
- <para>It works by creating a special target object (behind the scenes) that stands-in as the message target for your widget and passes off incoming messages to the appropriate block. The single argument to <methodname>connect</methodname> is the FOX message type you're handling (e.g. <constant>SEL_COMMAND</constant>, <constant>SEL_CHANGED</constant>, etc.) The three arguments to the block are the same as those for regular FOX message handler methods, namely, the sender object, the message type and identifier and the message data. And of course, for simple handlers like this one, you can just leave the arguments off altogether:</para>
- <programlisting format="linespecific"><![CDATA[aButton = FXButton.new(parent, "Push Me")
-aButton.connect(SEL_COMMAND) { puts "Ouch!" }]]></programlisting>
- </simplesect>
- <simplesect>
- <title>Timers</title>
- <para>Timers are scheduled by calling <methodname>FXApp#addTimeout</methodname>. There are three different forms of <methodname>addTimeout</methodname>, but the first argument to each is the timeout interval in milliseconds. The most primitive version of this method takes two additional arguments to specify the target object and message identifier for the object that will handle the timeout event:</para>
- <programlisting format="linespecific"><![CDATA[aTimer = getApp().addTimeout(1000, timeoutHandlerObj, ID_TIMER)]]></programlisting>
- <para>The second form takes either a <classname>Method</classname> or <classname>Proc</classname> instance as its second argument, e.g.</para>
- <programlisting format="linespecific"><![CDATA[aTimer = getApp().addTimeout(1000, method(:timeoutHandlerMethod))]]></programlisting>
- <para>The last form uses a code block as the handler for the timeout event:</para>
- <programlisting format="linespecific"><![CDATA[aTimer = getApp().addTimeout(1000) { |sender, sel, ptr|
- # handle this timeout event
-}]]></programlisting>
- </simplesect>
- <simplesect>
- <title>Chores</title>
- <para>Chores are scheduled by calling <methodname>FXApp#addChore</methodname>. There are three different forms of <methodname>addChore</methodname>; the most primitive version requires two arguments to specify the target object and message identifier for the object that will handle the chore event:</para>
- <programlisting format="linespecific"><![CDATA[aChore = getApp().addChore(choreHandlerObj, ID_CHORE)]]></programlisting>
- <para>The second form takes either a <classname>Method</classname> or <classname>Proc</classname> instance as its single argument, e.g.</para>
- <programlisting format="linespecific"><![CDATA[aChore = getApp().addChore(method(:choreHandlerMethod))]]></programlisting>
- <para>The last form uses a code block as the handler for the chore:</para>
- <programlisting format="linespecific"><![CDATA[aChore = getApp().addChore { |sender, sel, ptr|
- # handle this chore
-}]]></programlisting>
- </simplesect>
- <simplesect>
- <title>Signals</title>
- <para>Operating system signal handlers are designated by calling <methodname>FXApp#addSignal</methodname>. There are three different forms of <methodname>addSignal</methodname>, but the first argument to each is the signal name (e.g. "SIGINT") or number. Each version also has two optional arguments (which should come at the end of the list) to specify <parameter>immediate</parameter> and <parameter>flags</parameter>. The most primitive version of this method takes two additional arguments to specify the target object and message identifier for the object that will handle this operating system signal:</para>
- <programlisting format="linespecific"><![CDATA[aSignal = getApp().addSignal("SIGINT", signalHandlerObj, ID_SIGINT)]]></programlisting>
- <para>The second form takes either a <classname>Method</classname> or <classname>Proc</classname> instance as its second argument, e.g.</para>
- <programlisting format="linespecific"><![CDATA[aSignal = getApp().addSignal("SIGINT", method(:signalHandlerMethod))]]></programlisting>
- <para>The last form uses a code block as the handler for the signal:</para>
- <programlisting format="linespecific"><![CDATA[aSignal = getApp().addSignal("SIGINT") { |sender, sel, ptr|
- # handle this signal
-}]]></programlisting>
- </simplesect>
- <simplesect>
- <title>Input Events</title>
- <para>Input event handlers are designated by calling <methodname>FXApp#addInput</methodname>. There are three different forms of <methodname>addInput</methodname>, but the first two arguments to each are the file object (including sockets) and the mode flag (some combination of <constant>INPUT_READ</constant>, <constant>INPUT_WRITE</constant> and <constant>INPUT_EXCEPT</constant>). The most primitive version of this method takes two additional arguments to specify the target object and message identifier for the object that will handle this input event:</para>
- <programlisting format="linespecific"><![CDATA[getApp().addInput(aFile, INPUT_READ, inputHandlerObj, ID_INPUT)]]></programlisting>
- <para>The second form takes either a <classname>Method</classname> or <classname>Proc</classname> instance as its third argument, e.g.</para>
- <programlisting format="linespecific"><![CDATA[getApp().addInput(aSocket, INPUT_READ|INPUT_EXCEPT, method(:inputHandlerMethod))]]></programlisting>
- <para>The last form uses a code block as the handler for the input event:</para>
- <programlisting format="linespecific"><![CDATA[getApp().addInput(aFile, INPUT_WRITE|INPUT_EXCEPT) { |sender, sel, ptr|
- # handle this input
-}]]></programlisting>
- <para>This API is a little different from the other cases. For example, timeout events always send the same message type (<constant>SEL_TIMEOUT</constant>) to their message target, so you just have a single handler method (or block) to handle the timeout. In contrast, input sources (e.g. pipes or sockets) can generate three different FOX messages, <constant>SEL_IO_READ</constant>, <constant>SEL_IO_WRITE</constant> and <constant>SEL_IO_EXCEPTION</constant>, depending on what happens, so your handler method (block) needs to check the message type, e.g.</para>
- <programlisting format="linespecific"><![CDATA[getApp().addInput(socket, INPUT_READ|INPUT_WRITE) { |sender, sel, ptr|
- case SELTYPE(sel)
- when SEL_IO_READ
- # handle read event
- when SEL_IO_WRITE
- # handle write event
- end
-}]]></programlisting>
- </simplesect>
-</chapter>
diff --git a/users_guide/examples.xml b/users_guide/examples.xml
deleted file mode 100755
index 3ec08de5dbe36522d6049eaab399e6b5481fa56d..0000000000000000000000000000000000000000
--- a/users_guide/examples.xml
+++ /dev/null
@@ -1,476 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="examples">
- <title>Examples</title>
-
- <simplesect>
- <para>The <ulink url="../examples/hello.rb"><filename>hello.rb</filename></ulink>
- example program is about as short as it gets for a working FXRuby program.
- Use this as a starting point for understanding the basic elements of an
- FXRuby program, especially if you're new to GUI programming in
- general.</para>
-
- <title>hello</title>
-
- <screenshot><mediaobject> <imageobject><imagedata align="center"
- fileref="images/hello.png" format="PNG"></imagedata></imageobject>
- </mediaobject></screenshot>
- </simplesect>
-
- <simplesect>
- <title>hello2</title>
-
- <para>The <ulink url="../examples/hello2.rb"><filename>hello2.rb</filename></ulink>
- example kicks it up a notch by adding an icon and tooltip to the button
- from the <filename>hello.rb</filename> example.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/hello2.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>scribble</title>
-
- <para>The <ulink url="../examples/scribble.rb"><filename>scribble.rb</filename></ulink>
- example is a good demonstration of how to obtain a device context for a
- window (in this case, an <classname>FXCanvas</classname>) and draw into
- that window. It also provides a basic demonstration of how FOX's GUI
- updating mechanism can be used to automatically update the state of
- widgets based on the application's state. Observe the "Clear"
- button becoming enabled and disabled (greyed-out) depending on whether the
- canvas is currently "dirty" or "clean", and then see how
- this updating is actually handled in the code.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/scribble.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>button</title>
-
- <para>The <ulink url="../examples/button.rb"><filename>button.rb</filename></ulink>
- example program shows off the various options (or button styles) for
- <classname>FXButton</classname> widgets.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/button.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>datatarget</title>
-
- <para>The <ulink url="../examples/datatarget.rb"><filename>datatarget.rb</filename></ulink>
- example program demonstrates most or all of the widgets that can work with
- FOX data targets (that is, instances of class <classname>FXDataTarget</classname>).
- Data targets are special objects that have a a string, float or integer
- value associated with them, and can interact with widgets to keep the data
- target's value in sync with the widget's setting. For example, you
- can create a data target with a string value and attach that to a text
- field widget. When the user types a new value in the text field, the data
- target's value is automatically updated; and when the data
- target's value is changed, the text field will update its setting.
- Since a single data targets can be attached to multiple widgets, this can
- be a useful way to keep multiple controls for the same logical value in
- sync with each other.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/datatarget.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>dialog</title>
-
- <para>The <ulink url="../examples/dialog.rb"><filename>dialog.rb</filename></ulink>
- example is a simple program demonstrating how to construct and display
- modal and non-modal dialog boxes.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/dialog.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>dirlist</title>
-
- <para>The <ulink url="../examples/dirlist.rb"><filename>dirlist.rb</filename></ulink>
- example program demonstrates the <classname>FXDirList</classname> widget.
- The directory list is a special kind of tree list, where each tree item
- represents a directory (or folder) in the file system.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/dirlist.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>iconlist</title>
-
- <para>The <ulink url="../examples/iconlist.rb"><filename>iconlist.rb</filename></ulink>
- example program demonstrates the <classname>FXIconList</classname> widget.
- An icon list is a special kind of list widget that can display its
- contents in one of three basic modes (details mode, small icons mode or
- large icons mode). The first screenshot below shows an icon list in
- details mode, while the second shows the same icon list in "big
- icons" mode.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/iconlist-details.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/iconlist-bigicons.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>mditest</title>
-
- <para>The <ulink url="../examples/mditest.rb"><filename>mditest.rb</filename></ulink>
- example program demonstrates FOX's Multiple Document Interface (MDI)
- capabilities, specifically the <classname>FXMDIClient</classname> and
- <classname>FXMDIChild</classname> classes.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/mditest.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>groupbox</title>
-
- <para>The <ulink url="../examples/groupbox.rb"><filename>groupbox.rb</filename></ulink>
- example program is a kind of "periodic table of widgets"
- demonstration, FOX-style. It shows off a lot of the FOX widgets as well as
- providing a good exercise of FOX's layout managers.</para>
-
- <screenshot>
- <mediaobject>
-
-
- <imageobject>
- <imagedata align="center" fileref="images/groupbox.png" format="PNG" />
- </imageobject>
-
-
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>header</title>
-
- <para>The <ulink url="../examples/header.rb"><filename>header.rb</filename></ulink>
- example program mainly demonstrates the <classname>FXHeader</classname>
- widget and the <classname>FXSplitter</classname> layout manager.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/header.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>image</title>
-
- <para>The <ulink url="../examples/image.rb"><filename>image.rb</filename></ulink>
- example demonstrates how to draw directly into an <classname>FXImage</classname>
- object and then "draw" that image into a canvas.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/image.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>splitter</title>
-
- <para>The <ulink url="../examples/splitter.rb"><filename>splitter.rb</filename></ulink>
- example demonstrates the <classname>FXSplitter</classname> layout manager.
- It also provides an example of the <classname>FXTreeList</classname>
- widget (on the left side of the split) and the <classname>FXMatrix</classname>
- layout manager (in the middle pane).</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/splitter.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>foursplit</title>
-
- <para>The <ulink url="../examples/foursplit.rb"><filename>foursplit.rb</filename></ulink>
- example program demonstrates the <classname>FX4Splitter</classname> layout
- manager. This four-way split is especially useful for CAD-type programs
- where it's necessary to show multiple views of the model
- simultaneously.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/foursplit.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>shutter</title>
-
- <para>The <ulink url="../examples/shutter.rb"><filename>shutter.rb</filename></ulink>
- example provides a simple demonstration of the <classname>FXShutter</classname>
- widget, with the skeleton of a PIM-type application. The very nice icons
- used for this program are courtesy of <ulink
- url="http://www.forrestwalter.com/icons">Gort's Icons</ulink>.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/shutter.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>tabbook</title>
-
- <para>The <ulink url="../examples/tabbook.rb"><filename>tabbook.rb</filename></ulink>
- example exists mainly to demonstrate the <classname>FXTabBook</classname>
- widget, but shows off a few other features in the process.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/tabbook.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>table</title>
-
- <para>The <ulink url="../examples/table.rb"><filename>table.rb</filename></ulink>
- example features the <classname>FXTable</classname> widget, sometimes
- known as a "grid" or "spreadsheet" widget in other
- toolkits.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/table.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>gltest</title>
-
- <para>The <ulink url="../examples/gltest.rb"><filename>gltest.rb</filename></ulink>
- example program demonstrates how to create a basic OpenGL canvas (i.e. an
- instance of the <classname>FXGLCanvas</classname> widget) and draw into
- it. It also demonstrates how to use timers and chores. This example
- requires the Ruby/OpenGL extension, available from the Ruby Application
- Archive.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/gltest.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>glviewer</title>
-
- <para>The <ulink url="../examples/glviewer.rb"><filename>glviewer.rb</filename></ulink>
- example program demonstrates how to use the <classname>FXGLViewer</classname>
- widget and draw various kinds of GL objects into it. It can also be used
- as model for a fairly complicated FXRuby application, since it includes a
- lot of typical features (like a menu bar, toolbar, status line, etc.).</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/glviewer.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>imageviewer</title>
-
- <para>Like the <ulink url="../examples/glviewer.rb"><filename>glviewer.rb</filename></ulink>
- example, the <ulink url="../examples/imageviewer.rb"><filename>imageviewer.rb</filename></ulink>
- can be used as a model for a typical full-featured GUI application, with a
- menu bar, toolbar, and so forth. It also features the
- <classname>FXImageView</classname> widget.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/imageviewer.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>dilbert</title>
-
- <para>The <ulink url="../examples/dilbert.rb"><filename>dilbert.rb</filename></ulink>
- example fetches the "Daily Dilbert" cartoon and displays it in a
- window. This was just a fun little exercise for me, but it does provide a
- more bare-bones example of the <classname>FXImageView</classname> widget
- than that provided by the (more complicated) <filename>imageviewer.rb</filename>
- example.</para>
-
- <para>This example program requires the html-parser extension, available
- from the Ruby Application Archive.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/dilbert.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>raabrowser</title>
-
- <para>The <ulink url="../examples/raabrowser.rb"><filename>raabrowser.rb</filename></ulink>
- example program shows a treelist view of the current Ruby Application
- Archive (RAA) contents, and product-specific information for the currently
- selected product in the panel on the right. This is a good demonstration
- of the following features:</para>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>the <classname>FXSplitter</classname> layout manager, used to
- split the left side (containing the tree list) from the right side
- (containing the information panel). If the panel on the left is too
- narrow to see all of its contents (especially when you've expanded
- the tree) try resizing the split.</para>
- </listitem>
-
- <listitem>
- <para>the <classname>FXTreeList</classname> widget, used to display
- the RAA contents.</para>
- </listitem>
-
- <listitem>
- <para>data targets (i.e. instances of class <classname>FXDataTarget</classname>),
- which are used for the contents of the fields in the information
- panel.</para>
- </listitem>
- </itemizedlist>
-
- <para>This example program requires the <ulink
- url="http://www.jin.gr.jp/~nahi/Ruby/SOAP4R">SOAP4R</ulink> extension.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/raabrowser.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>babelfish</title>
-
- <para>The <ulink url="../examples/babelfish.rb"><filename>babelfish.rb</filename></ulink>
- example program, like the <filename>raabrowser.rb</filename> example,
- depends on the <ulink url="http://www.jin.gr.jp/~nahi/Ruby/SOAP4R">SOAP4R</ulink>
- extension. Other than that it doesn't bring anything new to the table.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/babelfish.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-
- <simplesect>
- <title>browser</title>
-
- <para>The <ulink url="../examples/browser.rb"><filename>browser.rb</filename></ulink>
- example program is mainly a "me too" for the class browser
- distributed with Ruby/GTK. It's hard for me to get excited about it,
- but here it is.</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/browser.png" format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </simplesect>
-</chapter>
\ No newline at end of file
diff --git a/users_guide/gems.xml b/users_guide/gems.xml
deleted file mode 100755
index b9db6166f66a3f6415b117267d5ab6234ea61d4c..0000000000000000000000000000000000000000
--- a/users_guide/gems.xml
+++ /dev/null
@@ -1,158 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="gems">
- <title>Installing from Gems</title>
-
- <simplesect>
- <title>Introduction</title>
-
- <para>FXRuby uses <ulink
- url="http://rubygems.rubyforge.org">RubyGems</ulink> as its preferred
- packaging and distribution method. The code is available both as</para>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>a "source" gem, which contains source code that must be compiled
- on your computer before it's installed; and,</para>
- </listitem>
-
- <listitem>
- <para>a "binary" gem, which contains a precompiled version of the code
- for a specific operating system (such as Windows).</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Installing from a Source Gem</title>
-
- <para>If you've already downloaded the source gem, you can install it by
- typing:</para>
-
- <screen>$ <command>sudo gem install fxruby-1.6.13.gem</command></screen>
-
- <para>Note the use of the <command>sudo</command> command to invoke
- superuser privileges, since you'll typically need superuser privileges to
- install the library files. By default, the source gem will look for your
- FOX (and optionally, FXScintilla) installation in a few standard places,
- such as the <filename>/usr</filename>, <filename>/usr/local</filename> and
- <filename>/sw</filename> directories. If you've installed those libraries
- under some other directory (for example, in your home directory) you might
- need to pass some additional arguments on the command line, e.g.</para>
-
- <screen>$ <command>sudo gem install fxruby-1.6.13.gem --force -- --with-fox-include=/home/lyle/include/fox-1.6 --with-fox-lib=/home/lyle/lib</command></screen>
-
- <para>If you're installing a source gem on a Windows box, you'd instead
- type something like:</para>
-
- <screen>C:\> <command>gem install fxruby-1.6.13.gem --force -- --with-fox-include=C:\include\fox-1.6 --with-fox-lib=C:\lib</command></screen>
-
- <para>If you're installing a source gem, it can take quite awhile to build
- FXRuby, so this might be a good time to take a coffee break. You won't see
- any compiler output appear on the screen while the gem is compiling, but
- rest assured that the output is being saved into the
- <filename>gem_make.out</filename> file.</para>
-
- <para>As a quick sanity check, to make sure that all is well, you should
- probably fire up <filename>irb</filename> and try to require the FXRuby
- gem once the installation is complete:</para>
-
- <screen>$ <command>irb</command>
-irb(main):001:0> <userinput><command>require 'rubygems'</command></userinput>
-true
-irb(main):002:0> <command>require 'fox16'</command>
-true</screen>
-
- <para>If the import failed (usually with a message along the lines of
- "Cannot load library"), first check the "Things That Can Go Wrong" section
- of this chapter. If that doesn't help, drop me an e-mail or ask around on
- the Ruby newsgroup or mailing list; it's quite likely that someone else
- has run into this problem too. Once you do have a working FXRuby
- installation, you're ready to check out the example programs.</para>
- </simplesect>
-
- <simplesect>
- <title>Installing from a Binary Gem</title>
-
- <para>To install a binary gem for Windows, just type:</para>
-
- <screen>C:\> <command>gem install fxruby-1.6.13-mswin32.gem</command></screen>
-
- <para>As a quick sanity check, to make sure that all is well, you should
- probably fire up <filename>irb</filename> and try to require the FXRuby
- gem once the installation is complete:</para>
-
- <screen>C:\> <command>irb</command>
-irb(main):001:0> <userinput><command>require 'rubygems'</command></userinput>
-true
-irb(main):002:0> <command>require 'fox16'</command>
-true</screen>
-
- <para>If the import failed (usually with a message along the lines of
- "Cannot load library"), first check the "Things That Can Go Wrong" section
- of this chapter. If that doesn't help, drop me an e-mail or ask around on
- the Ruby newsgroup or mailing list; it's quite likely that someone else
- has run into this problem too. Once you do have a working FXRuby
- installation, you're ready to check out the example programs.</para>
- </simplesect>
-
- <simplesect>
- <title>Things That Can Go Wrong</title>
-
- <para><emphasis>"Cannot load library"</emphasis></para>
-
- <para>On Linux and other Unix systems that support shared libraries, FOX
- is typically installed as a shared library named
- <filename>libFOX-1.6.so</filename>. After all of the source files for
- FXRuby are compiled, the last step is to link all of the FXRuby object
- files together with the FOX library (and possibly other system libraries)
- to produce a new shared object that Ruby can import as an extension
- module.</para>
-
- <para>There are a few things that can go wrong when you try to import this
- extension into Ruby. A common problem is that the operating system cannot
- locate the FOX shared library (<filename>libFOX-1.6.so</filename>) when it
- tries to dynamically load the FXRuby extension module; when this happens,
- the error message will look something like:</para>
-
- <screen>$ <command>irb</command>
-irb(main):001:0> <userinput>require 'fox16'</userinput>
-LoadError: libFOX-1.6.so: cannot open shared object file: No such file or directory - /usr/local/lib/ruby/1.8/i686-linux/fox16.so
- from (irb):1:in 'require'
- from (irb):1
- </screen>
-
- <para>Note that the wording of this error message may be slightly
- different, depending on your operating environment. One workaround for
- this problem is to modify the <constant>LD_LIBRARY_PATH</constant>
- environment variable to include the directory where
- <filename>libFOX-1.6.so</filename> is installed. For example, if
- <filename>libFOX-1.6.so</filename> is installed in <filename
- class="directory">/usr/local/lib</filename>, try setting:</para>
-
- <screen>$ <command>export LD_LIBRARY_PATH=/usr/local/lib</command>
-$ <command>irb</command>
-irb(main):001:0> <userinput>require 'fox16'</userinput>
-</screen>
-
- <para>If this works, you can of course permanently add the
- <constant>LD_LIBRARY_PATH</constant> setting to your login file(s) so that
- you don't have to remember to type it each time. Another approach that
- should work for Linux is to modify your
- <filename>/etc/ld.so.conf</filename> file to include the installation
- directory (e.g. <filename>/usr/local/lib</filename>). If you'd like to do
- this instead, you'll need to (as root):</para>
-
- <orderedlist numeration="arabic" spacing="compact">
- <listitem>
- <para>Edit your <filename>/etc/ld.so.conf</filename> file and add the
- directory where <filename>libFOX-1.6.so</filename> is installed;
- and,</para>
- </listitem>
-
- <listitem>
- <para>At the shell prompt, type <command>ldconfig</command> to reload
- the linker configuration.</para>
- </listitem>
- </orderedlist>
- </simplesect>
-</chapter>
\ No newline at end of file
diff --git a/users_guide/goals.xml b/users_guide/goals.xml
deleted file mode 100755
index 8d79c9e9c8fe02450e92c406d23c69b79ed6336e..0000000000000000000000000000000000000000
--- a/users_guide/goals.xml
+++ /dev/null
@@ -1,58 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<preface id="goals">
- <title>History and Goals</title>
- <para>The primary goal of this project was (and is) to provide a complete
- interface to <ulink url="http://www.fox-toolkit.com">FOX</ulink> from
- <ulink url="http://www.ruby-lang.org">Ruby</ulink>. Ruby programs should
- be able to access FOX classes transparently; this includes deriving new
- Ruby classes from FOX classes and overriding their virtual functions. This
- goal has been met pretty well at this point although there are undoubtedly
- a number of bugs waiting to be discovered.</para>
- <para>A secondary goal of the project is to promote Ruby and FOX, two great
- open-source projects that both deserve wider recognition. After discovering
- Ruby and monitoring the comp.lang.ruby newsgroup postings for only a few
- weeks, it became apparent that users were dissatisfied with the existing
- GUI options for Ruby. As with Python, Tk is the de facto standard because
- of its maturity and availability on a number of platforms (including the
- Macintosh). But Tk is also showing its age in many ways and it has failed
- to keep pace with some of the "younger" cross-platform GUI toolkits like
- FOX, wxWidgets, FLTK, Qt and GTK+. Of the latter five, only Qt and GTK+
- appeared (at the time) to have usable Ruby interfaces and there are some
- problems associated with these as well; for Qt, it's the restrictive
- license for the Windows platform version, and for GTK+ it's a Windows
- version that often lags far behind the standard Linux/Unix version. There
- is clearly a need for a modern, open-source, cross-platform GUI for Ruby,
- and FOX fills that need.</para>
- <para>Since its first public release in January 2001, FXRuby has become one
- of the most popular GUI options for Ruby:</para>
- <itemizedlist mark="bullet">
- <listitem><para>In a <ulink url="http://www.rubygarden.org/pollBooth.php?op=results&pollID=4">
- Ruby Garden poll</ulink> held in July 2001, FXRuby edged out Ruby/GTK as the
- most-preferred GUI writing toolkit for Ruby.</para></listitem>
- <listitem><para>In August 2001, FXRuby was added to the Pragmatic Programmers'
- <ulink url="http://rubyinstaller.sourceforge.net">
- Windows installer for Ruby</ulink>.</para></listitem>
- <listitem><para>In October 2001, Lyle gave a presentation on
- <ulink url="http://www.rubyconf.org/2001/talks/lyle/lylefox.htm">
- "Developing GUIs with FOX and Ruby"</ulink> at the first annual Ruby
- Conference in Tampa, Florida.</para></listitem>
- <listitem><para>Although the lack of documentation has been a sore spot for
- some time, several Ruby books (such as the <citetitle pubwork="book">
- Ruby Developer's Guide</citetitle> and <citetitle pubwork="book">The Ruby
- Way</citetitle>) feature FXRuby as a Ruby GUI development option.</para>
- </listitem>
- <listitem><para>FXRuby is used as the GUI for <ulink url="http://freeride.rubyforge.org/wiki/wiki.pl">
- FreeRIDE</ulink> and a number of other Ruby-based projects.</para></listitem>
- </itemizedlist>
- <para>Most recently, work has focused on keeping FXRuby up-to-date with the
- still evolving FOX library while looking for new ways to make Ruby GUI
- development fun. If you have suggestions about where you'd like to
- see things go, feel free to drop me an e-mail.</para>
- <simplesect>
- <title>About this Document</title>
- <para>The contents of this document were written using <ulink url="http://docbook.org/whatis">DocBook</ulink> version 5.0.
- The HTML version of this document uses the CSS stylesheet originally developed for the
- HTML version of the book <ulink url="http://svnbook.red-bean.com/">Version Control with Subversion</ulink>,
- which is licensed under the <ulink url="http://creativecommons.org/licenses/by/2.0/">Creative Commons Attribution License</ulink>.</para>
- </simplesect>
-</preface>
diff --git a/users_guide/images/babelfish.png b/users_guide/images/babelfish.png
deleted file mode 100755
index 78219d3aa032d64ac84e686bc8b9af57b0374847..0000000000000000000000000000000000000000
Binary files a/users_guide/images/babelfish.png and /dev/null differ
diff --git a/users_guide/images/browser.png b/users_guide/images/browser.png
deleted file mode 100755
index 890c7b6d53a925ebc684e3fd815459451788a736..0000000000000000000000000000000000000000
Binary files a/users_guide/images/browser.png and /dev/null differ
diff --git a/users_guide/images/button.png b/users_guide/images/button.png
deleted file mode 100755
index 6f20212c22ae700e280d79e92f241f4c7d68c5d5..0000000000000000000000000000000000000000
Binary files a/users_guide/images/button.png and /dev/null differ
diff --git a/users_guide/images/call-chain-example.dia b/users_guide/images/call-chain-example.dia
deleted file mode 100755
index 481c5cd9d272a06b9eee40bc39ee288ede7b7749..0000000000000000000000000000000000000000
Binary files a/users_guide/images/call-chain-example.dia and /dev/null differ
diff --git a/users_guide/images/call-chain-example.png b/users_guide/images/call-chain-example.png
deleted file mode 100755
index 853e278243a081a80f953ac807f77dd44d1a5839..0000000000000000000000000000000000000000
Binary files a/users_guide/images/call-chain-example.png and /dev/null differ
diff --git a/users_guide/images/colordialog.png b/users_guide/images/colordialog.png
deleted file mode 100755
index 155ca67fe17252a8f306a6979b409979c00cbe56..0000000000000000000000000000000000000000
Binary files a/users_guide/images/colordialog.png and /dev/null differ
diff --git a/users_guide/images/datatarget.png b/users_guide/images/datatarget.png
deleted file mode 100755
index 86b740b9d342a8ccad4dfd2b0071ec1a6e9ff670..0000000000000000000000000000000000000000
Binary files a/users_guide/images/datatarget.png and /dev/null differ
diff --git a/users_guide/images/dialog.png b/users_guide/images/dialog.png
deleted file mode 100755
index 223af0fbfbe93dce0d85991360a26a8a2b8ca315..0000000000000000000000000000000000000000
Binary files a/users_guide/images/dialog.png and /dev/null differ
diff --git a/users_guide/images/dilbert.png b/users_guide/images/dilbert.png
deleted file mode 100755
index 15b6c9868e1d39c86e3622122ffb11637bdba07b..0000000000000000000000000000000000000000
Binary files a/users_guide/images/dilbert.png and /dev/null differ
diff --git a/users_guide/images/dirlist.png b/users_guide/images/dirlist.png
deleted file mode 100755
index 5de021e3ef65298090f8bdb70a843f5b32c886b5..0000000000000000000000000000000000000000
Binary files a/users_guide/images/dirlist.png and /dev/null differ
diff --git a/users_guide/images/dropsite-droprejected.png b/users_guide/images/dropsite-droprejected.png
deleted file mode 100755
index 0086044717c6ec46747f5959bb7726b07c07d817..0000000000000000000000000000000000000000
Binary files a/users_guide/images/dropsite-droprejected.png and /dev/null differ
diff --git a/users_guide/images/foursplit.png b/users_guide/images/foursplit.png
deleted file mode 100755
index 7b4920a5222d12f3763b36bb1c837fd874c0d630..0000000000000000000000000000000000000000
Binary files a/users_guide/images/foursplit.png and /dev/null differ
diff --git a/users_guide/images/gltest.png b/users_guide/images/gltest.png
deleted file mode 100755
index f764d56942546236a097ce00ef7cd9557bfada03..0000000000000000000000000000000000000000
Binary files a/users_guide/images/gltest.png and /dev/null differ
diff --git a/users_guide/images/glviewer.png b/users_guide/images/glviewer.png
deleted file mode 100755
index 675d1f6c013adaecb10ea95f2ccf8f84ce81e117..0000000000000000000000000000000000000000
Binary files a/users_guide/images/glviewer.png and /dev/null differ
diff --git a/users_guide/images/groupbox.png b/users_guide/images/groupbox.png
deleted file mode 100755
index db7a46ef6b25581b065193b8fd71a73abc9f7ae6..0000000000000000000000000000000000000000
Binary files a/users_guide/images/groupbox.png and /dev/null differ
diff --git a/users_guide/images/header.png b/users_guide/images/header.png
deleted file mode 100755
index dab85ccfd44a910af18ce662a422a083efc4561e..0000000000000000000000000000000000000000
Binary files a/users_guide/images/header.png and /dev/null differ
diff --git a/users_guide/images/hello-with-button.png b/users_guide/images/hello-with-button.png
deleted file mode 100755
index 489cc1024ca2e6dc26e78cc20a6555a093e5c985..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello-with-button.png and /dev/null differ
diff --git a/users_guide/images/hello-with-icon-1.png b/users_guide/images/hello-with-icon-1.png
deleted file mode 100755
index f3b70472320ef68785575980b3b4d355643d7cde..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello-with-icon-1.png and /dev/null differ
diff --git a/users_guide/images/hello-with-icon-2.png b/users_guide/images/hello-with-icon-2.png
deleted file mode 100755
index c8a3b05e4bb64bb59877eb21e22cb4fe2f577884..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello-with-icon-2.png and /dev/null differ
diff --git a/users_guide/images/hello-with-icon-3.png b/users_guide/images/hello-with-icon-3.png
deleted file mode 100755
index 8b6f5788d019b1844d4ccef385ff2c763879a669..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello-with-icon-3.png and /dev/null differ
diff --git a/users_guide/images/hello-with-tooltip.png b/users_guide/images/hello-with-tooltip.png
deleted file mode 100755
index 36198e733fb3088ea2416dc89593e07bf6610fd0..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello-with-tooltip.png and /dev/null differ
diff --git a/users_guide/images/hello-without-button.png b/users_guide/images/hello-without-button.png
deleted file mode 100755
index 76fd92a808f9d9f3b4e6b07bec00a3771aeabdc9..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello-without-button.png and /dev/null differ
diff --git a/users_guide/images/hello.png b/users_guide/images/hello.png
deleted file mode 100755
index ac85aa1e01de1978f692e53e33dda4f489b4e937..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello.png and /dev/null differ
diff --git a/users_guide/images/hello2.png b/users_guide/images/hello2.png
deleted file mode 100755
index 998d158902a869717cded8f6cebfed626488e2cb..0000000000000000000000000000000000000000
Binary files a/users_guide/images/hello2.png and /dev/null differ
diff --git a/users_guide/images/iconlist-bigicons.png b/users_guide/images/iconlist-bigicons.png
deleted file mode 100755
index f0a448bb2a243f31ce5a578e5389e72778f52c5f..0000000000000000000000000000000000000000
Binary files a/users_guide/images/iconlist-bigicons.png and /dev/null differ
diff --git a/users_guide/images/iconlist-details.png b/users_guide/images/iconlist-details.png
deleted file mode 100755
index 3090dff243e8079a3994a56409e89bf421e98b8f..0000000000000000000000000000000000000000
Binary files a/users_guide/images/iconlist-details.png and /dev/null differ
diff --git a/users_guide/images/image.png b/users_guide/images/image.png
deleted file mode 100755
index ec46c73cadca390188cb5f7e317f89c111ef83a8..0000000000000000000000000000000000000000
Binary files a/users_guide/images/image.png and /dev/null differ
diff --git a/users_guide/images/imageviewer.png b/users_guide/images/imageviewer.png
deleted file mode 100755
index f608faa6d9cdec8f3c3612616c7e2c61ce2fe78f..0000000000000000000000000000000000000000
Binary files a/users_guide/images/imageviewer.png and /dev/null differ
diff --git a/users_guide/images/inheritance.dia b/users_guide/images/inheritance.dia
deleted file mode 100755
index 3687178bf71f9b14077ad7633df47e3b3ee3e18f..0000000000000000000000000000000000000000
Binary files a/users_guide/images/inheritance.dia and /dev/null differ
diff --git a/users_guide/images/inheritance.png b/users_guide/images/inheritance.png
deleted file mode 100755
index df712fb78b5c3e216eb7b07d4d7828131dbec717..0000000000000000000000000000000000000000
Binary files a/users_guide/images/inheritance.png and /dev/null differ
diff --git a/users_guide/images/mditest.png b/users_guide/images/mditest.png
deleted file mode 100755
index c8b9ad78562b081e04f416397086c91675de88e3..0000000000000000000000000000000000000000
Binary files a/users_guide/images/mditest.png and /dev/null differ
diff --git a/users_guide/images/raabrowser.png b/users_guide/images/raabrowser.png
deleted file mode 100755
index 6f83e6fe6ce018780bca57db1b65cfdb02fae212..0000000000000000000000000000000000000000
Binary files a/users_guide/images/raabrowser.png and /dev/null differ
diff --git a/users_guide/images/scribble.png b/users_guide/images/scribble.png
deleted file mode 100755
index 072f39b058bbae2c12b7543e256a45c1fbee0a45..0000000000000000000000000000000000000000
Binary files a/users_guide/images/scribble.png and /dev/null differ
diff --git a/users_guide/images/shutter.png b/users_guide/images/shutter.png
deleted file mode 100755
index bb810b044db01a10ffa5a1570fda732df673d4ca..0000000000000000000000000000000000000000
Binary files a/users_guide/images/shutter.png and /dev/null differ
diff --git a/users_guide/images/splitter.png b/users_guide/images/splitter.png
deleted file mode 100755
index 522ee156515658f1da05423f78dfdc2df071386f..0000000000000000000000000000000000000000
Binary files a/users_guide/images/splitter.png and /dev/null differ
diff --git a/users_guide/images/tabbook.png b/users_guide/images/tabbook.png
deleted file mode 100755
index 99dd2e31f64ba6ab7b5f162ad6934e26e88309a5..0000000000000000000000000000000000000000
Binary files a/users_guide/images/tabbook.png and /dev/null differ
diff --git a/users_guide/images/table.png b/users_guide/images/table.png
deleted file mode 100755
index 11705e0ccab7dee694cfa71dcfdd0e47d6c5b86b..0000000000000000000000000000000000000000
Binary files a/users_guide/images/table.png and /dev/null differ
diff --git a/users_guide/images/tutorial1.png b/users_guide/images/tutorial1.png
deleted file mode 100755
index 96e84d14a9f30ac974e1a74b27adcd145916ccee..0000000000000000000000000000000000000000
Binary files a/users_guide/images/tutorial1.png and /dev/null differ
diff --git a/users_guide/implementation.xml b/users_guide/implementation.xml
deleted file mode 100755
index d3d1ea0dc1fc0e608e94fa7cccf8799ba12a3689..0000000000000000000000000000000000000000
--- a/users_guide/implementation.xml
+++ /dev/null
@@ -1,117 +0,0 @@
-<appendix id="implementation">
- <title>Implementation</title>
- <section>
- <title>Code Generation</title>
- <para>The development and maintenance of FXRuby would be almost impossible
- without the help of Dave Beazley's excellent
- <ulink url="http://www.swig.org">SWIG</ulink>. The complete set of SWIG
- interface files used to generate FXRuby is included in the standard
- FXRuby source code distribution, and if you'd like you can even
- regenerate the FXRuby sources using SWIG. Because FXRuby relies on
- functionality in a specific version of SWIG (version 1.3.22), you will need
- to <ulink url="http://sourceforge.net/project/showfiles.php?group_id=1645&package_id=1608&release_id=265569">download and install SWIG-1.3.22</ulink>.
- <emphasis role="strong">Note that more recent versions of SWIG will not
- work</emphasis> (this will be corrected in the future).</para>
- <para>To regenerate the FXRuby sources from the SWIG interface files,
- change directories to the <filename class="directory">swig-interfaces
- </filename> subdirectory of the FXRuby source tree and type <command>make
- </command>. Any time that you make a change to the SWIG interface files,
- you'll need to repeat this step to update the C++ sources.</para>
- </section>
- <section>
- <title>Object Life Cycles and Garbage Collection</title>
- <para>One of the more difficult issues to deal with was understanding
- the "life cycle" of FOX objects (that is, the actual C++ objects) and
- their relationship to the associated Ruby instances. Understanding this
- relationship is critical when dealing with Ruby's garbage collector,
- to ensure that objects are disposed of at the right time.</para>
- <para>For our purposes, we can divide the set of all objects in an FXRuby
- program into two groups, those objects that Ruby "owns" and those that
- it doesn't. The first group (the "owned" objects) includes those that you
- create explicitly from Ruby code. This is usually done by calling a class'
- <methodname>new</methodname> method, e.g.</para>
- <programlisting format="linespecific">myIcon = FXPNGIcon.new(myApp, File.open("icon.png", "rb").read)
-myButton = FXButton.new(parentWin, "Hello, World!", myIcon)</programlisting>
- <para>It's important to keep in mind that when you create an object like
- this you're not only creating the Ruby instance part (i.e. whatever
- overhead is usually associated with a Ruby instance) but a C++ FOX object
- as well. Because we created these objects, we would reasonably expect them
- to be destroyed when they are garbage-collected so that our programs
- don't leak memory.</para>
- <para>The other group of objects (those not owned by Ruby) are those
- returned from most class instance methods; they are references to already-
- existing objects. For example, <methodname>FXStatusBar#statusline
- </methodname> returns a reference to the status bar's enclosed status line
- instance.</para>
- <section>
- <title>GL Objects</title>
- <para>A C++ <classname>FXGLGroup</classname> object owns all of the <classname>FXGLObject</classname> objects it "contains". In other words, when that <classname>FXGLGroup</classname> object is destroyed, it will also destroy all of the <classname>FXGLObject</classname> objects for which it holds pointers.</para>
- <para>In order to keep track of <emphasis>which</emphasis> GL objects have been added to an <classname>FXGLGroup</classname>, all of the FXRuby C++ classes derived from <classname>FXGLObject</classname> have a boolean member variable <structfield>owned</structfield> that indicates whether this object is "owned" or not. Until an <classname>FXGLObject</classname> object is added to a group, this member variable should stay false.</para>
- </section>
- </section>
- <section>
- <title>Virtual Functions</title>
- <para>
-One of the design requirements for FXRuby was to ensure that any
-virtual function call made on a FOX object (from the C++ library
-layer) is routed to the proper Ruby instance method, even if that
-method has been overridden in a derived class.
-</para>
-<para>
-For example, many of the FXRuby example programs are structured with a
-main window class that subclasses <classname>FXMainWindow</classname>
-and then overrides its <methodname>create</methodname> instance method:</para>
-<programlisting format="linespecific">class MyMainWindow < Fox::FXMainWindow
- # overrides the base class version, FXMainWindow#create
- def create
- end
-end</programlisting>
-<para>This <methodname>create</methodname> method isn't called directly from Ruby code, however; it's called as a side effect of calling <methodname>FXApp#create</methodname>. Inside the C++ FOX library, the <methodname>FXApp::create()</methodname> member function recursively calls <methodname>create()</methodname> on all of the application's windows and eventually calls the virtual <methodname>FXMainWindow::create()</methodname> member function as well:
-</para>
-<screenshot>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/call-chain-example.png" format="PNG" align="center"/>
- </imageobject>
- </mediaobject>
-</screenshot>
-<para>
-To ensure that our main window's overridden <methodname>create
-</methodname> method is invoked instead of the base class implementation,
-we need some special machinery in place.
-</para>
-<para>
-For every C++ class that declares virtual member functions, we derive
-a new C++ class that overrides all of those virtual functions with special
-stubs that know how to make method calls on Ruby instances. The naming
-convention for these classes is that the "FX" prefix is replaced with
-"FXRb"; for example, our <classname>FXRbButton</classname> C++ class is
-derived from FOX's <classname>FXButton</classname>:
-</para>
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/inheritance.png" format="PNG" align="center"/>
- </imageobject>
- </mediaobject>
- </screenshot>
-<para>
-Although the implementation of these "stubs" varies from function to function, the
-basic requirements are always the same:
-<orderedlist>
- <listitem><para>Look up the Ruby object associated with this C++ object.</para></listitem>
- <listitem><para>Convert each of the function's arguments to their Ruby
- representation. For example, arguments of type <type>FXint</type> are
- converted to Ruby <classname>Fixnum</classname>s.</para></listitem>
- <listitem><para>Call the Ruby object's method, using the <function>
- rb_funcall()</function> function from Ruby's C API, and capture its
- result (which is itself a Ruby object).</para></listitem>
- <listitem><para>Convert the method call's result back to the virtual
- function's C++ return type, and then return that result from the C++
- function. For example, if the C++ function has a <type> FXbool</type>
- return type, we would expect the corresponding Ruby method to return
- either <constant>Qtrue</constant> or <constant>Qfalse</constant>.</para></listitem>
-</orderedlist>
-</para>
- </section>
-</appendix>
diff --git a/users_guide/infosources.xml b/users_guide/infosources.xml
deleted file mode 100755
index 6fb8ec15247e85b86f3a1be0d7961ee3674066ff..0000000000000000000000000000000000000000
--- a/users_guide/infosources.xml
+++ /dev/null
@@ -1,95 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="infosources">
- <title>Other Sources of Information</title>
-
- <simplesect>
- <title>Books</title>
-
- <para>There are no books entirely dedicated to programming with FXRuby,
- but the following Ruby books contain sections on FXRuby:</para>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para><citetitle pubwork="book">The Ruby Way</citetitle>, by Hal
- Fulton.</para>
- </listitem>
-
- <listitem>
- <para><citetitle pubwork="book">Ruby Developer's Guide</citetitle>,
- by Michael Neumann, Robert Feldt and Lyle Johnson.</para>
- </listitem>
- </itemizedlist>
- </simplesect>
-
- <simplesect>
- <title>Reference Documentation</title>
-
- <para>The current <ulink url="http://www.fxruby.org/doc/api">FXRuby API
- Reference Documentation</ulink> is a work in progress, but serves as a
- pretty good guide to the available methods and attributes for the
- different classes. The regular <ulink
- url="http://www.fox-toolkit.org">FOX</ulink> API
- Reference Documentation can be used as a fallback source of
- information, although it is intended for users of the C++ library.</para>
- </simplesect>
-
- <simplesect>
- <title>Web Sites</title>
-
- <para>The <ulink url="http://www.fox-toolkit.com">FOX toolkit home page</ulink>
- is still one of the best places to find information about GUI programming
- with FOX. This is the site maintained by Jeroen van der Zijp, the creator
- and primary developer of FOX, and serves as the official download site for
- the FOX library. In addition to a number of articles about programming
- with FOX, you'll find links to projects using FOX. A newer web site,
- the <ulink url="http://www.fox-toolkit.net">FOX Community Wiki</ulink>, is
- maintained by Sander Jansen. Like most Wiki sites, the information here is
- a little more scattered but tends to be more up-to-date than some
- information on the main FOX site. This site includes a number of tutorial
- articles, as well as "cookbook" and "how-to" pages on many
- topics.</para>
- </simplesect>
-
- <simplesect>
- <title>Mailing Lists</title>
-
- <para>One or more of the following mailing lists may be of interest:</para>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>The fxruby-announce@rubyforge.org mailing list is a very
- low-volume list for FXRuby-related announcements. To subscribe to this
- list, follow the instructions at <ulink
- url="http://rubyforge.org/mailman/listinfo/fxruby-announce">http://rubyforge.org/mailman/listinfo/fxruby-announce</ulink></para>
- </listitem>
-
- <listitem>
- <para>The fxruby-users@rubyforge.org mailing list is a
- higher-volume list for FXRuby-related discussions. To subscribe to
- this list, follow the instructions at <ulink
- url="http://rubyforge.org/mailman/listinfo/fxruby-users">http://rubyforge.org/mailman/listinfo/fxruby-users</ulink></para>
- </listitem>
-
- <listitem>
- <para>The foxgui-announce@lists.sourceforge.net mailing list is a very
- low-volume list for FOX-related announcements. To subscribe to this
- list, follow the instructions at <ulink
- url="http://lists.sourceforge.net/lists/listinfo/foxgui-announce">http://lists.sourceforge.net/lists/listinfo/foxgui-announce</ulink></para>
- </listitem>
-
- <listitem>
- <para>The foxgui-users@lists.sourceforge.net mailing list is a
- higher-volume list for FOX-related discussions. To subscribe to this
- list, follow the instructions at <ulink
- url="http://lists.sourceforge.net/lists/listinfo/foxgui-users">http://lists.sourceforge.net/lists/listinfo/foxgui-users</ulink></para>
- </listitem>
-
- <listitem>
- <para>The Ruby-Talk mailing list (or its mirror, the
- comp.lang.ruby newsgroup) is a high-volume list for Ruby-related
- discussions. To subscribe to this list, follow the instructions at
- <ulink url="http://www.ruby-lang.org/en/community/mailing-lists/">http://www.ruby-lang.org/en/community/mailing-lists/</ulink></para>
- </listitem>
- </itemizedlist>
- </simplesect>
-</chapter>
diff --git a/users_guide/layout.xml b/users_guide/layout.xml
deleted file mode 100755
index 44e4273eb818814871fc1da2b8597ef5a09157f7..0000000000000000000000000000000000000000
--- a/users_guide/layout.xml
+++ /dev/null
@@ -1,31 +0,0 @@
-<chapter id="layout">
- <title>Layout Managers</title>
- <para>FOX uses special widgets known as <emphasis>layout managers</emphasis> to arrange the widgets in a user interface.</para>
- <section>
- <title>FXPacker</title>
- <para>All widgets derived from <classname>FXFrame</classname> have some amount of internal padding along their sides. The default padding along each side is 2 pixels, but you can specify the amount of padding when the widget is constructed via the <arg>pl</arg>, <arg>pr</arg>, <arg>pt</arg> and <arg>pb</arg> arguments to the widget's constructor. For example, to construct an <classname>FXLabel</classname> widget with 5 pixels padding at its left and right sides, you'd do:</para>
- <programlisting format="linespecific">aLabel = FXLabel.new(parent, "Label", nil, LABEL_NORMAL, 0, 0, 0, 0, 5, 5)</programlisting>
- <para>It of course may be easier to set the padding in a code block instead, e.g.</para>
- <programlisting format="linespecific"><![CDATA[aLabel = FXLabel.new(parent, "Label") do
- self.padLeft = 5
- self.padRight = 5
-end]]></programlisting>
- </section>
- <section>
- <title>FXHorizontalFrame and FXVerticalFrame</title>
- <para>The <classname>FXHorizontalFrame</classname> and <classname>FXVerticalFrame</classname> layout managers aren't as powerful as some of the other layout managers, but they are very easy to use and you'll probably find them adequate for a lot of layout needs. As you might guess from their names, the <classname>FXHorizontalFrame</classname> layout manager lays out its children horizontally and the <classname>FXVerticalFrame</classname> layout manager lays out its children from top to bottom.</para>
- </section>
- <section>
- <title>FXMatrix</title>
- <para>The <classname>FXMatrix</classname> layout manager lays out its children in rows and columns.</para>
- </section>
- <section>
- <title>FXSplitter and FX4Splitter</title>
- <para>The <classname>FXSplitter</classname> layout manager is used to display a pair of windows side-by-side. The size of the individual windows' contents can be easily resized by the user.</para>
- <para>A splitter is either a "horizontal" splitter, meaning that the container is split left-to-right, or a "vertical" splitter, meaning that the container is split top-to-bottom. By default, an <classname>FXSplitter</classname> is created with a horizontal split, but you can change that by specifying the <constant>SPLITTER_VERTICAL</constant> option in the initialization options:</para>
- <programlisting format="linespecific">aSplitter = FXSplitter.new(parent, SPLITTER_VERTICAL)</programlisting>
- <para>Although it will probably make for a confusing user interface, you can also change this setting at any time by modifying the <structfield>splitterStyle</structfield> attribute, i.e.</para>
- <programlisting format="linespecific">aSplitter.splitterStyle = SPLITTER_HORIZONTAL</programlisting>
- <para>A splitter should contain exactly two child widgets, one for the "left" pane and one for the "right" pane (assuming it's a horizontal splitter).</para>
- </section>
-</chapter>
diff --git a/users_guide/library.xml b/users_guide/library.xml
deleted file mode 100755
index 72b547691173b500fd56b9da0a18287230bc1828..0000000000000000000000000000000000000000
--- a/users_guide/library.xml
+++ /dev/null
@@ -1,61 +0,0 @@
-<appendix id="library">
- <title>The FXRuby Standard Library</title>
- <para>While the majority of FXRuby is in fact implemented by an extension module, some parts are provided instead by "pure Ruby" code. This section describes the classes and modules available in the FXRuby standard library.</para>
- <simplesect>
- <title>Undoable Commands</title>
- <para>The <filename>fox16/undolist.rb</filename> file provides the <classname>FXCommand</classname> and <classname>FXUndoList</classname> classes. These serve the same purpose as the <classname>FXCommand</classname> and <classname>FXUndoList</classname> classes from the standard FOX distribution, but they're implemented entirely in Ruby.</para>
- <para>For a complete description of these classes and how to use them, see the RD documentation in <filename>fox16/undolist.rb</filename>.</para>
- </simplesect>
- <simplesect>
- <title>Aliases</title>
- <para>The <filename>fox16/aliases.rb</filename> implements most of the accessor-style aliases for methods. This file is loaded automatically when you <programlisting format="linespecific">require 'fox16'</programlisting> and so you should never need to load it directly.</para>
- </simplesect>
- <simplesect>
- <title>Color Names</title>
- <para>The <filename>fox16/colors.rb</filename> file, contributed by Jeff
- Heard, provides a bunch of predefined color values (based on the standard
- X11 color names). You can use these color constants anywhere that FOX
- expects an RGB color value, e.g.</para>
- <programlisting format="linespecific">dc = FXDCWindow.new(drawable, ev)
-dc.foreground = FXColor::MistyRose # instead of FXRGB(255, 228, 225)
-dc.background = FXColor::MidnightBlue # instead of FXRGB( 25, 25, 112)</programlisting>
- </simplesect>
- <simplesect>
- <title>OpenGL Shapes</title>
- <para>The <filename>fox16/glshapes.rb</filename> library provides Ruby
- implementations of a number of basic 3-D shapes (all derived from the
- built-in <classname>FXGLShape</classname> class) that can be used with
- the <classname>FXGLViewer</classname>. Several of these shapes are used
- in the <filename>glviewer.rb</filename> example program. These shapes
- were originally implemented in C++ and wrapped using SWIG, but they are
- straightforward enough to implement in Ruby so they were moved out to
- this library instead.</para>
- </simplesect>
- <simplesect>
- <title>Iterators</title>
- <para>The <filename>fox16/iterators.rb</filename> library just adds an
- <methodname>each</methodname> instance method for the <classname>
- FXComboBox</classname>, <classname>FXGLGroup</classname>, <classname>
- FXHeader</classname>, <classname>FXIconList</classname>, <classname>
- FXList</classname>, <classname>FXListBox</classname>, <classname>
- FXTable</classname>, <classname>FXTreeItem</classname>, <classname>
- FXTreeList</classname> and <classname>FXTreeListBox</classname> classes,
- so that you can iterate over their members in a Ruby-friendly way. It
- also mixes the <classname>Enumerable</classname> module into each of
- these classes.</para>
- </simplesect>
- <simplesect>
- <title>Key Codes</title>
- <para>The <filename>fox16/keys.rb</filename> library file defines all of the
- key codes (e.g. <constant>KEY_space</constant>) that might show up in the
- code field of an <classname>FXEvent</classname> instance. This file is
- loaded automatically when you
- <programlisting format="linespecific">require 'fox16'</programlisting> and
- so you should never need to load it
- directly.</para>
- </simplesect>
- <simplesect>
- <title>Calendar Widget</title>
- <para>The <filename>fox16/calendar.rb</filename> library file provides the <classname>FXCalendar</classname> widget, contributed by David Naseby.</para>
- </simplesect>
-</appendix>
diff --git a/users_guide/maintainer.xml b/users_guide/maintainer.xml
deleted file mode 100755
index f47d7aea8c4159d3e5e4c9d27632580e989f9b49..0000000000000000000000000000000000000000
--- a/users_guide/maintainer.xml
+++ /dev/null
@@ -1,24 +0,0 @@
-<chapter id="maintainer">
- <title>Maintainer's Checklists</title>
- <simplesect>
- <title>Updating to a new version of FOX</title>
- <itemizedlist mark="bullet">
- <listitem><para>Download, build and install the latest version of the FOX library.</para></listitem>
- <listitem><para>Change to the <filename class=directory>fox-includes</filename> subdirectory of the FXRuby code and modify the <filename>diffs.py</filename> script so that the path1 variable contains the path name for the include files.</para></listitem>
- <listitem><para>Run the <filename>diffs.py</filename> and redirect its output to a file. This generates a cleaned-up listing of the differences between the FOX include files currently included with FXRuby and those from the latest FOX distribution, including things like lists of include files added to and removed from the distribution.</para></listitem>
- <listitem><para>If any new include files have been added to FOX, copy those over to FXRuby's <filename class=directory>fox-includes</filename> subdirectory and add them to the Subversion repository using svn add.</para></listitem>
- </itemizedlist>
- </simplesect>
- <simplesect>
- <title>Integrating a new FOX class into FXRuby</title>
- <listitem><para>Create a new SWIG interface file for this class in the <filename class=directory>swig-interfaces</filename> subdirectory. It's easiest to start by just copying over the corresponding FOX include file (e.g. copy <filename>fox-includes/FXColorWheel.h</filename> to <filename>swig-interfaces/FXColorWheel.i</filename>.</para></listitem>
- <listitem><para>Replace all of the FOX copyright information at the top of the file with the FXRuby copyright information (from any of the other SWIG interface files).</para></listitem>
- <listitem><para>Remove the #ifdef preprocessor protections, the FXDECLARE macro, the FXAPI macro, and any private sections of the class declaration.</para></listitem>
- <listitem><para>Remove the declarations of any virtual function overrides (e.g. <methodname>create</methodname> or <methodname>getDefaultWidth</methodname>) since they aren't needed.</para></listitem>
- <listitem><para>Add the declaration for the class' destructor, if it's not already there. This is a signal to SWIG to generate code that destroys the C++ object when it's garbage-collected; if it's not there, you may experience memory leaks.</para></listitem>
- <listitem><para>Add the required SWIG %rename directives to the <filename>swig-interfaces/renames.i</filename> file. For each class, you'll have two %rename directives; one to rename the original class name (e.g. <classname>FXPicker</classname>) to a mangled name (<classname>FX_Picker</classname>) and another to rename the FXRuby subclass (<classname>FXRbPicker</classname>) to the public name (<classname>FXPicker</classname>).</para></listitem>
- <listitem><para>Add a new header file to the <filename class=directory>ext/fox/include</filename> directory for the new FXRuby subclass (e.g. <filename>FXRbPicker.h</filename>.</para></listitem>
- <listitem><para>Add any appropriate aliases for this class' method names to the <filename>lib/fox/aliases.rb</filename> file.</para></listitem>
- </itemizedlist>
- </simplesect>
-</chapter>
diff --git a/users_guide/opengl.xml b/users_guide/opengl.xml
deleted file mode 100755
index e6f10293d2595eefeda8e2fe089786c89264c88c..0000000000000000000000000000000000000000
--- a/users_guide/opengl.xml
+++ /dev/null
@@ -1,151 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<appendix id="opengl">
- <title>Using OpenGL with FXRuby</title>
-
- <abstract>
- <para>FOX provides extensive support for OpenGL through its
- <classname>FXGLCanvas</classname> and <classname>FXGLViewer</classname>
- widgets, and FXRuby in turn provides interfaces to those classes. By
- combining FXRuby with the OpenGL interface for Ruby (described below) you
- can develop very powerful 3-D graphics applications. This chapter gives
- you the information you'll need to get started.</para>
- </abstract>
-
- <simplesect>
- <title>What is OpenGL?</title>
-
- <para>OpenGL is a platform-independent API for 2D and 3D graphics. The
- home page is <ulink
- url="http://www.opengl.org">http://www.opengl.org</ulink>. Because it's a
- fairly open standard, highly optimized OpenGL drivers are available for
- most operating systems (including Windows and Linux).</para>
- </simplesect>
-
- <simplesect>
- <title>OpenGL Extensions for Ruby</title>
-
- <para>This extension module, developed by Yoshiyuki Kusano, provides
- interfaces to not only the basic OpenGL API, but also the GLU and GLUT
- APIs. As of this writing, the currently released version is 0.32d and is
- available for download from <ulink
- url="http://www2.giganet.net/~yoshi/rbogl-0.32b.tgz">http://www2.giganet.net/~yoshi/rbogl-0.32d.tgz</ulink>.
- Be sure to check the <ulink
- url="http://www.ruby-lang.org/en/raa.html">Ruby Application
- Archive</ulink> for the latest version of this extension as it is still
- under development.</para>
-
- <para>Once you've downloaded the tarball, you should extract its contents
- to the working directory of your choice by typing:</para>
-
- <screen>$ <command>tar xzf rbogl-0.32d.tgz</command></screen>
-
- <para>After executing this command you should have a new <filename
- class="directory">opengl</filename> (<emphasis>not</emphasis> <filename
- class="directory">rbogl-0.32b</filename>) subdirectory. Change to this
- directory and then type:</para>
-
- <screen>$ <command>ruby extconf.rb</command></screen>
-
- <para>This should create a <filename>Makefile</filename> configured
- appropriately for your local Ruby installation. To now build the OpenGL
- module, type:</para>
-
- <screen>$ <command>make</command></screen>
-
- <para>You can safely ignore the warning(s) about
- <methodname>glut_KeyboardFunc</methodname> when it's compiling
- <filename>glut.c</filename>. Well, I ignore them and it hasn't hurt me yet
- ;) Assuming you get an otherwise clean build, install the OpenGL
- extensions by typing:</para>
-
- <screen>$ <command>make site-install</command></screen>
-
- <para>Please note that I'm not the maintainer of this particular Ruby
- extension, so I can't really accept bug fixes for it. But if you're having
- trouble integrating Ruby/OpenGL with FXRuby, let me know and we'll see
- what we can do.</para>
- </simplesect>
-
- <simplesect>
- <title>The FXGLVisual Class</title>
-
- <para>An <classname>FXGLVisual</classname> object describes the
- capabilities of an <classname>FXGLCanvas</classname> or
- <classname>FXGLViewer</classname> window. Typically, an X server supports
- many different visuals with varying capabilities, but the ones with
- greater capabilities require more resources than those with fewer
- capbilities. To construct an <classname>FXGLVisual</classname> object,
- just call <methodname>FXGLVisual.new</methodname>:</para>
-
- <programlisting format="linespecific">aVisual = FXGLVisual.new(theApp, VISUAL_DOUBLEBUFFER)</programlisting>
-
- <para>The first argument to <methodname>FXGLVisual.new</methodname> is a
- reference to the application object. The second argument is a set of
- options indicating the <emphasis>requested</emphasis> capabilities for the
- visual. If one or more of the requested capabilities aren't available, FOX
- will try to gracefully degrade to a working GL visual; but if you're
- counting on a specific capability, be sure to check the returned visual to
- see if it actually supports that capability. For example, say you request
- a visual with double-buffering and stereographic capabilities:</para>
-
- <programlisting format="linespecific">anotherVisual = FXGLVisual.new(theApp, VISUAL_DOUBLEBUFFER | VISUAL_STEREO)</programlisting>
-
- <para>Double-buffering is pretty commonplace these days, but stereo may
- not be available on the system. We can check to see whether the visual we
- got supports these capabilities by calling the
- <methodname>FXGLVisual#doubleBuffered?</methodname> and
- <methodname>FXGLVisual#stereo?</methodname> methods:</para>
-
- <programlisting format="linespecific">anotherVisual = FXGLVisual.new(theApp, VISUAL_DOUBLEBUFFER | VISUAL_STEREO)
-if anotherVisual.doubleBuffered?
- puts "It's double-buffered."
-else
- puts "It's single-buffered."
-end
-if anotherVisual.stereo?
- puts "It's stereo."
-else
- puts "It isn't stereo."
-end</programlisting>
-
- <para>Some <classname>FXGLVisual</classname> object must be associated
- with every <classname>FXGLCanvas</classname> or
- <classname>FXGLViewer</classname> window, but you don't need to have a
- separate <classname>FXGLVisual</classname> object for each window. For
- most applications, you can just construct a single
- <classname>FXGLVisual</classname> object that's shared among all the
- OpenGL windows.</para>
- </simplesect>
-
- <simplesect>
- <title>The FXGLCanvas Class</title>
-
- <para>The <classname>FXGLCanvas</classname> widget provides a very simple
- OpenGL-capable window with minimal functionality. To construct an
- <classname>FXGLCanvas</classname>, call
- <methodname>FXGLCanvas.new</methodname>:</para>
-
- <programlisting format="linespecific">glCanvas = FXGLCanvas.new(parent, vis)</programlisting>
-
- <para>The first argument to <methodname>FXGLCanvas.new</methodname> is the
- parent (container) widget and the second argument is the
- <classname>FXGLVisual</classname> that should be used for this
- window.</para>
- </simplesect>
-
- <simplesect>
- <title>OpenGL objects and the FXGLViewer</title>
-
- <para>The <classname>FXGLViewer</classname> widget provides a higher-level
- OpenGL-capable window with a lot of built-in functionality. To construct
- an <classname>FXGLViewer</classname>, call
- <methodname>FXGLViewer.new</methodname>:</para>
-
- <programlisting format="linespecific">glViewer = FXGLViewer.new(parent, vis)</programlisting>
-
- <para>The first argument to <methodname>FXGLViewer.new</methodname> is the
- parent (container) widget and the second argument is the
- <classname>FXGLVisual</classname> that should be used for this
- window.</para>
- </simplesect>
-</appendix>
\ No newline at end of file
diff --git a/users_guide/preface.xml b/users_guide/preface.xml
deleted file mode 100755
index 7f65d2c0437f860aaa07c0b2afa51c3d3450cd64..0000000000000000000000000000000000000000
--- a/users_guide/preface.xml
+++ /dev/null
@@ -1,7 +0,0 @@
-<preface><title>Preface</title>
- <para>
- The purpose of this tutorial is to introduce you to some of the
- fundamental concepts in FXRuby. It assumes that you already have
- a working FXRuby installation in place.
- </para>
-</preface>
diff --git a/users_guide/scintilla.xml b/users_guide/scintilla.xml
deleted file mode 100755
index 2b515056d11bf6164f0dd2e9bdd26aeb00dd7e7e..0000000000000000000000000000000000000000
--- a/users_guide/scintilla.xml
+++ /dev/null
@@ -1,79 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<appendix id="scintilla">
- <title>Using Scintilla with FXRuby</title>
-
- <simplesect>
- <title>What is Scintilla?</title>
-
- <para><ulink url="http://www.scintilla.org">Scintilla</ulink> is a free
- source code editing component developed by Neil Hodgson for the Win32 and
- GTK+ platforms.</para>
- </simplesect>
-
- <simplesect>
- <title>What is FXScintilla?</title>
-
- <para><ulink
- url="http://savannah.gnu.org/projects/fxscintilla">FXScintilla </ulink> is
- a FOX widget that wraps around the Scintilla component, or, if you wish,
- the FOX "port" of Scintilla. Until recently it was developed by Gilles Filippini,
- and as of this writing the latest release is available for download from
- <ulink
- url="http://download.savannah.gnu.org/releases/fxscintilla/fxscintilla-1.71.tar.gz">http://download.savannah.gnu.org/releases/fxscintilla/fxscintilla-1.71.tar.gz</ulink>.</para>
- </simplesect>
-
- <simplesect>
- <title>Compiling FXScintilla</title>
-
- <para>The FXScintilla distribution contains everything you need to build
- the FXScintilla widget and begin using it in your C++-based FOX
- applications. That is to say, you do not have to separately download the
- Scintilla source code from the Scintilla home page. When you unpack the
- FXScintilla tarball, you should get a new <filename class="directory">
- fxscintilla-1.71</filename> directory containing the source code for the
- FOX port of the Scintilla widget.</para>
-
- <para>As of the 1.46 release of FXScintilla, the build process has been
- "autoconfiscated" and should seem very familiar to you if you've built
- other open-source software (like FOX) from the source code. The
- <filename>INSTALL</filename> file in the top-level directory should
- provide enough instruction for you to build and install FXScintilla for
- either Unix or Microsoft Windows.</para>
- </simplesect>
-
- <simplesect>
- <title>Enabling FXScintilla Support in FXRuby</title>
-
- <para>The next step is to build a version of FXRuby (from its source code)
- with the optional FXScintilla support enabled. If you're working on a Unix
- or Linux system and have installed FXScintilla in one of the standard
- installation directories (e.g. under <filename
- class="directory">/usr/include</filename> or <filename
- class="directory">/usr/local/include</filename>), the regular FXRuby build
- process should automatically detect it and enable FXScintilla
- support.</para>
-
- <para>If you have installed FXScintilla in some non-standard place, or if
- you're building the code on Microsoft Windows, you will need to specify a
- few additional configuration options at the beginning.</para>
-
- <para>You can configure the build on Unix or Linux systems by
- typing:</para>
-
- <screen>
-$ <command>sudo gem install fxruby-1.6.7.gem --force -- --with-fxscintilla-include=/usr/local/include/fxscintilla --with-fxscintilla-lib=/usr/local/lib</command>
-</screen>
-
- <para>or, when compiling with Microsoft Visual C++, by typing:</para>
-
- <screen>
-C:\> <command>gem install fxruby-1.6.7.gem --force -- --with-fox-include=C:\fox-1.6.25\include --with-fox-lib=C:\fox-1.6.25\lib --with-fxscintilla-include=C:\fxscintilla-1.71\include --with-fxscintilla-lib=C:\fxscintilla-1.71\lib</command>
-</screen>
-
- <para>Past this point, the build and installation process for either
- platform should be the same as for standard builds. To test your new
- FXScintilla-enabled build of FXRuby, try running the
- <filename>scintilla-test.rb</filename> example program in the FXRuby
- <filename class="directory">examples</filename> subdirectory.</para>
- </simplesect>
-</appendix>
diff --git a/users_guide/style.css b/users_guide/style.css
deleted file mode 100644
index a584e5d2ff6593c575ec5a539966a0d28f7f790f..0000000000000000000000000000000000000000
--- a/users_guide/style.css
+++ /dev/null
@@ -1,247 +0,0 @@
-/************************************************************************/
-/* Custom style-sheet stuffs for the Subversion book in HTML form. */
-/************************************************************************/
-
-/*
- * Copyright (c) 2003-2007
- * Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato.
- *
- * This work is licensed under the Creative Commons Attribution License.
- * To view a copy of this license, visit
- * http://creativecommons.org/licenses/by/2.0/ or send a letter to
- * Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305,
- * USA.
- */
-
-body
-{
- background: white;
- margin: 0.5in;
- font-family: arial,helvetica,sans-serif;
-}
-
-p, li, ul, ol, dd, dt
-{
- font-style: normal;
- font-weight: normal;
- color: black;
-}
-
-tt, pre
-{
- font-family: courier new,courier,fixed;
-}
-
-a
-{
- color: blue;
- text-decoration: underline;
-}
-
-a:hover
-{
- background: rgb(75%,75%,100%);
- color: blue;
- text-decoration: underline;
-}
-
-a:visited
-{
- color: purple;
- text-decoration: underline;
-}
-
-img
-{
- border: none;
-}
-
-h1.title
-{
- font-size: 250%;
- font-style: normal;
- font-weight: bold;
- color: black;
-}
-
-h2.subtitle
-{
- font-size: 150%;
- font-style: italic;
- color: black;
-}
-
-h2.title
-{
- font-size: 150%;
- font-style: normal;
- font-weight: bold;
- color: black;
-}
-
-h3.title
-{
- font-size: 125%;
- font-style: normal;
- font-weight: bold;
- color: black;
-}
-
-h4.title
-{
- font-size: 100%;
- font-style: normal;
- font-weight: bold;
- color: black;
-}
-
-.toc b
-{
- font-size: 125%;
- font-style: normal;
- font-weight: bold;
- color: black;
-}
-
-.command, .screen, .programlisting, .structname
-{
- font-family: courier new,courier,fixed;
- font-style: normal;
- font-weight: normal;
-}
-
-.filename
-{
- font-family: arial,helvetica,sans-serif;
- font-style: italic;
-}
-
-.figure, .example, .table
-{
- margin: 0.125in 0.25in;
-}
-
-.table table
-{
- border-width: 1px;
- border-style: solid;
- border-color: black;
- border-spacing: 0;
- background: rgb(240,240,240);
-}
-
-.table td
-{
- border: none;
- border-right: 1px black solid;
- border-bottom: 1px black solid;
- padding: 2px;
-}
-
-.table th
-{
- background: rgb(180,180,180);
- border: none;
- border-right: 1px black solid;
- border-bottom: 1px black solid;
- padding: 2px;
-}
-
-.table p.title, .figure p.title, .example p.title
-{
- text-align: left !important;
- font-size: 100% !important;
-}
-
-.author, .pubdate
-{
- margin: 0;
- font-size: 100%;
- font-style: italic;
- font-weight: normal;
- color: black;
-}
-
-.preface div.author, .preface .pubdate
-{
- font-size: 80%;
-}
-
-.sidebar
-{
- border-top: dotted 1px black;
- border-left: dotted 1px black;
- border-right: solid 2px black;
- border-bottom: solid 2px black;
- background: rgb(240,220,170);
- padding: 0 0.12in;
- margin: 0.25in;
-}
-
-.note .programlisting, .note .screen,
-.tip .programlisting, .tip .screen,
-.warning .programlisting, .warning .screen,
-.sidebar .programlisting, .sidebar .screen
-{
- border: none;
- background: none;
-}
-
-.sidebar p.title
-{
- text-align: center;
- font-size: 125%;
-}
-
-.note
-{
- border: black solid 1px;
- background: url(./images/note.png) no-repeat rgb(252,246,220);
- margin: 0.125in 0;
- padding: 0 55px;
-}
-
-.tip
-{
- border: black solid 1px;
- background: url(./images/tip.png) no-repeat rgb(224,244,255);
- margin: 0.125in 0;
- padding: 0 55px;
-}
-
-.warning
-{
- border: black solid 1px;
- background: url(./images/warning.png) no-repeat rgb(255,210,210);
- margin: 0.125in 0;
- padding: 0 55px;
-}
-
-.note .title, .tip .title, .warning .title
-{
- display: none;
-}
-
-.programlisting, .screen
-{
- font-size: 90%;
- color: black;
- margin: 1em 0.25in;
- padding: 0.5em;
- background: rgb(240,240,240);
- border-top: black dotted 1px;
- border-left: black dotted 1px;
- border-right: black solid 2px;
- border-bottom: black solid 2px;
-}
-
-.navheader, .navfooter
-{
- border: black solid 1px;
- background: rgb(180,180,200);
-}
-
-.navheader hr, .navfooter hr
-{
- display: none;
-}
diff --git a/users_guide/subversion.xml b/users_guide/subversion.xml
deleted file mode 100755
index c2947ef4cee64204500ef18f90db71c970d6942b..0000000000000000000000000000000000000000
--- a/users_guide/subversion.xml
+++ /dev/null
@@ -1,45 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<appendix id="subversion">
- <title>Getting the Sources from Subversion</title>
-
- <para>All of the source code for FXRuby is available for anonymous,
- read-only <ulink url="http://subversion.tigris.org/">Subversion</ulink>
- access. This chapter describes how to check out the sources for the
- development release of FXRuby and then build FXRuby from those sources. The
- information in this chapter builds on the basic Subversion instructions
- provided for any RubyForge hosted project, and specifically those <ulink
- url="http://rubyforge.org/scm/?group_id=300">instructions</ulink> for the
- FXRuby project hosted at RubyForge.</para>
-
- <para>There are some prerequisites. Obviously, you're going to need to have
- some kind of Subversion client installed on your system and have a clue
- about how to use it to check out code from a remote repository. Please do
- not send me questions about how to install or use Subversion. A good
- starting point for documentation about Subversion is the <ulink
- url="http://subversion.tigris.org/">home page</ulink>, and especially the
- <ulink url="http://svnbook.red-bean.com/">book</ulink>.</para>
-
- <para>You're also going to need to have a working <ulink
- url="http://www.swig.org/">SWIG</ulink> installation so that you can
- generate the C++ source files from the SWIG interface files. As of this
- writing, FXRuby requires SWIG version 1.3.22; later versions of SWIG will
- not work, nor will versions earlier than about 1.3.15.</para>
-
- <simplesect>
- <title>Checking out the code</title>
-
- <para>To check out the development version (i.e. the trunk) for FXRuby,
- type the following command:</para>
-
- <para><screen>svn checkout svn://rubyforge.org/var/svn/fxruby/trunk/FXRuby</screen></para>
-
- <para>Next, you'll need to use SWIG to generate the C++ source code from
- the SWIG interface files. To do that, type:</para>
-
- <para><screen>rake swig</screen></para>
-
- <para>At this point, you should be ready to change to the top-level
- directory and go through the normal build and installation process, as
- described in an earlier chapter.</para>
- </simplesect>
-</appendix>
diff --git a/users_guide/template.xml b/users_guide/template.xml
deleted file mode 100755
index 085c248fc8d5293e13e107c7fa717c7eaa3cbaee..0000000000000000000000000000000000000000
--- a/users_guide/template.xml
+++ /dev/null
@@ -1,5 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN" -->
-<chapter>
- <title>TITLE HERE</title>
- <para>PARAGRAPH(S) HERE</para>
-</chapter>
diff --git a/users_guide/todo.xml b/users_guide/todo.xml
deleted file mode 100755
index 249bffd91ea7aab89a43996d95e355ea89cf59ea..0000000000000000000000000000000000000000
--- a/users_guide/todo.xml
+++ /dev/null
@@ -1,76 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="todo">
- <title>To-do list</title>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>I haven't yet paid much attention to some of the more esoteric
- issues such as multithreaded applications, or interactions with other
- popular Ruby extensions. FXRuby seems to cooperate well with Ruby's
- thread scheduler on all platforms, although threading support for the
- mswin32 build of Ruby was broken for Ruby versions 1.6.7 and earlier.
- For best results, use Ruby versions 1.6.8 or later.</para>
- </listitem>
-
- <listitem>
- <para>More examples are always good. Instead of (or in addition to)
- merely cloning the C++ examples from the standard FOX distribution, it
- would be nice to have original example programs that demonstrate
- Ruby's special strengths.</para>
- </listitem>
-
- <listitem>
- <para>Documentation is of course a big weakness at this point. I am
- slowly building up a set of "pseudo-sources" with RDoc-style
- comments that can be used to generate API documentation but this is far
- from complete (see the <filename class="directory">rdoc-sources</filename>
- directory in the standard source distribution).</para>
- </listitem>
-
- <listitem>
- <para>Many people have expressed interest in a framework similar to
- Tk's <classname>Canvas</classname> widget that allows you to draw
- and drag 2-D shapes around, etc. Should be able to implement this kind
- of thing directly in Ruby code (i.e. no need to write it in C++ first
- and then "wrap" it).</para>
- </listitem>
-
- <listitem>
- <para>There is no native Mac OS X port of FOX, but many people are
- successfully building and running FOX and FXRuby applications on Mac OS
- X using Apple's X11 server implementation. For more information,
- please see the <ulink
- url="http://www.fox-toolkit.net/cgi-bin/wiki.pl?Mac_OS_X">Mac OS X</ulink>
- page at the <ulink url="http://www.fox-toolkit.net">FOX Community Wiki</ulink>
- site.</para>
- </listitem>
-
- <listitem>
- <para>Need to investigate how well FXRuby-based applications work with
- <ulink url="http://exerb.sourceforge.jp/index.en.html">exerb</ulink>,
- and perhaps add a section to the documentation about how to do this.</para>
- </listitem>
-
- <listitem>
- <para>As of this writing, FOX doesn't provide any support for
- internationalization (I18N) or Unicode text and so FXRuby doesn't
- either. It is possible that FOX 1.2 will include some I18N support (see
- the <ulink url="http://www.fox-toolkit.net/cgi-bin/wiki.pl?FAQ">FAQ</ulink>
- at the <ulink url="http://www.fox-toolkit.net">FOX Community Wiki</ulink>
- site), and if so, appropriate changes will be made to FXRuby at that
- time.</para>
- </listitem>
-
- <listitem>
- <para>FOX's list-like widgets (such as <classname>FXList</classname>)
- behave differently from Ruby container objects (such as
- <classname>Array</classname>) in the sense that when a list widget is
- destroyed, it typically destroys all of its contained items at the same
- time. One consequence of this behavior is that you can end up with Ruby
- objects that refer to dead C++ objects (a variation of the dangling
- pointer problem familiar to C/C++ programmers). I would like to see if
- this behavior can be modified for FXRuby so that it's impossible to
- end up with these "dangling references".</para>
- </listitem>
- </itemizedlist>
-</chapter>
diff --git a/users_guide/tutorial1.xml b/users_guide/tutorial1.xml
deleted file mode 100755
index 446ea0174681b292e97392dcdd7b6d8c5849d240..0000000000000000000000000000000000000000
--- a/users_guide/tutorial1.xml
+++ /dev/null
@@ -1,437 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="tutorial1">
- <title>Hello, World!</title>
-
- <para>There are a few things common to all programs that use FXRuby, and the
- purpose of this chapter is to help you get familiar with those. We'll do
- this by developing a short program that simply displays a button containing
- the text, "Hello, World!". For reference, this program is included in the
- <filename>examples</filename> subdirectory of the standard FXRuby source
- code distribution.</para>
-
- <section>
- <title>First Things First</title>
-
- <para>All of the code associated with the FXRuby extension is provided by
- the <classname>fox16 </classname>gem, so we need to start by requiring
- this gem:</para>
-
- <programlisting format="linespecific">require 'fox16'</programlisting>
-
- <para>Since all of the FXRuby classes are defined under the
- <classname>Fox</classname> module, you'd normally need to refer to them
- using their "fully qualified" names (i.e. names that begin with the
- <classname>Fox::</classname> prefix). Because this can get a little
- tedious, and because there's not really much chance of name conflicts
- between FXRuby and other Ruby extensions, I usually like to add an
- <methodname>include Fox</methodname> statement so that all of the names in
- the <classname>Fox</classname> module are "included" into the global
- namespace:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-<emphasis role="bold">include Fox</emphasis></programlisting>
-
- <para>Every FXRuby program begins by creating an
- <classname>FXApp</classname> instance:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-<emphasis role="bold">theApp = FXApp.new</emphasis></programlisting>
-
- <para>The <classname>FXApp</classname> instance has a lot of
- responsibilities in an FXRuby application. One of the most frequent ways
- you'll use it is to kick off the application's main event loop (which
- you'll see later in this tutorial). The application is also the object
- responsible for managing "global" resources like timers and the FOX
- registry. It is a different approach from some other GUI toolkits for
- Ruby, where these kinds of global resources are accessed using
- module-level methods. As you continue to develop programs using FXRuby,
- you'll learn about other ways that the <classname>FXApp</classname> object
- is used.</para>
-
- <para>The next step is to create an <classname>FXMainWindow</classname>
- instance to serve as the application's main window. If you've used Ruby/Tk
- before, this is similar to its <classname>TkRoot</classname>
- window:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-<emphasis role="bold">theMainWindow = FXMainWindow.new(theApp, "Hello")</emphasis></programlisting>
-
- <para>Here, we pass <parameter>theApp</parameter> as the first argument to
- <methodname>FXMainWindow.new</methodname> to associate the new
- <classname>FXMainWindow</classname> instance with this
- <classname>FXApp</classname>. The second argument to
- <methodname>FXMainWindow.new</methodname> is a string that will be used
- for the main window's title.</para>
-
- <para>So far, all we've done is instantiate the client-side objects.
- Unlike most other toolkits, FOX makes a distinction between client-side
- data (such as an <classname>FXMainWindow</classname> object) and
- server-side data (such as the X window associated with that Ruby object).
- To create the server-side objects associated with the already-constructed
- client-side objects, we call <methodname>FXApp#create</methodname>:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-theMainWindow = FXMainWindow.new(theApp, "Hello")
-
-<emphasis role="bold">theApp.create</emphasis></programlisting>
-
- <para>By default, all windows in FXRuby programs are invisible, so we need
- to call our main window's <methodname>show</methodname> instance
- method:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-theMainWindow = FXMainWindow.new(theApp, "Hello")
-theApp.create
-
-<emphasis role="bold">theMainWindow.show</emphasis></programlisting>
-
- <para>The last step is to start the program's main loop by calling
- <parameter>theApp</parameter>'s <methodname>run</methodname> instance
- method:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-theMainWindow = FXMainWindow.new(theApp, "Hello")
-theApp.create
-
-theMainWindow.show
-
-<emphasis role="bold">theApp.run</emphasis></programlisting>
-
- <para>The <methodname>FXApp#run</methodname> method doesn't return until
- the program exits. It is similar to the <methodname>mainloop</methodname>
- method used for Ruby/Tk and Ruby/GTK, and you can in fact use
- <methodname>FXApp#mainloop</methodname> as an alias for
- <methodname>run</methodname> if you prefer.</para>
-
- <para>At this point, we have a working (if not very interesting) program
- that uses FXRuby. If you run it, you'll see something like this:</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/hello-without-button.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </section>
-
- <section>
- <title>Better living through buttons</title>
-
- <para>Obviously, we need to add a few things to make it more interesting.
- Let's start by putting a button inside the main window. The
- <classname>FXButton</classname> class provides a standard push-button
- widget:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-theMainWindow = FXMainWindow.new(theApp, "Hello")
-<emphasis role="bold">FXButton.new(theMainWindow, "Hello, World!")</emphasis>
-theApp.create
-
-theMainWindow.show
-
-theApp.run</programlisting>
-
- <para>As you might guess, passing <parameter>theMainWindow</parameter> as
- the first argument to <methodname>FXButton.new</methodname> tells FXRuby
- that the new button is a child of the main window. The second argument to
- <methodname>FXButton.new</methodname> is a string that will be displayed
- on the button. If you run the program <emphasis>now</emphasis>, you should
- see this:</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/hello-with-button.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </section>
-
- <section>
- <title>Messages</title>
-
- <para>Now we're cookin' with Crisco, but let's press on and see what other
- things we can do to improve this. You may have noticed by now that the
- only way to quit the program is to close the window using the window
- manager's "close window" option, or to just kill the program outright. We
- can do better than that. Let's add a message handler for the
- <classname>FXButton</classname> such that when you click the button, it
- causes the program to exit:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-theMainWindow = FXMainWindow.new(theApp, "Hello")
-theButton = FXButton.new(theMainWindow, "Hello, World!")
-<emphasis role="bold">theButton.connect(SEL_COMMAND) do |sender, selector, data|
- exit
-end</emphasis>
-theApp.create
-
-theMainWindow.show
-
-theApp.run</programlisting>
-
- <para>Most FOX objects send out messages (also known as
- <emphasis>events</emphasis>) when something interesting happens. FOX
- messages have four important elements:</para>
-
- <orderedlist>
- <listitem>
- <para>The message <emphasis>sender</emphasis> is the object that sends
- the message. In this case, the <classname>FXButton</classname>
- instance is the sender.</para>
- </listitem>
-
- <listitem>
- <para>The message <emphasis>type</emphasis> is a predefined integer
- constant that indicates what kind of event has occurred (i.e. why this
- message is being sent). In this case, the message type is
- <constant>SEL_COMMAND</constant>, which indicates that the command
- associated with this widget should be invoked.</para>
- </listitem>
-
- <listitem>
- <para>The message <emphasis>identifier</emphasis> is another integer
- constant that is used to distinguish between different messages of the
- same type. For example, the message that tells a FOX window to make
- itself visible is a <constant>SEL_COMMAND</constant> message with the
- identifier <constant>FXWindow::ID_SHOW</constant> (where
- <constant>ID_SHOW</constant> is a constant defined in the
- <classname>FXWindow</classname> class). A different message
- identifier, <constant>FXWindow::ID_HIDE</constant>, tells an
- <classname>FXWindow</classname> instance to make itself
- invisible.</para>
- </listitem>
-
- <listitem>
- <para>The message <emphasis>data</emphasis> is an object containing
- message-specific information. For this case (the
- <classname>FXButton</classname>'s <constant>SEL_COMMAND</constant>
- message, there is no interesting message data, but we'll see other
- kinds of messages where the message data is useful.</para>
- </listitem>
- </orderedlist>
-
- <para>For historical reasons, the message type and identifier are usually
- packed into a single 32-bit unsigned integer known as the
- <emphasis>selector</emphasis>, and this is the value that is passed into
- the message handler block. Since we don't actually need to use the
- <parameter>sender</parameter>, <parameter>selector</parameter> or
- <parameter>data</parameter> arguments for this particular message handler,
- we can just ignore them and shorten the code to:</para>
-
- <programlisting format="linespecific">theButton.connect(SEL_COMMAND) { exit }</programlisting>
-
- <para>Re-run the program and push the button to convince yourself that it
- works.</para>
- </section>
-
- <section>
- <title>Adding a tool tip</title>
-
- <para>To wrap up this introduction, we'd like to add a few finishing
- touches to the program. The first addition is to add a tool tip to the
- button, such that when the mouse cursor hovers over the button for a short
- while, it will pop up a little message describing what the button
- does:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-theMainWindow = FXMainWindow.new(theApp, "Hello")
-
-theButton = FXButton.new(theMainWindow, "Hello, World!")
-<emphasis role="bold">theButton.tipText = "Push Me!"</emphasis>
-theButton.connect(SEL_COMMAND) { exit }
-
-<emphasis role="bold">FXToolTip.new(theApp)</emphasis>
-
-theApp.create
-
-theMainWindow.show
-
-theApp.run</programlisting>
-
- <para>There are two changes involved here. The first is to set the tool
- tip text for the button using the <methodname>tipText</methodname>
- accessor, and for this example we're setting the button's tip text to
- "Push Me!". The second change is to create the (single)
- <classname>FXToolTip</classname> instance for the application. Although
- this program shows the <classname>FXToolTip</classname> instance being
- created after the <classname>FXButton</classname>, it doesn't really
- matter when you do it. You just want to have instantiated the
- <classname>FXToolTip</classname> before you drop into the main event loop
- by calling <methodname>FXApp#run</methodname>. If you run this version and
- hover over the button for a second or so, you should see the tooltip pop
- up:</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/hello-with-tooltip.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </section>
-
- <section>
- <title>Adding an icon</title>
-
- <para>The final change is to add an icon to the button to make things a
- little more festive. FOX supports all of the popular image file formats
- (e.g. BMP, GIF, JPEG, PNG and TIFF) and you can use any of them as icons
- on buttons and labels. For this example, we'll use the one of the "Powered
- By Ruby" images created by Hal Fulton (and posted at the <ulink
- url="http://www.rubygarden.org/ruby?PoweredByRubyButtons">Ruby Garden
- Wiki</ulink>):</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-theApp = FXApp.new
-
-theMainWindow = FXMainWindow.new(theApp, "Hello")
-
-theButton = FXButton.new(theMainWindow, "Hello, World!")
-theButton.tipText = "Push Me!"
-<emphasis role="bold">iconFile = File.open("pbr.jpg", "rb")
-theButton.icon = FXJPGIcon.new(theApp, iconFile.read)
-iconFile.close</emphasis>
-theButton.connect(SEL_COMMAND) { exit }
-
-FXToolTip.new(theApp)
-
-theApp.create
-
-theMainWindow.show
-
-theApp.run</programlisting>
-
- <para>Here, <filename>pbr.jpg</filename> is the file name of the JPEG
- image file. You want to be sure to open the file in
- <emphasis>binary</emphasis> mode (i.e. including the "b" mode flag),
- because there is a difference on the Windows platform. Since it's a JPEG
- image, we need to use the <classname>FXJPGIcon</classname> class to
- instantiate this icon. The first argument to
- <methodname>FXJPGIcon.new</methodname> is just a reference to the
- <classname>FXApp</classname> instance, and the second argument is the
- contents of the image file. We associate this icon object with our button
- using the button's <methodname>icon</methodname> accessor method. If you
- run this example, you should see:</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/hello-with-icon-1.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
-
- <para>When you have both text and an icon displayed on a button (or its
- superclass, <classname>FXLabel</classname>) the default positioning is to
- display the icon to the left of the text. For this particular example,
- however, it would probably be more appropriate to display the icon
- <emphasis>above</emphasis> the text. We can achieve this using the
- button's <methodname>iconPosition</methodname> accessor method:</para>
-
- <programlisting format="linespecific">theButton.iconPosition = ICON_ABOVE_TEXT</programlisting>
-
- <para>If you re-run the program after adding this line, you should
- see:</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/hello-with-icon-2.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
-
- <para>The last change we're going to make is to make the icon transparent.
- FOX allows you to specify that some regions of an icon should be treated
- as "transparent", meaning that whatever's underneath them shows through.
- FOX distinguishes those transparent regions from the non-transparent ones
- using a transparency color, and any pixels in the original image that have
- that color become transparent. In most cases, FOX can determine this
- transparency color automatically (indeed, for image file formats like GIF
- it's part of the image information). You can also specify the transparency
- color explicitly if you like.</para>
-
- <para>For the icon we've chosen, it's pretty obvious that the transparency
- color is white, but let's let FOX figure that out for us. We want to
- activate two options for the icon:</para>
-
- <itemizedlist mark="bullet">
- <listitem>
- <para>the <constant>IMAGE_ALPHACOLOR</constant> option, which tells
- FOX that some regions of this image should be treated as transparent;
- and,</para>
- </listitem>
-
- <listitem>
- <para>the <constant>IMAGE_ALPHAGUESS</constant> option, which tells
- FOX to guess the appropriate transparency color using the colors used
- in the four corners of the image.</para>
- </listitem>
- </itemizedlist>
-
- <para>To set these options, add this line to the program:</para>
-
- <programlisting format="linespecific">theButton.icon.options = IMAGE_ALPHACOLOR | IMAGE_ALPHAGUESS</programlisting>
-
- <para>and then re-run the program after making this change to see the
- final result:</para>
-
- <screenshot>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/hello-with-icon-3.png"
- format="PNG" />
- </imageobject>
- </mediaobject>
- </screenshot>
- </section>
-</chapter>
diff --git a/users_guide/unicode.xml b/users_guide/unicode.xml
deleted file mode 100644
index fb79a4c9eb43e8eb3512ec22052e132df5cba793..0000000000000000000000000000000000000000
--- a/users_guide/unicode.xml
+++ /dev/null
@@ -1,75 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="unicode">
- <title>Unicode and FXRuby</title>
-
- <para>Beginning with version 1.6, FOX and FXRuby provide support for the
- display of Unicode strings in FOX widgets. For some excellent discussion
- about how to use Unicode in Ruby, I recommend Patrick Hall's article, <ulink
- url="http://ruphus.com/blog/2005/06/11/ruby-and-unicode/">"Ruby and
- Unicode"</ulink> and why the lucky stiff's follow-up article, <ulink
- url="http://redhanded.hobix.com/inspect/closingInOnUnicodeWithJcode.html">"Closing
- in on Unicode with Jcode"</ulink>. Here, we're going to make use of the
- ideas in those articles to give a quick demonstration of how to use FXRuby's
- support for Unicode.</para>
-
- <section>
- <title>Basic Application</title>
-
- <para>Here's the original version of our "Hello, World!" program:</para>
-
- <programlisting format="linespecific">require 'fox16'
-
-include Fox
-
-application = FXApp.new("Hello", "FoxTest")
-main = FXMainWindow.new(application, "Hello", nil, nil, DECOR_ALL)
-FXButton.new(main, "&Hello, World!", nil, application, FXApp::ID_QUIT)
-application.create()
-main.show(PLACEMENT_SCREEN)
-application.run()
-</programlisting>
-
- <para>and here's the modified version:</para>
-
- <programlisting format="linespecific">require 'fox16'
-<emphasis role="bold">require 'jcode'</emphasis>
-
-<emphasis role="bold">$KCODE = 'u'</emphasis>
-
-<emphasis role="bold">class UString < String
- # Show u-prefix as in Python
- def inspect; "u#{ super }" end
-
- # Count multibyte characters
- def length; self.scan(/./).length end
-
- # Reverse the string
- def reverse; self.scan(/./).reverse.join end
-end
-
-module Kernel
- def u( str )
- UString.new str.gsub(/U\+([0-9a-fA-F]{4,4})/u){["#$1".hex ].pack('U*')}
- end
-end</emphasis>
-
-include Fox
-
-<emphasis role="bold">question = u'U+00bfHabla espaU+00f1ol?'</emphasis>
-
-application = FXApp.new("Hello", "FoxTest")
-main = FXMainWindow.new(application, "Hello", nil, nil, DECOR_ALL)
-FXButton.new(main, <emphasis role="bold">question</emphasis>, nil, application, FXApp::ID_QUIT)
-application.create()
-main.show(PLACEMENT_SCREEN)
-application.run()
-</programlisting>
-
- <para>The <emphasis role="bold">jcode</emphasis> library (part of the
- standard Ruby library) provides a number of extensions to Ruby's
- <classname>String</classname> class, to ensure that its methods work
- properly for non-ASCII character encodings. By setting the
- <varname>$KCODE</varname> global variable to "u", we're telling Ruby which
- character encoding it is that we're using (UTF-8).</para>
- </section>
-</chapter>