wxhaskell-devel — wxhaskell developers

Re: [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

Re: [wxhaskell-devel] The 'making wxC build on all platforms thread

[Dave T. <duk...@gm...>]

Hi all,

Sorry I've been a little quiet the last week or two, rest assured I have
lurking all along.

On 22 January 2012 00:37, Jeremy O'Donoghue <jer...@gm...>wrote:

> I now have wxC building on Windows. Details below and patches attached.
>

Excellent!
I'll take a look.


>
> Jeremy
>
>  On 18 January 2012 23:34, Jeremy O'Donoghue <jer...@gm...>wrote:
>
>> On 17 January 2012 22:40, Jeremy O'Donoghue <jer...@gm...>wrote:
>>
>>> On 17 January 2012 21:38, Jeremy O'Donoghue <jer...@gm...>wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have collected together all of the people who I know are making the
>>>> effort to build Dave's latest code on different platforms. I'd also like to
>>>> introduce Andrej, who is testing wxC in the context of D (so could we go
>>>> easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in
>>>> this thread :-)
>>>>
>>>> I'd suggest that we try to pull together all of the experiences into a
>>>> single thread - makes it easier for people to keep up.
>>>>
>>>> For the moment, I'd like to bring up my experience with wxC on Windows:
>>>>
>>>> First, you need at least a patch to wx-config-win32 which sorts out
>>>> library names (msys libraries are incorrectly named due to a 2.8/2.9
>>>> change)
>>>>
>>>> At line 948 of wx-config-win.cpp, you need:
>>>> if (cfg["BUILD"] == “debug” && cfg["DEBUG_FLAG"] == “default”)
>>>> po["WXDEBUGFLAG"] = “”;
>>>>
>>>> if (cfg["DEBUG_FLAG"] == “1″)
>>>> po["WXDEBUGFLAG"] = “”;
>>>>
>>>>
>>>> Second, in wxc/Setup.hs you need to change line 82 (just after output
>>>> readProcess “wx-config” ["--libs", "std,gl,stc,xrc,richtext,aui,media",
>>>> "--cppflags"] “”
>>>>
>>>> This is needed because wx-config-win does not support the new ‘all’
>>>> flag, and I haven’t had time to fix wx-config-win properly.
>>>>
>>>> Third, the library then builds for me, but fails to link (link errors
>>>> in StyledTextCtrl). I hope to work out why tonight or tomorrow.
>>>>
>>>>
>>>>
>>>>
>>> I've worked out why, but haven't fixed it.
>>>
>>> wx-config-win doesn't know about some of the new libraries, and is
>>> giving incorrect results in other cases. I don't have time to fix this
>>> tonight, but:
>>>
>>> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config
>>> --libs base,gl,xrc,richtext,aui,media returns
>>>  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_richtext
>>> -lwxmsw29u_gl -lopengl32 -lglu32 -lwxmsw29u_media -lwxbase29u -lwxtiff
>>> -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32
>>> -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32
>>> -lole32
>>> -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32
>>>
>>> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config
>>> --libs returns
>>>  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_html -lwxmsw29u_adv
>>> -lwxmsw29u_core -lwxbase29u_xml -lwxbase29u_net
>>> -lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat
>>> -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lw xregexu -lwinspool -lwinmm
>>> -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32
>>> -lwsock32
>>>
>>> Missing base libraries in red.
>>>
>>> I'll try to fix this tomorrow.
>>>
>>>
>>
> I have managed to make wx-config-win work, at least for my configuration.
> There is a known bug which I lack the will to fix right now - the command
> line parser in wx-config-win is very rudimentary and thinks that wx-config
> --libs all --cppflags is looking for the additional library --cppflags.
>
> The work-around is to call wx-config --cppflags --libs all - I have
> changed wxc\Setup.hs to call wx-config this way.
>
> Changes to wx-config-win are quite numerous. The most notable is that the
> Unix wx-config has the set of libraries available (e.g. for "all")
> hard-coded into it (when wx-config.in is turned into wx-config by
> configure). On Windows this is not possible, so I have written a function
> which goes to the library directory of the selected wxWidgets install and
> enumerates all of the wx-related libraries. This is a bit fragile really,
> since it assumes that future wxWidgets libraries follow the current naming
> convention, but it works for now.
>
> I don't have access to the wx-config-win svn repo, so the updated file is
> attached. Oh, and it also builds under VS2010 now (I wanted a decent
> debugger!).
>
> A couple of minor patches were needed to wxc to make it build. These are:
>
>    - Reversed the order of libraries, to correctly permit static linking
>    (because MinGW GCC actually statically links the implibs).
>    - Don't specify wxWidgets version for Windows (wx-config-win doesn't
>    support). We do show the detected version, however.
>    - Work-around for the wx-config-win --cppflags bug noted above.
>    - Add the -Wl,enable-auto-import link flag on Windows, which gets rid
>    of a lot of spurious link warnings.
>    - Made wxc.a and wxc.dll build in the dist\build directory, so install
>    succeeds.
>    - Added undef cases for wxAUI event wrappers
>
>
> I am now failing to build wxcore. This is faling to find the wxc header
> files on Windows (it is looking for them in ./include/wxc). I notice that
> Dave has already marked the wxcInstallDir function as dubious, so I'll
> start looking there when it isn't past midnight (a bad time to start
> anything, IME).
>

Mmm, I'm sorry about that.
I actually went for this solution because I'm using cabal-dev to work on
wxHaskell (so I can keep the hackage wxHaskell in my system cabal pkg
conf): I needed a way to find the wxC headers (which obviously should be
part of the wxC package) during the wxcore configure (because wxdirect
(called by wxcore) needs them to generate some Haskell source (the FFI
bindings)).

Whilst I did mark wxcInstallDir as dubious, I do quite like the idea of
having cabal work out which version of wxC it is using to satisfy wxcore's
dependency, and then linking against exactly that version's header files.
The only alternatives I can think of are:

1. Enforce that wxC is installed as a system or user shared library and
find/version it up as we would any other external library (this would be
required if we stopped using cabal).

2. Provide some other (auto-guesswork-or-specify-on-command-line) mechanism
to tell wxcore: "can you configure yourself with the wxC headers here, and
link against this shared library".


Dave,



