[wxhaskell-devel] Source code?

[maciek . makowski]

Where is the official source code repository for wxHaskell? The
details in http://www.haskell.org/haskellwiki/WxHaskell/Development
are incorrect.

Thanks,
Maciek

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] [wxhaskell-users] Haskell Platform roadmap?

[Maciek Makowski]

Getting wxHaskell into HP would be great and I'd be happy to commit a
couple of hours each week for a year to help make it happen. That
said, I'm relatively new to Haskell and have very little experience
with linking with native libraries (my day job is Java programming) so
I might need quite a lot of guidance, at least initially.

Regards,
Maciek

On Tue, Jun 14, 2011 at 11:36 PM, Jeremy O'Donoghue
 wrote:
> Hi all,
>
> This is a call for help. There's been some discussion both on this list and
> on the cafe about getting a GUI into Haskell Platform.
>
> The formal requirement is that inclusion needs to be supported by at least
> one library maintainer, and from a practical perspective it should be
> something which builds and works well on all supported platforms, i.e.
> Linux, Windows and Mac, and should have a team of maintainers who are able
> to maintain the code over a long term basis.
>
> While there have been some fantastic contributions to wxHaskell over the
> past years from any people, the reality is that most of the work gets done
> by me, and some may have noticed that I don't have a lot of time - certainly
> nothing like enough to commit to inclusion in Haskell Platform.
>
> The call for help is this: can we get together a team which would be able to
> field enough effort to make a submission for Haskell Platform realistic? I
> believe that such a team would look something like the following:
>
> Project lead, release co-ordinator and mentor to others. That will be me
> then.
> Target leads for Linux, Mac and Windows. Responsible for building tip code
> for their platforms and providing fixes when it breaks. In the case of Mac
> and Linux, extra points if you can make things work using the platform
> built-in wxWidgets.
> A number of specific functional areas to be addressed:
>
> Fix the long-standing bug preventing GHCi use of wxHaskell. In my opinion,
> this is best addressed by factoring the C wrapper for wxHaskell (we call it
> wxC) into a separate library which is built as a dynamically loadable
> library. I know, in principle, how to do this for Windows and Linux, but
> would need help for Mac. Anyone who wants to help should know that this
> involves lots of revolting work with linkers, and is especially suitable for
> masochists. That's probably me as well.
> Make it easier to wrap some of the optional wxWidgets libraries. This
> requires work on wxDirect. This is probably the easiest area to work on as
> wxDirect is a self-contained executable, and is small and fairly simple to
> understand.
> Using the above, wrap some of the optional libraries. STC should be
> reinstated in wxHaskell now (it's part of the core in wxWidgets 2.9), but
> there are many others. OpenGL canvas, AUI and the media framework look
> particularly interesting.
> Consider a pure Haskell replacement for wx-config, at least on Windows, but
> potentially on all targets. We currently bundle a 3rd party wx-config
> replacement for Windows, but it doesn't work very well on wxWidgets 2.9.
> Extend Graphics.UI.WX so that more of the core functionality has high-level
> wrappers, e.g. for Grid, List boxes etc. I would love to see an FRP wrapper
> around parts of wxHaskell, and think we could reinstate one or more of the
> FRP libraries, for example. Making GUI programming less like C programming
> would do a lot to promote Haskell GUI development, but it requires much
> better Haskell-fu than I have to offer.
>
> Go back through the list of bugs and feature requests and fix as many as
> possible. This is an easy starting point for a new wxHaskell contributor.
> Improve documentation. While wxHaskell is pretty good, it could definitely
> be improved. In particular, I think we should consider finding a way to
> generate better documentation for the wxC wrapper functions, which currently
> only include type information.
>
> There's probably a lot more to do, and I welcome comments and suggestions. I
> welcome offers of help even more, and estimate that getting into HP requires
> a core team of 6-8 people who can commit to a few hours per week for at
> least a year. This is a huge ask, but the outcome would be that wxHaskell
> could become part of the Haskell Platform, and would likely be much more
> widely used.
>
> What do you think?
>
> Best regards
> Jeremy
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> wxhaskell-users mailing list
> wxhaskell-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

--
EditLive Enterprise is the world's most technically advanced content
authori

[wxhaskell-devel] Building wxcore on Windows: problem with wx-config

[maciek . makowski]

wx-config-win (from https://sites.google.com/site/wxconfig/) does not
support --version flag used by latest wxcore/Setup.hs. How should I go
about building on Windows?

Regards,
Maciek

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Building wxcore on Windows: problem with wx-config

[Maciek Makowski]

This is darcs tip, hackage version built fine for me a couple of weeks ago.

Do we want the ability to build given version of wxHaskell against different
versions of wxWidgets? If so, wouldn't patching wx-config-win be the
simplest solution?

Maciek

On 20 Jun 2011 00:28, "Jeremy O'Donoghue" 
wrote:

On 19 June 2011 22:03,  wrote:
>
> wx-config-win (from https://sites.goog...
Haven't seen this - I'll look into it (there are other problems with
wx-config, but this is a new one on me).

Assume you're trying to build either darcs tip or current hackage version
with latest Haskell Platform. Please let me know if it isn't one of these.

Jeremy
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Conflicting exports in wxcore

[maciek . makowski]

I get the following during "cabal install" in wxcore (darcs tip):

--
src\haskell\Graphics\UI\WXCore.hs:25:11:
Conflicting exports for `wxEVT_FIRST':
  `module Graphics.UI.WXCore.WxcClasses' exports
`Graphics.UI.WXCore.WxcClasses.wxEVT_FIRST' imported from
Graphics.UI.WXCore.WxcClasses at
src\haskell\Graphics\UI\WXCore.hs:47:1-36

(defined at
src\haskell\Graphics\UI\WXCore\WxcClassesMZ.hs:17133:1)
  `module Graphics.UI.WXCore.WxcDefs' exports
`Graphics.UI.WXCore.WxcDefs.wxEVT_FIRST' imported from
Graphics.UI.WXCore.WxcDefs at
src\haskell\Graphics\UI\WXCore.hs:46:1-33

  (defined at src\haskell\Gra
phics\UI\WXCore\WxcDefs.hs:2969:1)

src\haskell\Graphics\UI\WXCore.hs:25:11:
Conflicting exports for `wxEVT_NULL':
  `module Graphics.UI.WXCore.WxcClasses' exports
`Graphics.UI.WXCore.WxcClasses.wxEVT_NULL' imported from
Graphics.UI.WXCore.WxcClasses at
src\haskell\Graphics\UI\WXCore.hs:47:1-36

   (defined at src\haskel
l\Graphics\UI\WXCore\WxcClassesMZ.hs:17700:1)
  `module Graphics.UI.WXCore.WxcDefs' exports
`Graphics.UI.WXCore.WxcDefs.wxEVT_NULL' imported from
Graphics.UI.WXCore.WxcDefs at
src\haskell\Graphics\UI\WXCore.hs:46:1-33

 (defined at
src\haskell\Graphics\UI\WXCore\WxcDefs.hs:2966:1)
--

Is it a known issue?

Regards,
Maciek

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Conflicting exports in wxcore

[maciek . makowski]

Thanks, that sorted this one out.

In summary, to build darcs tip on Windows against wxWidgets 2.8 I needed:

1. a patch that removes wx-config --version call and hard-codes 2.8
libraries (attached)
2. Dave's patch from the previous e-mail in this thread

1. is obviously not ideal given that the goal now is to support
multiple wxWidgets versions with the same codebase. I'll have a look
at Eric's Haskell version of wx-config to see if it can help here.

Maciek

On Fri, Jul 29, 2011 at 9:43 PM, Dave Tapley  wrote:
> The attached patch resolves this issue for me.
>
> Let me know how you get on.
>
> Dave,
>
>
> On 28 July 2011 23:08, Dave Tapley  wrote:
>>
>> Yep, I see this¹ as well, I'll take a look now.
>>
>> Dave,
>>
>>
>> ¹ http://sourceforge.net/mailarchive/message.php?msg_id=27810904
>
>


patch_for_unsupported_wx-config_flag
Description: Binary data
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] [wxhaskell-users] Haskell Platform roadmap?

[maciek . makowski]

I set up a BuildBot instance for wxHaskell darcs tip:
http://build.bimbr.com/wxhaskell/waterfall. At the moment it is
configured to run nightly, at 1 AM CET (numerous builds at other times
are a result of me testing the setup). The only slave I configured so
far is Windows with wxWidgets 2.8, but if anyone would like to
contribute a differently configured slave to build on, that would be
most welcome. Please let me know if you have a machine that is
regularly online at this time or if you are willing to configure an
EC2 AMI (I can host it).

As you can see, the Windows build currently fails due to unsupported
wx-config --version flag, which has been discussed on wxhaskell-devel
before. A reasonable next step seems to be to to actually fix the
Windows build, which I hope to have a stab at next weekend.

Also, this is the first time I had anything to do with BuildBot, so
any suggestions on how to improve the setup are welcome.

Maciek

On Wed, Jun 15, 2011 at 1:12 PM, Eric Kow  wrote:
> On Tue, Jun 14, 2011 at 23:36:37 +0100, Jeremy O'Donoghue wrote:
>>    - Target leads for Linux, Mac and Windows. Responsible for building tip
>>    code for their platforms and providing fixes when it breaks. In the case 
>> of
>>    Mac and Linux, extra points if you can make things work using the platform
>>    built-in wxWidgets.
>
> So it sounds like what could be handy is to partially automate our way
> out of this with something like buildbot.  We would need somebody to
> manage the master, and also volunteers to provide always-on Mac, Linux
> and Windows machines to do the builds for us.
>
> You can get an idea of what buildbot would buy us at
>  http://buildbot.darcs.net/waterfall
>
> I'm a big fan of replacing scarce humans with robots wherever possible.
> ... but we do need somebody to help with said robots!
>
> --
> Eric Kow 
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk34oZUACgkQBUrOwgisBPnl+wCeN4gLoWD9hlokzS/xugr7WpNS
> exAAoL3bzR5V7qBqjDt20u051oMC1bST
> =8jSq
> -END PGP SIGNATURE-
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> wxhaskell-users mailing list
> wxhaskell-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Fix for Windows build

[maciek . makowski]

Attached is my attempt to fix the Windows build. It should not have
any impact on the builds on other platforms.

The patch contains:
- Dave's fix to conflicting wxEVT definitions
- Eric's wx-config replacement
- my changes to WxConfig and wxcore Setup.hs

Any chance this can be applied to the official repo?

Regards,
Maciek


windows_build_fix
Description: Binary data
--
FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
Subversion made easy with a complete admin console. Easy 
to use, easy to manage, easy to install, easy to extend. 
Get a Free download of the new open ALM Subversion platform now.
http://p.sf.net/sfu/wandisco-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Fix for 3019730

[maciek . makowski]

Attached is a patch for the colorDialog return value bug:
https://sourceforge.net/tracker/?func=detail&aid=3019730&group_id=73133&atid=536845.

Can someone please review it and, if there are no issues with it, apply?

Thanks,
Maciek


fix_for_3019730
Description: Binary data
--
FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
Subversion made easy with a complete admin console. Easy 
to use, easy to manage, easy to install, easy to extend. 
Get a Free download of the new open ALM Subversion platform now.
http://p.sf.net/sfu/wandisco-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] liberal commit access?

[Maciek Makowski]

I don't have a strong opinion on which version of wx should be
supported by wxHaskell, as long as there is at least one that works on
Windows without the need to compile wxWidgets from source. Until there
is a wxPack available for 2.9 I fear that the majority of Windows
users will be stuck with wxHaskell versions that work with 2.8.

That aside, focusing on supporting a single version of wxWidgets
sounds like a reasonable thing to do.

Maciek

On Mon, Nov 28, 2011 at 5:56 PM, Dave Tapley  wrote:
> On 28 November 2011 11:37, Jeremy O'Donoghue  
> wrote:
>> On 21 November 2011 18:31, Dave Tapley  wrote:
>>>
>>> Not surprisingly, I am in favour of this :)
>>
>> I have spent a while thinking about this, as it has considerable
>> ramifications.
>>
>> I don't think we have ever seen a case of an irresponsible committer (could
>> such a thing even exist in the Haskell community?), so I'm in favour.
>>
>>>
>>> Given that there aren't going to be any more 2.8.x releases of
>>> wxWidgets, I'm happy to say:
>>> If you want a stable(ish) wxHaskell, then use the current hackage
>>> release along with the last stable wxWidgets release (2.8.12).
>>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
>>> along with the latest dev wxWidgets release (currently 2.9.2).
>>>
>>> I should note one more time that I'm quite happy to stop supporting
>>> pre 2.9.x support now, I don't know if anyone has any objection to
>>> this?
>>
>> The caveat is that I would like to do one more release on Hackage
>> supporting  2.8.x, as we have a number of valuable bugfixes in the devel
>> branches which would benefit users of 2.8.x. I will try to do this over then
>> next two weeks, so my proposal is...
>>
>> Patches committed until the end of 2011 should be verified on a wxWidgets
>> 2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
>> version number from 0.13.x to 0.14.x.
>>
>> How does this sound?
>
> Well it's the most sensible new year's resolution I've heard thus far :)
>
> I shall continue pushing to my >= wx-2.9 repo on darcs den, in to
> which I'm aiming to get all the patches which are sent out on the
> mailing list as well.
>
> Dave,
>
>>
>> Jeremy
>>
>
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] liberal commit access?

