On 25 January 2012 15:19, Dave Tapley <dukedave@gmail.com> wrote:
On 16 January 2012 00:46, Eric Kow <eric.kow@gmail.com> 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/haskell-cafe@haskell.org/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