> NB: Andrej, the contents of this mail should be enough for you to start
> working with wxD on Windows, but please note that I have not tested wxc.dll
> (which is generated in wxc/dist/build, BTW) as I need wxcore built before I
> can try to run any of our test cases.
>
> Regards
> Jeremy
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> 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-dev2
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>

Re: [wxhaskell-devel] The future of wxC

[Dave T. <duk...@gm...>]

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
>
>

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

[Frodo K. <fro...@gm...>]

>>> >>
>>> >> However, keyboard input is not directed to the gui but to the ghci
>>> >> terminal…
>>> >>
>>> >> There used to be an EnableGUI module to fix this
>>> >> (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does
>>> >> not
>>> >> seem to work anymore.
>>> >>
>>> >> The window can be closed and restarted from ghci though. However, the
>>> >> window does not actually disappear until ghci is exited.
>>>
>>> I'm a little confused by this statement?
>>> Do you mean: You can close the window, and ghci returns to the prompt,
>>> but the actual window manager window remains?
>>
>>
>> If I press the close button (there is no menubar), the window does not
>> actually disappear but it does not react to any (mouse) inputs anymore and
>> the ghci prompt returns. Without keyboard input going to the gui and without
>> a menu bar, the gui is not really useful yet I guess, so I hope this is
>> fixable.
>
> Oh, I understand now.
> I haven't heard of this before, but it sounds like exactly the kind of
> weirdness I'd expect.
> Anyone?
>

Hmm, it appears the example I was using was broke. With the HelloWorld
sample and using:

main  = enableGUI >> start hello

the mouse and keyboard input do go to the window under GHCi. So this
is great as I now can do everything I could do before in GHC 6.10.

If I close the window it does remain visible in an unusable state
until you exit ghci. However, control returns to GHCi and I can
restart the application (i.e. run "main" again), re-using the same
window. So that is an improvement over before (which crashed ghci when
closing the window).

Re: [wxhaskell-devel] The 'making wxC build on all platforms thread

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

I now have wxC building on Windows. Details below and patches attached.

Jeremy

On 18 January 2012 23:34, Jeremy O'Donoghue <jer...@gm...>wrote:

> On 17 January 2012 22:40, Jeremy O'Donoghue <jer...@gm...>wrote:
>
>> On 17 January 2012 21:38, Jeremy O'Donoghue <jer...@gm...>wrote:
>>
>>> Hi all,
>>>
>>> I have collected together all of the people who I know are making the
>>> effort to build Dave's latest code on different platforms. I'd also like to
>>> introduce Andrej, who is testing wxC in the context of D (so could we go
>>> easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in
>>> this thread :-)
>>>
>>> I'd suggest that we try to pull together all of the experiences into a
>>> single thread - makes it easier for people to keep up.
>>>
>>> For the moment, I'd like to bring up my experience with wxC on Windows:
>>>
>>> First, you need at least a patch to wx-config-win32 which sorts out
>>> library names (msys libraries are incorrectly named due to a 2.8/2.9
>>> change)
>>>
>>> At line 948 of wx-config-win.cpp, you need:
>>> if (cfg["BUILD"] == “debug” && cfg["DEBUG_FLAG"] == “default”)
>>> po["WXDEBUGFLAG"] = “”;
>>>
>>> if (cfg["DEBUG_FLAG"] == “1″)
>>> po["WXDEBUGFLAG"] = “”;
>>>
>>>
>>> Second, in wxc/Setup.hs you need to change line 82 (just after output
>>> readProcess “wx-config” ["--libs", "std,gl,stc,xrc,richtext,aui,media",
>>> "--cppflags"] “”
>>>
>>> This is needed because wx-config-win does not support the new ‘all’
>>> flag, and I haven’t had time to fix wx-config-win properly.
>>>
>>> Third, the library then builds for me, but fails to link (link errors in
>>> StyledTextCtrl). I hope to work out why tonight or tomorrow.
>>>
>>>
>>>
>>>
>> I've worked out why, but haven't fixed it.
>>
>> wx-config-win doesn't know about some of the new libraries, and is giving
>> incorrect results in other cases. I don't have time to fix this tonight,
>> but:
>>
>> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config --libs
>> base,gl,xrc,richtext,aui,media returns
>>  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_richtext
>> -lwxmsw29u_gl -lopengl32 -lglu32 -lwxmsw29u_media -lwxbase29u -lwxtiff
>> -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32
>> -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32
>> -lole32
>> -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32
>>
>> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config --libs
>> returns
>>  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_html -lwxmsw29u_adv
>> -lwxmsw29u_core -lwxbase29u_xml -lwxbase29u_net
>> -lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat
>> -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lw xregexu -lwinspool -lwinmm
>> -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32
>> -lwsock32
>>
>> Missing base libraries in red.
>>
>> I'll try to fix this tomorrow.
>>
>>
>
I have managed to make wx-config-win work, at least for my configuration.
There is a known bug which I lack the will to fix right now - the command
line parser in wx-config-win is very rudimentary and thinks that wx-config
--libs all --cppflags is looking for the additional library --cppflags.

The work-around is to call wx-config --cppflags --libs all - I have changed
wxc\Setup.hs to call wx-config this way.

Changes to wx-config-win are quite numerous. The most notable is that the
Unix wx-config has the set of libraries available (e.g. for "all")
hard-coded into it (when wx-config.in is turned into wx-config by
configure). On Windows this is not possible, so I have written a function
which goes to the library directory of the selected wxWidgets install and
enumerates all of the wx-related libraries. This is a bit fragile really,
since it assumes that future wxWidgets libraries follow the current naming
convention, but it works for now.

I don't have access to the wx-config-win svn repo, so the updated file is
attached. Oh, and it also builds under VS2010 now (I wanted a decent
debugger!).

A couple of minor patches were needed to wxc to make it build. These are:

   - Reversed the order of libraries, to correctly permit static linking
   (because MinGW GCC actually statically links the implibs).
   - Don't specify wxWidgets version for Windows (wx-config-win doesn't
   support). We do show the detected version, however.
   - Work-around for the wx-config-win --cppflags bug noted above.
   - Add the -Wl,enable-auto-import link flag on Windows, which gets rid of
   a lot of spurious link warnings.
   - Made wxc.a and wxc.dll build in the dist\build directory, so install
   succeeds.
   - Added undef cases for wxAUI event wrappers


I am now failing to build wxcore. This is faling to find the wxc header
files on Windows (it is looking for them in ./include/wxc). I notice that
Dave has already marked the wxcInstallDir function as dubious, so I'll
start looking there when it isn't past midnight (a bad time to start
anything, IME).