[maciek . makowski]

Last time I tried I wasn't able to get wx 2.8 to build on Windows.
After spending a day trying to sort out gcc running out of memory and
issues with Unicode support I resorted to wxPack. If not for wxPack I
would have probably given up on using wxHaskell altogether. I'm sure
it was possible to build it somehow, but I was not prepared to invest
massive amount of time just to be able to use a GUI library.

Maciek

On Mon, Nov 28, 2011 at 6:24 PM, Alessandro Vermeulen
 wrote:
>>  I fear that the majority of Windows
>> users will be stuck with wxHaskell versions that work with 2.8.
> Well, you can always bundle the wx libraries with your application in that
> case and create your own wxPack. :-)
>
> - Alessandro
> On 28 nov. 2011, at 19:09, Maciek Makowski wrote:
>
>> I don't have a strong opinion on which version of wx should be
>> supported by wxHaskell, as long as there is at least one that works on
>> Windows without the need to compile wxWidgets from source. Until there
>> is a wxPack available for 2.9 I fear that the majority of Windows
>> users will be stuck with wxHaskell versions that work with 2.8.
>>
>> That aside, focusing on supporting a single version of wxWidgets
>> sounds like a reasonable thing to do.
>>
>> Maciek
>>
>> On Mon, Nov 28, 2011 at 5:56 PM, Dave Tapley  wrote:
>>> On 28 November 2011 11:37, Jeremy O'Donoghue  
>>> wrote:
>>>> On 21 November 2011 18:31, Dave Tapley  wrote:
>>>>>
>>>>> Not surprisingly, I am in favour of this :)
>>>>
>>>> I have spent a while thinking about this, as it has considerable
>>>> ramifications.
>>>>
>>>> I don't think we have ever seen a case of an irresponsible committer (could
>>>> such a thing even exist in the Haskell community?), so I'm in favour.
>>>>
>>>>>
>>>>> Given that there aren't going to be any more 2.8.x releases of
>>>>> wxWidgets, I'm happy to say:
>>>>> If you want a stable(ish) wxHaskell, then use the current hackage
>>>>> release along with the last stable wxWidgets release (2.8.12).
>>>>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
>>>>> along with the latest dev wxWidgets release (currently 2.9.2).
>>>>>
>>>>> I should note one more time that I'm quite happy to stop supporting
>>>>> pre 2.9.x support now, I don't know if anyone has any objection to
>>>>> this?
>>>>
>>>> The caveat is that I would like to do one more release on Hackage
>>>> supporting  2.8.x, as we have a number of valuable bugfixes in the devel
>>>> branches which would benefit users of 2.8.x. I will try to do this over 
>>>> then
>>>> next two weeks, so my proposal is...
>>>>
>>>> Patches committed until the end of 2011 should be verified on a wxWidgets
>>>> 2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
>>>> version number from 0.13.x to 0.14.x.
>>>>
>>>> How does this sound?
>>>
>>> Well it's the most sensible new year's resolution I've heard thus far :)
>>>
>>> I shall continue pushing to my >= wx-2.9 repo on darcs den, in to
>>> which I'm aiming to get all the patches which are sent out on the
>>> mailing list as well.
>>>
>>> Dave,
>>>
>>>>
>>>> Jeremy
>>>>
>>>
>>> --
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> ___
>>> wxhaskell-devel mailing list
>>> wxhaskell-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>>>
>>
>> --
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> ___
>> wxhaskell-devel mailing list
>> wxhaskell-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] UI updates from non-UI threads: an addition to wx?

[maciek . makowski]

Getting wxHaskell to handle UI updates from non-UI threads was a
frustrating experience; it's embarassing how long it took me to
realise that the solution presented in this StackOverflow answer:
http://stackoverflow.com/a/3182588/424978 is probably the only viable
one. I've packaged it into a tiny module that provides Gtk2hs-style
`postGUIAsync` function:
https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs.
Is there any interest in incorporating this into wxHaskell proper? It
might save other users some head scratching.

Regards,
Maciek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel