wxPike README
=============

The original post:
------------------

From comments I made in the mail list.

I'm glad to see I'm not the only one willing to use wxWidgets from Pike. 
I'm uploading my binding as-is currently. It is incomplete, and probably ugly for any experienced module writer, so I accept suggestions.

About this version
------------------

If you tried prior versions, check for build/install/API changes in the Changelog. 

This version works with both old and new series stable releases (2.4.2 and 2.6.1 for GTK2) in Linux. wxPike compile but didn't run with 2.5.x releases (I don't know why, things just started working with 2.6.1). wxX11 should work too, but I didn't try it (yet). Support under Windows is planned as soon I be able to compile the module under Windows.

At this time it was tested on:

Slackware 10.1 wxWidgets 2.6.2 for GTK+ 2.0, GTK+ 2.6.7 (me)

About previous versions, Martin Bähr reported it didn't work with 2.5.x series at this time. This one should compile with 2.5.x, but won't work sucessfully. Martin also reported success with Debian Sarge and wxWidgets 2.4 GTK.

The inner workings
------------------

Most of the binding is generated with bindgen.pike from prototype declarations in a C++ like sui generis syntax, a somewhat it's possible with SWIG. More complex, special cases are in handcoded* files:

handcoded.cc: Main framework (At this time, wxApp and event managing)
handcoded2.cc: Special widget methods.

The generator is basically complete, see TODO for further changes and improvements.

The binding
-----------

At this time there just are a few classes declarations, and even those are incomplete at this time (see the Completion file for details), but adding declarations is easier, as long the generator can handle it by itself.

I aim to provide a more or less complete binding, just leaving out those areas that overlap with those already nicely provided by vanilla Pike, like complex types (wxString, wxArray), database support, etc. If you need or want some of these (or any class/method/whatever lacking at this time) check declarations/syntax.txt for the bindgen input syntax. (and please send me those back!)

All the virtual methods (but weird exceptions) are treated by the binding as such, even when I suspect many of these aren't virtual because of interface but implementation reasons. Anyway you should be able to define subclasses and things should go as expected.

There are a few cases where wxPike method syntax deviates from C++ syntax (generally methods with parameter polymorphism and values returned via pointers), usually I followed wxPython syntax in those cases. While this is not really necessary, it's a lot easier than deal with variable parameters, specially when I prefer limit the amount of handcoded methods.

Event message tables are not implemented, and can't be really implemented as they are static, but I think can be nicely implemented as a function with an array as a parameter, then doing a foreach() { Connect(); } there. So event definitions could look like:

MyFrame->BEGIN_EVENT_TABLE(
	({ EVT_MENU( ID_Quit, MyFrame->OnQuit),
	   EVT_MENU( ID_About, MyFrame->OnAbout)
	})
);

or:

BEGIN_EVENT_TABLE(MyFrame,
	({ EVT_MENU( ID_Quit, MyFrame->OnQuit),
	   EVT_MENU( ID_About, MyFrame->OnAbout)
	})
);

wxRuby simply add EVT_* methods with message table syntax to be called in the Ruby constructor.
If you are interested in message tables, please tell me what approach like you more. While I'm more interested in using Connect, and therefore this is not in my priorities, I won't be a nice guy if I do not try to provide complete binding.

The examples
------------

The "Hello world" (hworld.pike) example is a translation of http://www.wxwidgets.org/hworld2.txt.
The dialog example (dialog.pike) is a small test build from scratch.