NB: Andrej, the contents of this mail should be enough for you to start
working with wxD on Windows, but please note that I have not tested wxc.dll
(which is generated in wxc/dist/build, BTW) as I need wxcore built before I
can try to run any of our test cases.

Regards
Jeremy

Re: [wxhaskell-devel] The 'making wxC build on all platforms thread

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

On 17 January 2012 22:40, Jeremy O'Donoghue <jer...@gm...>wrote:

> On 17 January 2012 21:38, Jeremy O'Donoghue <jer...@gm...>wrote:
>
>> Hi all,
>>
>> I have collected together all of the people who I know are making the
>> effort to build Dave's latest code on different platforms. I'd also like to
>> introduce Andrej, who is testing wxC in the context of D (so could we go
>> easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in
>> this thread :-)
>>
>> I'd suggest that we try to pull together all of the experiences into a
>> single thread - makes it easier for people to keep up.
>>
>> For the moment, I'd like to bring up my experience with wxC on Windows:
>>
>> First, you need at least a patch to wx-config-win32 which sorts out
>> library names (msys libraries are incorrectly named due to a 2.8/2.9
>> change)
>>
>> At line 948 of wx-config-win.cpp, you need:
>> if (cfg["BUILD"] == “debug” && cfg["DEBUG_FLAG"] == “default”)
>> po["WXDEBUGFLAG"] = “”;
>>
>> if (cfg["DEBUG_FLAG"] == “1″)
>> po["WXDEBUGFLAG"] = “”;
>>
>>
>> Second, in wxc/Setup.hs you need to change line 82 (just after output
>> readProcess “wx-config” ["--libs", "std,gl,stc,xrc,richtext,aui,media",
>> "--cppflags"] “”
>>
>> This is needed because wx-config-win does not support the new ‘all’ flag,
>> and I haven’t had time to fix wx-config-win properly.
>>
>> Third, the library then builds for me, but fails to link (link errors in
>> StyledTextCtrl). I hope to work out why tonight or tomorrow.
>>
>>
>>
>
> I've worked out why, but haven't fixed it.
>
> wx-config-win doesn't know about some of the new libraries, and is giving
> incorrect results in other cases. I don't have time to fix this tonight,
> but:
>
> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config --libs
> base,gl,xrc,richtext,aui,media returns
>  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_richtext
> -lwxmsw29u_gl -lopengl32 -lglu32 -lwxmsw29u_media -lwxbase29u -lwxtiff
> -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32
> -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32
> -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32
>
> C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config --libs
> returns
>  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_html -lwxmsw29u_adv
> -lwxmsw29u_core -lwxbase29u_xml -lwxbase29u_net
> -lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat
> -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lw xregexu -lwinspool -lwinmm
> -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32
> -lwsock32
>
> Missing base libraries in red.
>
> I'll try to fix this tomorrow.
>
>

Quick status update - it's a bit more involved than I thought. I have coded
most of the changes needed to wx-config-win, but need to get them working.
C++ isn't like Haskell where things work first time once they compile, you
know :-)

ETA for wx-config-win update is now Friday night (GMT) - I have several
commitments tomorrow, so I won't do very much, I suspect.

Jeremy

Re: [wxhaskell-devel] The 'making wxC build on all platforms thread

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

On 17 January 2012 21:38, Jeremy O'Donoghue <jer...@gm...>wrote:

