On 25 January 2012 15:19, Dave Tapley <duked...@gmail.com> wrote:
> On 16 January 2012 00:46, Eric Kow <eric....@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 &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
&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> &</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
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
