Re: [wxhaskell-users] [wxhaskell-devel] The future of wxC

[Jeremy O'D. <jer...@gm...>]

On 25 January 2012 15:19, Dave Tapley <duk...@gm...> wrote:

> On 16 January 2012 00:46, Eric Kow <eri...@gm...> wrote:
>
>>
>> I was going to post on your blog, but you beat me to mentioning it. So
>> better hear it from me, you should totally use GitHub for wxC. Plus it
>> would be a chance to work with darcs-bridge maybe.
>>
>>
>>    1. Eric will probably kill me for saying this, but I think GitHub is
>>       probably the right place, possibly keeping Sourceforge as the project
>>       website and distribution point (I personally don't much like git, but it
>>       has mindshare, and probably makes more sense than Darcs for a non-Haskell
>>       project - plus my experience with patch-tag and darcsden has been that
>>       'getting going' on a Windows machine is far from trivial). I could be
>>       persuaded to change my mind on this one, but probably only if one of the
>>       Darcs hosts can get the experience 'right' on Windows clients.
>>       2. Keep the Cabal-based build system to start with, until there is
>>       clear evidence of non-Haskell contributions.
>>    1. If wxC turns out to have legs, the main areas to attack should be:
>>       1. Move to bakefile based build.
>>       2. Automated generation of the binding.
>>
>>
>>
> If I may weight in..
>
> I like the idea of moving wxC to a separate project, to at least open it
> up to other communities, and I'd be happy to have it on GitHub, if that's
> the consensus.
> What ever decision we make, do we want to hold off the move on to
> code.haskell.org until we've made a decision?
> Actually, it might be easier to get moved across in our current state, and
> then move out wxC afterwards?
>

I tend to favour moving to code.haskell.org first so that it remains easy
for Haskellers to work on wxHaskell using only Cabal.

I have been thinking along the lines of the cabal version of wxC becoming a
stub which contains pre-compiled wxC libraries and headers and installs
them for you. I think it's important that 'cabal install wx' continues to
work for Haskell users.

For that reasson, I'd rather move everything to c.h.o ASAP.


> R.e. Point 1.2. In the list above, I've been keeping half an eye on this
> -cafe thread, which seems to be getting more attention than I had
> anticipated:
> http://www.mail-archive.com/has...@ha.../msg96678.html
> I may be getting ahead of myself..
>

Me too :-)

However, I also  generated Doxygen XML output for wxWidgets (which the
wxWidgets people seem to favour), and it looks quite nice. Here's a sample
- it's the XML generated for the start of class wxPropertyGrid and the
method virtual void wxPropertyGrid::DoShowPropertyError(wxPGProperty
*property, const wxString &amp;msg);

  <compounddef id="classwx_property_grid" kind="class" prot="public">
    <compoundname>wxPropertyGrid</compoundname>
    <basecompoundref refid="classwx_control" prot="public"
virt="non-virtual">wxControl</basecompoundref>
    <basecompoundref refid="classwx_property_grid_interface" prot="public"
virt="non-virtual">wxPropertyGridInterface</basecompoundref>
    <includes local="no">wx/propgrid/propgrid.h</includes>
      <sectiondef kind="user-defined">
      <header>wxPropertyGrid customization</header>
      <description><para>Reimplement these member functions in derived
class for better control over <ref refid="classwx_property_grid"
kindref="compound">wxPropertyGrid</ref> behaviour. </para></description>
      <memberdef kind="function"
id="classwx_property_grid_1a6eff1187beba43109be7a12194b0bf2b" prot="public"
static="no" const="no" explicit="no" inline="no" virt="virtual">
        <type>void</type>
        <definition>virtual void
wxPropertyGrid::DoShowPropertyError</definition>
        <argsstring>(wxPGProperty *property, const wxString
&amp;msg)</argsstring>
        <name>DoShowPropertyError</name>
        <param>
          <type><ref refid="classwx_p_g_property"
kindref="compound">wxPGProperty</ref> *</type>
          <declname>property</declname>
        </param>
        <param>
          <type>const <ref refid="classwx_string"
kindref="compound">wxString</ref> &amp;</type>
          <declname>msg</declname>
        </param>
        <briefdescription>
<para>Override in derived class to display error messages in custom manner
(these message usually only result from validation failure). </para>
</briefdescription>
        <detaileddescription>
<para><simplesect kind="remark"><para>If you implement this, then you also
need to implement <ref
refid="classwx_property_grid_1af170d02811ab8eed906963de693b79aa"
kindref="member">DoHidePropertyError()</ref> - possibly to do nothing, if
error does not need hiding (e.g. it was logged or shown in a message
box).</para></simplesect>
<simplesect kind="see"><para><ref
refid="classwx_property_grid_1af170d02811ab8eed906963de693b79aa"
kindref="member">DoHidePropertyError()</ref> </para></simplesect>
</para>        </detaileddescription>
        <inbodydescription>
        </inbodydescription>
        <location
file="D:/Builds/wxWidgets-2.9.3/interface/wx/propgrid/propgrid.h"
line="1108"/>
      </memberdef>
Notice that all of the documentation is retained (which would be very nice
for documenting wxcore), and that function signature is quite easy to
extract.

Jeremy