> Hi all,
>
> I have collected together all of the people who I know are making the
> effort to build Dave's latest code on different platforms. I'd also like to
> introduce Andrej, who is testing wxC in the context of D (so could we go
> easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in
> this thread :-)
>
> I'd suggest that we try to pull together all of the experiences into a
> single thread - makes it easier for people to keep up.
>
> For the moment, I'd like to bring up my experience with wxC on Windows:
>
> First, you need at least a patch to wx-config-win32 which sorts out
> library names (msys libraries are incorrectly named due to a 2.8/2.9
> change)
>
> At line 948 of wx-config-win.cpp, you need:
> if (cfg["BUILD"] == “debug” && cfg["DEBUG_FLAG"] == “default”)
> po["WXDEBUGFLAG"] = “”;
>
> if (cfg["DEBUG_FLAG"] == “1″)
> po["WXDEBUGFLAG"] = “”;
>
>
> Second, in wxc/Setup.hs you need to change line 82 (just after output
> readProcess “wx-config” ["--libs", "std,gl,stc,xrc,richtext,aui,media",
> "--cppflags"] “”
>
> This is needed because wx-config-win does not support the new ‘all’ flag,
> and I haven’t had time to fix wx-config-win properly.
>
> Third, the library then builds for me, but fails to link (link errors in
> StyledTextCtrl). I hope to work out why tonight or tomorrow.
>
>
>

I've worked out why, but haven't fixed it.

wx-config-win doesn't know about some of the new libraries, and is giving
incorrect results in other cases. I don't have time to fix this tonight,
but:

C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config --libs
base,gl,xrc,richtext,aui,media returns
 -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_richtext
-lwxmsw29u_gl -lopengl32 -lglu32 -lwxmsw29u_media -lwxbase29u -lwxtiff
-lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32
-lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32
-loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32

C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxc>wx-config --libs
returns
 -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_html
-lwxmsw29u_adv
-lwxmsw29u_core -lwxbase29u_xml -lwxbase29u_net
-lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat
-lkernel32 -luser32 -lgdi32 -lcomdlg32 -lw xregexu -lwinspool -lwinmm
-lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32

Missing base libraries in red.

I'll try to fix this tomorrow.

Regards
Jeremy

[wxhaskell-devel] The 'making wxC build on all platforms thread

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

Hi all,

I have collected together all of the people who I know are making the
effort to build Dave's latest code on different platforms. I'd also like to
introduce Andrej, who is testing wxC in the context of D (so could we go
easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in
this thread :-)

I'd suggest that we try to pull together all of the experiences into a
single thread - makes it easier for people to keep up.

For the moment, I'd like to bring up my experience with wxC on Windows:

First, you need at least a patch to wx-config-win32 which sorts out library
names (msys libraries are incorrectly named due to a 2.8/2.9 change)

At line 948 of wx-config-win.cpp, you need:
if (cfg["BUILD"] == “debug” && cfg["DEBUG_FLAG"] == “default”)
po["WXDEBUGFLAG"] = “”;

if (cfg["DEBUG_FLAG"] == “1″)
po["WXDEBUGFLAG"] = “”;

.
Second, in wxc/Setup.hs you need to change line 82 (just after output
readProcess “wx-config” ["--libs", "std,gl,stc,xrc,richtext,aui,media",
"--cppflags"] “”

This is needed because wx-config-win does not support the new ‘all’ flag,
and I haven’t had time to fix wx-config-win properly.

Third, the library then builds for me, but fails to link (link errors in
StyledTextCtrl). I hope to work out why tonight or tomorrow.

Best regards

Jeremy

Re: [wxhaskell-devel] API graphics

[David V. <dav...@gm...>]

Le 16 janvier 2012 17:26, Dave Tapley <duk...@gm...> a écrit :
>> On 14 Jan 2012, at 23:01, Eric Kow wrote:
>>> I think our haddocks should include pictures.  If not possible due to technical constraints, they should include links to pictures hosted on the wiki or perhaps somewhere more stable like a darcs repository.

> What kind of pictures do you foresee a need for?

Well, they say a picture speaks more than a thousant words ! For
documenting the layouts modes, that would be great.
Also, it's annoying to have to switch between the haddocs and the
wxWidget documentation, if everything could be in one place, that'd be
cool.

David.

P.S. Also, haddock is useless for anything other than English
documentation. (Accentuated letters have to be escaped, last time I
checked)

Re: [wxhaskell-devel] I declare the wxHaskell repo open for merging of wxWidgets 2.9.x support

[Personal <je...@o-...>]

Hi Dave,

It is indeed code.haskell.org.

You need an account - you can request one at
http://community.haskell.org/admin/account_request.html

One of the wxHaskell project admins needs to add you to the project. This is
a 30 second operation (addtoproject <username> wxhaskell).

Then you get to blat all over that ancient 2.8.x code...

Jeremy

-----Original Message-----
From: duk...@gm... [mailto:duk...@gm...] On Behalf Of Dave
Tapley
Sent: 16 January 2012 16:27
To: Jeremy O'Donoghue
Cc: wxhaskell-devel
Subject: Re: [wxhaskell-devel] I declare the wxHaskell repo open for merging
of wxWidgets 2.9.x support

On 15 January 2012 22:38, Jeremy O'Donoghue <jer...@gm...>
wrote:
> Hi developers,
>
> Think the subject says it all :-)

Bwahahahaa.

So, this is code.haskell.org?
How does one go about obtaining access?

>
> Jeremy
>
>
----------------------------------------------------------------------------
--
> 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
>

Re: [wxhaskell-devel] API graphics

[Eric K. <eri...@gm...>]

On 16 Jan 2012, at 16:26, Dave Tapley wrote:
>> Or maybe from a different direction, we should create
>> 
>> http://www.haskell.org/haskellwiki/WxHaskell/Widgets
>> 
>> With pictures pointing to the relevant haddocks
> 
> What kind of pictures do you foresee a need for?
> The wxWidget API seems to have a good coverage or sample renderings:
> http://www.google.com/search?q=site:docs.wxwidgets.org/2.9.3+Appearance&tbm=isch


I was thinking small thumbnails.

Two goals in mind:
- rapid navigation: I got kind of annoyed about having to read through the API when I sort of see what I wanted in my mind's eye. If I had a gallery I could just take a glance, go "that one!" and jump straight to the docs.
- discovery: sometimes I think I'm looking for something but actually am doing so because I hadn't adequately considered the alternatives, so instead of going "that one!", I'd spy an even better widget out of the corner of my eye and say "ah, that one instead!"

Not sure if it'd really help :-)

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] I declare the wxHaskell repo open for merging of wxWidgets 2.9.x support

[Dave T. <dav...@gm...>]

On 15 January 2012 22:38, Jeremy O'Donoghue <jer...@gm...> wrote:
> Hi developers,
>
> Think the subject says it all :-)

Bwahahahaa.

So, this is code.haskell.org?
How does one go about obtaining access?

>
> Jeremy
>
> ------------------------------------------------------------------------------
> 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
>

Re: [wxhaskell-devel] API graphics

[Dave T. <duk...@gm...>]

On 14 January 2012 23:02, Eric Kow <eri...@gm...> wrote:
>
> On 14 Jan 2012, at 23:01, Eric Kow wrote:
>> I think our haddocks should include pictures.  If not possible due to technical constraints, they should include links to pictures hosted on the wiki or perhaps somewhere more stable like a darcs repository.
>
>
> Or maybe from a different direction, we should create
>
> http://www.haskell.org/haskellwiki/WxHaskell/Widgets
>
> With pictures pointing to the relevant haddocks

What kind of pictures do you foresee a need for?
The wxWidget API seems to have a good coverage or sample renderings:
http://www.google.com/search?q=site:docs.wxwidgets.org/2.9.3+Appearance&tbm=isch


>
> --
> Eric Kow <http://erickow.com>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAk8SCZ8ACgkQBUrOwgisBPmjgwCfUqnsakJoEZ9Xs9eoa4Xc6XWG
> AJ0An0vRu1z+Z1jypG4iCAAFiWtNeZH3
> =flay
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> 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
>

Re: [wxhaskell-devel] The future of wxC

[Eric K. <eri...@gm...>]

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.

[wxhaskell-devel] The future of wxC

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

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

[wxhaskell-devel] I declare the wxHaskell repo open for merging of wxWidgets 2.9.x support

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

Hi developers,

Think the subject says it all :-)

Jeremy

Re: [wxhaskell-devel] API graphics

[Eric K. <eri...@gm...>]

On 14 Jan 2012, at 23:01, Eric Kow wrote:
> I think our haddocks should include pictures.  If not possible due to technical constraints, they should include links to pictures hosted on the wiki or perhaps somewhere more stable like a darcs repository.


Or maybe from a different direction, we should create

http://www.haskell.org/haskellwiki/WxHaskell/Widgets

With pictures pointing to the relevant haddocks

-- 
Eric Kow <http://erickow.com>

[wxhaskell-devel] API graphics

[Eric K. <eri...@gm...>]

