From: Jeremy O'D. <jer...@gm...> - 2012-01-15 23:03:30
|
Hi lists, There have been a number of discussions over the past week or so on the future of wxC. I'm not as good as Dave at cross-referencing everything, but at the very least we have: http://www.mail-archive.com/wxh...@li.../msg01050.html http://www.mail-archive.com/wxh...@li.../msg00735.html http://www.mail-archive.com/wxh...@li.../msg00736.html http://wewantarock.wordpress.com/2012/01/12/who-is-my-community/ http://www.reddit.com/r/programming/comments/oek2t/any_interest_in_a_c_binding_to_wxwidgets_from/ What I have tried to do is to raise the option of making wxC a separate project to other groups (Dave and Eric have reached out to a couple of other comunities as well), and see whether there is much interest out there. The most concrete interest has come from the D community, which lacks a good GUI binding, and which (it seems to me, based entirely on blog noise) is growing pretty rapidly, with some more vague interest coming from the wxWidgets community more generally (and granted that I have not done much to reach out in that direction). I must say that I am at least somewhat convinced that there is demand for wxC 'out there', and it is therefore worth making an initial effort to make wxC a viable option for other language communities. With this in mind, I would like to suggest a staged approach - comments and opinions are very welcome. 1. The first stage is to simply get wxHaskell with 2.9.x support out of the door. I don't think we should change anything at this stage, other than that it definitely makes more sense to use wx-config-win on Windows platforms if we are going to work with others. 2. The second stage is to spin wxC off as a separate project. 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. 3. 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. I must say that comments to the blog posting in particular were really quite encouraging, but I don't waht to put the cart before the horse. In particular, Gour (an ex-Haskeller) and Andrej seem keen to try out what we have already with D, which would make an excellent proof of concept. Once we've had some discussion (say around the middle of the week), I'd like to blog on what we propose to do, and start to reach out a bit further to other groups. Regards Jeremy |
From: Eric K. <eri...@gm...> - 2012-01-16 00:46:49
|
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. > 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. > Keep the Cabal-based build system to start with, until there is clear evidence of non-Haskell contributions. > If wxC turns out to have legs, the main areas to attack should be: > Move to bakefile based build. > Automated generation of the binding. |
From: Dave T. <duk...@gm...> - 2012-01-25 15:20:22
|
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? 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.. > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
From: Jeremy O'D. <jer...@gm...> - 2012-01-25 15:38:36
|
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 &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 |