I think our haddocks should include pictures.  If not possible due to technical constraints, they should include links to pictures hosted on the wiki or perhaps somewhere more stable like a darcs repository.

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

[Dave T. <duk...@gm...>]

On 13 January 2012 16:28, Frodo Kenny <fro...@gm...> wrote:
>
> On Thu, Jan 12, 2012 at 5:19 PM, Dave Tapley <duk...@gm...> wrote:
>>
>> On 12 January 2012 15:09, Jeremy O'Donoghue <jer...@gm...>
>> wrote:
>> > Thank you Kenneth,
>> >
>> > That's an extremely detailed and complete set of notes. It is very much
>> > appreciated.
>>
>> I'd also like to offer my thanks, this is extremely useful to us.
>
>
> You're welcome. Thanks for replying otherwise my post would not even be
> visible. I guess some copy-past action html-ified it. And here I was
> thinking attachments would be a problem :)

I noticed that, very strange..

>
>>
>>
>> >
>> > Best regards
>> > Jeremy
>> >
>> > On 12 January 2012 14:52, Frodo Kenny <fro...@gm...> wrote:
>> >>
>> >> Nice work. I was still on GHC 6.10 to be able to use wxhaskell with
>> >> ghci.
>> >>
>> >> Here are some notes and patches for OS X. I'm running Lion (10.7.2) and
>> >> getting wxwidgets running actually took the most time.
>> >>
>> >>
>> >> 1) wxwidgets
>> >>
>> >>
>> >> First of all, Haskell and wxwidgets must use the same architecture,
>> >> i.e.
>> >> both 32-bit or both 64-bit.
>>
>> This never occurred to me, well spotted.
>> We should check this, so I've created a ticket:
>>
>> https://sourceforge.net/tracker/?func=detail&aid=3472972&group_id=73133&atid=536848
>
>
> Good idea.
>
>>
>> >>
>> >> The standard build is 64-bit, but wxwidgets includes the QuickTime
>> >> framework which is only available in 32-bit. It builds and ghc only
>> >> gives a
>> >> warning, but ghci will give an error
>> >> (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but
>> >> wrong
>> >> architecture).
>> >>
>> >> To build 32-bit you can use "--enable-macosx_arch=i386".
>> >>
>> >> It looks like quicktime is only used for PICT support, which is
>> >> disabled
>> >> in 64-bit builds anyway, so I made a patch that disables quicktime for
>> >> both
>> >> 32 and 64 bit cocoa builds.
>> >>
>> >> By further disabling the ppc architecture, we can make a universal
>> >> 32/64-bit binary with:
>> >>
>> >> =remove -arch ppc in configure
>> >>
>> >> =remove -framework QuickTime in configure
>> >>
>> >> =remove PICT by __LP64__ -> __WXOSX_COCOA__ in bitmap.c, fontenum.c,
>> >> metafile.cpp
>> >>
>> >>
>> >> > ./configure --disable-debug --disable-dependency-tracking
>> >> > --with-osx_cocoa --disable-webkit
>> >> > --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk
>> >> > --with-macosx-version-min=10.6 --enable-universal_binary
>> >>
>> >> > make install
>> >>
>> >>
>> >> Note that on lion with the latest Xcode, 10.6 is the lowest sdk
>> >> version.
>> >>
>> >>
>> >> I use Homebrew so I attached a formula for it. To install homebrew:
>> >>
>> >>
>> >> > /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
>> >>
>> >>
>> >> Then put "wxosx.rb" in /usr/local/Library/Formula and run:
>> >>
>> >>
>> >> > brew install wxosx
>>
>> I'm not an OS X person, so this doesn't really mean anything to me; is
>> it something which should be on the wiki?
>
>
> I think that would be useful (homebrew is a package manager and the attached
> "formula" applies the patches and installs wxwidgets 2.9.3 relatively easy).

Ah, thanks for the explanation.

>
>>
>>
>> >>
>> >>
>> >>
>> >> 2) wxhaskell
>> >>
>> >>
>> >> installing wxc gives:
>> >>
>> >> > cd wxc
>> >>
>> >> > cabal install
>> >>
>> >> - error wxEVT_WEBKIT_ was not declared…
>> >>
>> >> so I disabled webkit in wxwidgets above.
>> >>
>> >>
>> >> -ld: file not found: undefined
>> >>
>> >> =change "-Wl,undefined" to "-Wl,-undefined" in linkCxxOpts in Setup.hs
>> >>
>> >>
>> >> installing wxcore
>> >>
>> >> -* Missing C library: wxc
>> >>
>> >> name is wxc.so instead of libwxc.dylib
>> >>
>> >> =change for sharedLibName: OSX -> "lib" ++ addExtension basename
>> >> ".dylib"
>> >> in Setup.hs
>> >>
>> >>
>> >> > ghc --make HelloWorld.hs
>> >>
>> >> Undefined symbols for architecture x86_64:
>> >>
>> >>   "_expEVT_DIALUP_DISCONNECTED
>> >>
>> >> I don't know where this is coming from (dialupman is enabled in
>> >> wxwidgets)
>> >> so I commented out the DIALUP lines in wxc_glue.h
>> >>
>> >>
>> >> > ./HelloWorld
>> >>
>> >> - dlopen(dist/build/libwxc.dylib) failed
>> >>
>> >> The final problem is that a dylib contains an absolute paths used for
>> >> linking, and the library is expected to be found at that locations. To
>> >> set
>> >> this path we must pass the "-install_name" argument when linking
>> >> libwxc.dylib
>> >>
>> >> =      OSX -> ["-dynamiclib",
>> >>
>> >>                   "-o " ++ out_dir </> sharedLibName ver basename,
>> >>
>> >>                   "-install_name " ++ basepath </> sharedLibName ver
>> >> basename,
>> >>
>> >>                   "-Wl,-undefined,dynamic_lookup"]
>> >>
>> >> in "linkCxxOpts", thus needing an extra "basepath" argument
>> >>
>> >> this is found by adding
>> >>
>> >> =        inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr
>> >> local_bld_info NoCopyDest
>> >>
>> >> to "myBuildHook" and also using an extra argument for "linkSharedLib".
>>
>> Thank you very much for the patch, but I have one tiny request:
>> I can't apply wxhaskell-osx.patch because the structure doesn't match
>> the one on my system.
>>
>> Could you record it with darcs and send the patch bundle as an
>> attachment (darcs send -o mypatch.dpatch)
>> http://darcs.net/manual/Darcs_commands.html#SECTION00661000000000000000
>> http://darcs.net/manual/Darcs_commands.html#SECTION00664000000000000000
>>
>> Also, if you record the patches your name will forever be attached to
>> them and you will received the karma you deserve :)
>>
>
> Done. The diff was only for the wxc directory, so maybe that was it. But
> karma is nice...

Mm, I do love me some darcs send, the patch applied successfully and
is now in -dev repo:
http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120113131345-1ccc1

Thank you for your contribution :)

>
>>
>> >>
>> >>
>> >> 3) using wxhaskell
>> >>
>> >>
>> >> "ghc --make" seems to work with the limited testing that I did
>> >>
>> >>
>> >> ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only
>> >> safe to invoke on the main thread.
>> >>
>> >>
>> >> ghci creates a new thread for each computation and under os x the gui
>> >> apparently must run on the main (first) thread.
>> >>
>> >> This is solved by:
>> >>
>> >> > ghci -fno-ghci-sandbox
>>
>> Another good tip for the wiki perhaps?
>> I wonder if there is a way to indicate at a package level that this is
>> required?
>>
>> >>
>> >> However, keyboard input is not directed to the gui but to the ghci
>> >> terminal…
>> >>
>> >> There used to be an EnableGUI module to fix this
>> >> (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does
>> >> not
>> >> seem to work anymore.
>> >>
>> >> The window can be closed and restarted from ghci though. However, the
>> >> window does not actually disappear until ghci is exited.
>>
>> I'm a little confused by this statement?
>> Do you mean: You can close the window, and ghci returns to the prompt,
>> but the actual window manager window remains?
>
>
> If I press the close button (there is no menubar), the window does not
> actually disappear but it does not react to any (mouse) inputs anymore and
> the ghci prompt returns. Without keyboard input going to the gui and without
> a menu bar, the gui is not really useful yet I guess, so I hope this is
> fixable.

Oh, I understand now.
I haven't heard of this before, but it sounds like exactly the kind of
weirdness I'd expect.
Anyone?

>
> Kenneth
>
>>
>>
>> Dave,
>>
>> >>
>> >> Does anybody know how this was working/can be fixed?
>> >>
>> >>
>> >> Hope this is useful.
>> >>
>> >>
>> >> Regards,
>> >>
>> >> Kenneth
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> 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
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > 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
>> >
>
>

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

[Dave T. <duk...@gm...>]

On 12 January 2012 15:09, Jeremy O'Donoghue <jer...@gm...> wrote:
> Thank you Kenneth,
>
> That's an extremely detailed and complete set of notes. It is very much
> appreciated.

I'd also like to offer my thanks, this is extremely useful to us.

>
> Best regards
> Jeremy
>
> On 12 January 2012 14:52, Frodo Kenny <fro...@gm...> wrote:
>>
>> Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci.
>>
>> Here are some notes and patches for OS X. I'm running Lion (10.7.2) and
>> getting wxwidgets running actually took the most time.
>>
>>
>> 1) wxwidgets
>>
>>
>> First of all, Haskell and wxwidgets must use the same architecture, i.e.
>> both 32-bit or both 64-bit.

This never occurred to me, well spotted.
We should check this, so I've created a ticket:
https://sourceforge.net/tracker/?func=detail&aid=3472972&group_id=73133&atid=536848

>>
>> The standard build is 64-bit, but wxwidgets includes the QuickTime
>> framework which is only available in 32-bit. It builds and ghc only gives a
>> warning, but ghci will give an error
>> (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong
>> architecture).
>>
>> To build 32-bit you can use "--enable-macosx_arch=i386".
>>
>> It looks like quicktime is only used for PICT support, which is disabled
>> in 64-bit builds anyway, so I made a patch that disables quicktime for both
>> 32 and 64 bit cocoa builds.
>>
>> By further disabling the ppc architecture, we can make a universal
>> 32/64-bit binary with:
>>
>> =remove -arch ppc in configure
>>
>> =remove -framework QuickTime in configure
>>
>> =remove PICT by __LP64__ -> __WXOSX_COCOA__ in bitmap.c, fontenum.c,
>> metafile.cpp
>>
>>
>> > ./configure --disable-debug --disable-dependency-tracking
>> > --with-osx_cocoa --disable-webkit
>> > --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk
>> > --with-macosx-version-min=10.6 --enable-universal_binary
>>
>> > make install
>>
>>
>> Note that on lion with the latest Xcode, 10.6 is the lowest sdk version.
>>
>>
>> I use Homebrew so I attached a formula for it. To install homebrew:
>>
>>
>> > /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
>>
>>
>> Then put "wxosx.rb" in /usr/local/Library/Formula and run:
>>
>>
>> > brew install wxosx

I'm not an OS X person, so this doesn't really mean anything to me; is
it something which should be on the wiki?

>>
>>
>>
>> 2) wxhaskell
>>
>>
>> installing wxc gives:
>>
>> > cd wxc
>>
>> > cabal install
>>
>> - error wxEVT_WEBKIT_ was not declared…
>>
>> so I disabled webkit in wxwidgets above.
>>
>>
>> -ld: file not found: undefined
>>
>> =change "-Wl,undefined" to "-Wl,-undefined" in linkCxxOpts in Setup.hs
>>
>>
>> installing wxcore
>>
>> -* Missing C library: wxc
>>
>> name is wxc.so instead of libwxc.dylib
>>
>> =change for sharedLibName: OSX -> "lib" ++ addExtension basename ".dylib"
>> in Setup.hs
>>
>>
>> > ghc --make HelloWorld.hs
>>
>> Undefined symbols for architecture x86_64:
>>
>>   "_expEVT_DIALUP_DISCONNECTED
>>
>> I don't know where this is coming from (dialupman is enabled in wxwidgets)
>> so I commented out the DIALUP lines in wxc_glue.h
>>
>>
>> > ./HelloWorld
>>
>> - dlopen(dist/build/libwxc.dylib) failed
>>
>> The final problem is that a dylib contains an absolute paths used for
>> linking, and the library is expected to be found at that locations. To set
>> this path we must pass the "-install_name" argument when linking
>> libwxc.dylib
>>
>> =      OSX -> ["-dynamiclib",
>>
>>                   "-o " ++ out_dir </> sharedLibName ver basename,
>>
>>                   "-install_name " ++ basepath </> sharedLibName ver
>> basename,
>>
>>                   "-Wl,-undefined,dynamic_lookup"]
>>
>> in "linkCxxOpts", thus needing an extra "basepath" argument
>>
>> this is found by adding
>>
>> =        inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr
>> local_bld_info NoCopyDest
>>
>> to "myBuildHook" and also using an extra argument for "linkSharedLib".

Thank you very much for the patch, but I have one tiny request:
I can't apply wxhaskell-osx.patch because the structure doesn't match
the one on my system.

Could you record it with darcs and send the patch bundle as an
attachment (darcs send -o mypatch.dpatch)
http://darcs.net/manual/Darcs_commands.html#SECTION00661000000000000000
http://darcs.net/manual/Darcs_commands.html#SECTION00664000000000000000

Also, if you record the patches your name will forever be attached to
them and you will received the karma you deserve :)

>>
>>
>> 3) using wxhaskell
>>
>>
>> "ghc --make" seems to work with the limited testing that I did
>>
>>
>> ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only
>> safe to invoke on the main thread.
>>
>>
>> ghci creates a new thread for each computation and under os x the gui
>> apparently must run on the main (first) thread.
>>
>> This is solved by:
>>
>> > ghci -fno-ghci-sandbox

Another good tip for the wiki perhaps?
I wonder if there is a way to indicate at a package level that this is required?

>>
>> However, keyboard input is not directed to the gui but to the ghci
>> terminal…
>>
>> There used to be an EnableGUI module to fix this
>> (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not
>> seem to work anymore.
>>
>> The window can be closed and restarted from ghci though. However, the
>> window does not actually disappear until ghci is exited.

I'm a little confused by this statement?
Do you mean: You can close the window, and ghci returns to the prompt,
but the actual window manager window remains?

Dave,

>>
>> Does anybody know how this was working/can be fixed?
>>
>>
>> Hope this is useful.
>>
>>
>> Regards,
>>
>> Kenneth
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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
>

[wxhaskell-devel] [ wxhaskell-Feature Requests-3472972 ] Fail gracefully when there is an architecture mis-match

[SourceForge.net <no...@so...>]

Feature Requests item #3472972, was opened at 2012-01-12 08:09
Message generated for change (Tracker Item Submitted) made by davetapley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536848&aid=3472972&group_id=73133

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: davetapley (davetapley)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fail gracefully when there is an architecture mis-match

Initial Comment:
As identified on the mailing list, it is required that "Haskell and wxwidgets must use the same architecture, i.e. both 32-bit or both 64-bit" [1].

It would be nice if wxc could check the architectures, fail gracefully and emit a message if they are not consistent.

[1] https://sourceforge.net/mailarchive/message.php?msg_id=28665899

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536848&aid=3472972&group_id=73133

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

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

Thank you Kenneth,

That's an extremely detailed and complete set of notes. It is very much
appreciated.

Best regards
Jeremy

On 12 January 2012 14:52, Frodo Kenny <fro...@gm...> wrote:

> Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci.
>
> Here are some notes and patches for OS X. I'm running Lion (10.7.2) and
> getting wxwidgets running actually took the most time.
>
>
> 1) wxwidgets
>
>
> First of all, Haskell and wxwidgets must use the same architecture, i.e.
> both 32-bit or both 64-bit.
>
> The standard build is 64-bit, but wxwidgets includes the QuickTime
> framework which is only available in 32-bit. It builds and ghc only gives a
> warning, but ghci will give an error
> (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but
> wrong architecture).
>
> To build 32-bit you can use "--enable-macosx_arch=i386".
>
> It looks like quicktime is only used for PICT support, which is disabled
> in 64-bit builds anyway, so I made a patch that disables quicktime for both
> 32 and 64 bit cocoa builds.
>
> By further disabling the ppc architecture, we can make a universal
> 32/64-bit binary with:
>
> =remove -arch ppc in configure
>
> =remove -framework QuickTime in configure
>
> =remove PICT by __LP64__ -> __WXOSX_COCOA__ in bitmap.c, fontenum.c,
> metafile.cpp
>
>
> > ./configure --disable-debug --disable-dependency-tracking
> --with-osx_cocoa --disable-webkit
> --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk
> --with-macosx-version-min=10.6 --enable-universal_binary
>
> > make install
>
>
> Note that on lion with the latest Xcode, 10.6 is the lowest sdk version.
>
>
> I use Homebrew so I attached a formula for it. To install homebrew:
>
>
> > /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
>
>
> Then put "wxosx.rb" in /usr/local/Library/Formula and run:
>
>
> > brew install wxosx
>
>
>
> 2) wxhaskell
>
>
> installing wxc gives:
>
> > cd wxc
>
> > cabal install
>
> - error wxEVT_WEBKIT_ was not declared…
>
> so I disabled webkit in wxwidgets above.
>
>
> -ld: file not found: undefined
>
> =change "-Wl,undefined" to "-Wl,-undefined" in linkCxxOpts in Setup.hs
>
>
> installing wxcore
>
> -* Missing C library: wxc
>
> name is wxc.so instead of libwxc.dylib
>
> =change for sharedLibName: OSX -> "lib" ++ addExtension basename ".dylib"
> in Setup.hs
>
>
> > ghc --make HelloWorld.hs
>
> Undefined symbols for architecture x86_64:
>
>   "_expEVT_DIALUP_DISCONNECTED
>
> I don't know where this is coming from (dialupman is enabled in wxwidgets)
> so I commented out the DIALUP lines in wxc_glue.h
>
>
> > ./HelloWorld
>
> - dlopen(dist/build/libwxc.dylib) failed
>
> The final problem is that a dylib contains an absolute paths used for
> linking, and the library is expected to be found at that locations. To set
> this path we must pass the "-install_name" argument when linking
> libwxc.dylib
>
> =      OSX -> ["-dynamiclib",
>
>                   "-o " ++ out_dir </> sharedLibName ver basename,
>
>                   "-install_name " ++ basepath </> sharedLibName ver
> basename,
>
>                   "-Wl,-undefined,dynamic_lookup"]
>
> in "linkCxxOpts", thus needing an extra "basepath" argument
>
> this is found by adding
>
> =        inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr
> local_bld_info NoCopyDest
>
> to "myBuildHook" and also using an extra argument for "linkSharedLib".
>
>
> 3) using wxhaskell
>
>
> "ghc --make" seems to work with the limited testing that I did
>
>
> ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only
> safe to invoke on the main thread.
>
>
> ghci creates a new thread for each computation and under os x the gui
> apparently must run on the main (first) thread.
>
> This is solved by:
>
> > ghci -fno-ghci-sandbox
>
> However, keyboard input is not directed to the gui but to the ghci
> terminal…
>
> There used to be an EnableGUI module to fix this (
> http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not
> seem to work anymore.
>
> The window can be closed and restarted from ghci though. However, the
> window does not actually disappear until ghci is exited.
>
> Does anybody know how this was working/can be fixed?
>
>
> Hope this is useful.
>
>
> Regards,
>
> Kenneth
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

[Frodo K. <fro...@gm...>]

Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci.

Here are some notes and patches for OS X. I'm running Lion (10.7.2) and
getting wxwidgets running actually took the most time.


1) wxwidgets


First of all, Haskell and wxwidgets must use the same architecture, i.e.
both 32-bit or both 64-bit.

The standard build is 64-bit, but wxwidgets includes the QuickTime
framework which is only available in 32-bit. It builds and ghc only gives a
warning, but ghci will give an error
(/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but
wrong architecture).

To build 32-bit you can use "--enable-macosx_arch=i386".

It looks like quicktime is only used for PICT support, which is disabled in
64-bit builds anyway, so I made a patch that disables quicktime for both 32
and 64 bit cocoa builds.

By further disabling the ppc architecture, we can make a universal
32/64-bit binary with:

=remove -arch ppc in configure

=remove -framework QuickTime in configure

=remove PICT by __LP64__ -> __WXOSX_COCOA__ in bitmap.c, fontenum.c,
metafile.cpp


> ./configure --disable-debug --disable-dependency-tracking
--with-osx_cocoa --disable-webkit
--with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk
--with-macosx-version-min=10.6 --enable-universal_binary

> make install


Note that on lion with the latest Xcode, 10.6 is the lowest sdk version.


I use Homebrew so I attached a formula for it. To install homebrew:


> /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"


Then put "wxosx.rb" in /usr/local/Library/Formula and run:


> brew install wxosx



2) wxhaskell


installing wxc gives:

> cd wxc

> cabal install

- error wxEVT_WEBKIT_ was not declared…

so I disabled webkit in wxwidgets above.


-ld: file not found: undefined

=change "-Wl,undefined" to "-Wl,-undefined" in linkCxxOpts in Setup.hs


installing wxcore

-* Missing C library: wxc

name is wxc.so instead of libwxc.dylib

=change for sharedLibName: OSX -> "lib" ++ addExtension basename ".dylib"
in Setup.hs


> ghc --make HelloWorld.hs

Undefined symbols for architecture x86_64:

  "_expEVT_DIALUP_DISCONNECTED

I don't know where this is coming from (dialupman is enabled in wxwidgets)
so I commented out the DIALUP lines in wxc_glue.h


> ./HelloWorld

- dlopen(dist/build/libwxc.dylib) failed

The final problem is that a dylib contains an absolute paths used for
linking, and the library is expected to be found at that locations. To set
this path we must pass the "-install_name" argument when linking
libwxc.dylib

=      OSX -> ["-dynamiclib",

                  "-o " ++ out_dir </> sharedLibName ver basename,

                  "-install_name " ++ basepath </> sharedLibName ver
basename,

                  "-Wl,-undefined,dynamic_lookup"]

in "linkCxxOpts", thus needing an extra "basepath" argument

this is found by adding

=        inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr
local_bld_info NoCopyDest

to "myBuildHook" and also using an extra argument for "linkSharedLib".


3) using wxhaskell


"ghc --make" seems to work with the limited testing that I did


ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe
to invoke on the main thread.


ghci creates a new thread for each computation and under os x the gui
apparently must run on the main (first) thread.

This is solved by:

> ghci -fno-ghci-sandbox

However, keyboard input is not directed to the gui but to the ghci terminal…

There used to be an EnableGUI module to fix this (
http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not
seem to work anymore.

The window can be closed and restarted from ghci though. However, the
window does not actually disappear until ghci is exited.

Does anybody know how this was working/can be fixed?


Hope this is useful.


Regards,

Kenneth

Re: [wxhaskell-devel] Weird implementation of wxTreeCtrl_GetBoundingRect

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

On 11 January 2012 15:55, Dave Tapley <duk...@gm...> wrote:

> On 11 January 2012 00:56, Dave Tapley <duk...@gm...> wrote:
> > Does anyone know why wxTreeCtrl_GetBoundingRect is implemented [1] such
> that:
> > 1. It returns a null pointer on non-Windows platforms.
> > 2. It disregards the returned value and returns GetRect().
> >
> > It came in with: "wxhaskell-from-cvs @ 2004-09-14 10:27:48 by dleijen".
> >
> > Dave,
> >
> > [1]
> http://darcsden.com/DukeDave/wxhaskell-dev/wxc/cpp/treectrl.cpp#L-535
>
> Well, I've 'fixed' it, and it appears to work just fine in Ubuntu:
> http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120111150758-a1f0b
>
> I'm still curious if anyone can answer my original two questions.
>

With respect to (1), I suspect that it is code dating back to wxWidgets 2.2
support (the 2.2. docs are no longer on line, so I can't confirm). At that
time, wxGTK was much less capable than wxMSW (it was based on GTK 1.x).

(2) baffles me completely.

Jeremy

Re: [wxhaskell-devel] Weird implementation of wxTreeCtrl_GetBoundingRect

[Dave T. <duk...@gm...>]

On 11 January 2012 00:56, Dave Tapley <duk...@gm...> wrote:
> Does anyone know why wxTreeCtrl_GetBoundingRect is implemented [1] such that:
> 1. It returns a null pointer on non-Windows platforms.
> 2. It disregards the returned value and returns GetRect().
>
> It came in with: "wxhaskell-from-cvs @ 2004-09-14 10:27:48 by dleijen".
>
> Dave,
>
> [1] http://darcsden.com/DukeDave/wxhaskell-dev/wxc/cpp/treectrl.cpp#L-535

Well, I've 'fixed' it, and it appears to work just fine in Ubuntu:
http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120111150758-a1f0b

I'm still curious if anyone can answer my original two questions.