wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] Haskell Platform

[Guy <guy...@ya...>]

On 12/06/2011 20:07, Eric Y. Kow wrote:
> On Sun, Jun 12, 2011 at 19:54:13 +0300, Guy wrote:
>> I'm trying to get a GUI package included in the Haskell Platform. The
>> platform's inclusion policy requires that (one
>> of?) the package's official maintainers supports the proposal.
>
> We may need to think strategically about this.
>
> gtk2hs is much more popular than wxHaskell, and by and large coders
> seem not to be particularly concerned about getting as close to native
> UI as possible (and they'll just point out that you can't anyway).

I made the same post to the gtk2hs list. However, gtk2hs doesn't install on the current version of cabal, and 
development there seems to have stalled (the fix has been known for several months), so I'm not too positive on that front.

Re: [wxhaskell-users] Haskell Platform

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

On Sun, Jun 12, 2011 at 19:54:13 +0300, Guy wrote:
> I'm trying to get a GUI package included in the Haskell Platform. The
> platform's inclusion policy requires that (one 
> of?) the package's official maintainers supports the proposal.

We may need to think strategically about this.

gtk2hs is much more popular than wxHaskell, and by and large coders
seem not to be particularly concerned about getting as close to native
UI as possible (and they'll just point out that you can't anyway).

I wonder if to make this happen, we would perhaps need to wait for
wxHaskell to mature a little more, wait for the installation procedure
to be a bit nicer, maybe get some way for gtk2hs code to "just work"
on wx

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

[wxhaskell-users] Haskell Platform

[Guy <guy...@ya...>]

I'm trying to get a GUI package included in the Haskell Platform. The platform's inclusion policy requires that (one 
of?) the package's official maintainers supports the proposal.

Are any WxHaskell maintainers interested?

Re: [wxhaskell-users] [wxhaskell-devel] wxHaskell repo restored to code.haskell.org

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

On 3 June 2011 12:44, <E....@br...> wrote:

> On Fri, Jun 03, 2011 at 12:14:58 +0100, Jeremy O'Donoghue wrote:
> >    - Bugfix for assert error in SearchDynamicEventTable which was found
> in
> >    debug builds. I believe that this is a proper fix for an issue Eric
> noted a
> >    couple of months back.
>
> It's not just debug builds (of what?),


Of wxWidgets itself. I don't see the assertion for retail builds. I *do* see
the assertion on debug builds for Windows, so I don't think it's a Mac
issue.

but basically the scenario where
> you naively type "cabal install wx" on MacOS after having installed the
> Haskell Platform and nothing else.   Macs ship with wxWidgets, albeit
> with this crucial bit of missing functionality.
>
> I'm a bit concerned that this may result in silently-does-the-wrong-thing
> errors
>
> +  if (evtHandler->GetDynamicEventTable() != NULL)
> +    found = evtHandler->SearchDynamicEventTable( event );
>
> As I'd discovered to my dismay, without this trawl through the non-existent
> dynamic event table, things like scrolled list boxes stop responding to
> events.
>
> http://www.mail-archive.com/wxh...@li.../msg00580.html
>

This is a bit more worrying - it's likely to be seen on other platforms as
well. I didn't see the problem on any of the (few) test cases I ran, but it
sounds more like a failure of what might laughably be called my test regime
than a Mac specific issue.


> If I understand the patch correctly, the result of this is that (A)
> users would be able to happily install wxHaskell on Mac without any
> prerequisites, but (B) if they were to use such a widget, it would just
> silently not-work.
>

No - I think it would silently not work everywhere :-(


> The even better solution would be for somebody to go understand how the
> event
> handling code works and propose a solution that works without the missing
> dynamic event table
>

That's probably a better bet. I have the impression that you're not really
supposed to call wxEvent::SearchDynamicEventTable() from outside anyway.
They seem to have gone to some lengths to not document it in wxWidgets.

I will have a go at understanding the event handling code. Wish me luck,
I'll probably need it...

Jeremy

Re: [wxhaskell-users] [wxhaskell-devel] wxHaskell repo restored to code.haskell.org

[<E....@br...>]

On Fri, Jun 03, 2011 at 12:14:58 +0100, Jeremy O'Donoghue wrote:
>    - Bugfix for assert error in SearchDynamicEventTable which was found in
>    debug builds. I believe that this is a proper fix for an issue Eric noted a
>    couple of months back.

It's not just debug builds (of what?), but basically the scenario where
you naively type "cabal install wx" on MacOS after having installed the
Haskell Platform and nothing else.   Macs ship with wxWidgets, albeit
with this crucial bit of missing functionality.

I'm a bit concerned that this may result in silently-does-the-wrong-thing
errors

+  if (evtHandler->GetDynamicEventTable() != NULL)
+    found = evtHandler->SearchDynamicEventTable( event );

As I'd discovered to my dismay, without this trawl through the non-existent
dynamic event table, things like scrolled list boxes stop responding to events.
  http://www.mail-archive.com/wxh...@li.../msg00580.html

If I understand the patch correctly, the result of this is that (A)
users would be able to happily install wxHaskell on Mac without any
prerequisites, but (B) if they were to use such a widget, it would just
silently not-work.

Much better to blow up from the beginning, I'm afraid :-(

Perhaps what we need is to use this opportunity to give a more friendly
error, something like this pseudocode
 
else {
  friendlyError $ "Your wxWidgets is missing a feature needed by wxHaskell."
               ++ "See http://haskell.org/haskell/wxHaskell for instructions"
               ++ "on installing a complete wxWidgets on your computer"
}

The even better solution would be for somebody to go understand how the event
handling code works and propose a solution that works without the missing
dynamic event table

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

Re: [wxhaskell-users] wxHaskell repo restored to code.haskell.org

[Guy <guy...@ya...>]

On 03/06/2011 14:14, Jeremy O'Donoghue wrote:
> The main issue is that wxWidgets 2.9 is impossible to build on my Windows machine in Monolithic mode (runs out of
> memory).

This is reported as a GHC memory leak
http://hackage.haskell.org/trac/ghc/ticket/4800

[wxhaskell-users] wxHaskell repo restored to code.haskell.org

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

Hi all,

I'm pleased to announce that as of last night UK time, and with the help of
a Google Talk mini-hackathon from Eric (thanks Eric :-), wxHaskell has been
restored to code.haskell.org.

Compared to the released version on cabal, this contains the following
changes:

   - Change to hasked darcs repo, whcih should make complete repo pulls much
   quicker.
   - Patches from Eric to enable wxHaskell to build against Haskell Platform
   2011.2.0.1
   - Removal of quite a few deprecated and removed functions, particularly
   ODBC bindings.
   - Support build with both wxWidgets 2.8.x and 2.9.x (see below)
   - Remove a number of warnings
   - Change Cabal license type from LGPL to 'Other'. This is *not* a license
   change: wxHaskell has always been licensed under the wxWidgets license.
   While this is very similar to LGPL, it differs in one absolutely vital area,
   which is that it explicitly allows for binary distribution of closed source
   programs which simply use wxHaskell, and I wanted our cabal stanzas to
   reflect this..
   - Version bump to 0.13 to reflect support for wxWidgets 2.9
   - Bugfix for assert error in SearchDynamicEventTable which was found in
   debug builds. I believe that this is a proper fix for an issue Eric noted a
   couple of months back.

I would like to make a new wxHaskell release fairly shortly, but there are a
few issues which *may* need changes before I can do so - I'd appreciate
testers to check whether there is a problem.

The main issue is that wxWidgets 2.9 is impossible to build on my Windows
machine in Monolithic mode (runs out of memory). This, of course, led to a
cascade of problems which are related to the fact that the external
wx-config program we use to determine what libraries are used on Windows has
many bugs and doesn't properly support wxWidgets 2.9 (or 2.8 when compiled
non-monolithic). Because of this there are some nasty hacks in the wxcore
Setup.hs to pull in the correct libraries, and these may cause problems with
the pre-compiled wxWidgets provided on non-Windows platforms. Please let me
know if this is the case.

I built wxWidgets (2.8.11 and 2.9.1) as follows:
Ensure that USE_HTML=1 and USE_XRC=1 are set in setup.h
> make -f makefile.gcc USE_OPENGL=1 UNICODE=1 SHARED=1 BUILD=debug

As a reminder, here's how to build wxHaskell from source, assuming that you
have wxWidgets installed with the WXWIN and WXCFG environment variables set
to point to the wxWidgets root directory and configuration respectively:

cd <place where you plan to build>
darcs get http://code.haskell.org/wxhaskell/
cd wxhaskell/wxdirect
runhaskell Setup.hs configure
runhaskell Setup.hs build
runhaskell Setup.hs install
cd ../wxcore
runhaskell Setup.hs configure
runhaskell Setup.hs build
runhaskell Setup.hs install
cd ../wx
runhaskell Setup.lhs configure
runhaskell Setup.lhs build
runhaskell Setup.lhs install

Windows users will need to run the install stanzas from within a command
windows with administrative priviledge. Note also that on Windows, your PATH
needs to have the wxWidgets DLLs present if you want to actually run
anything.

Just for information, I have (non-tested) patches on my machine for the
following:

   - Wrapper for wxDisplay (requested by Brian Victor)
   - {H|V}Slider which supports swapped order - code graciously provided by
   Henning Thielmann
   - Wrapper OpenGL contexts

These will be added to the repo as soon as I have convinced myself that they
work on more than one machine ;-)

Thanks to all for your patience.

Best regards
Jeremy

Re: [wxhaskell-users] Change the range of a spin control

[Guy <guy...@ya...>]

On 03/06/2011 11:19, Jeremy O'Donoghue wrote:
> The API documentation hasn't kept up with wxHaskell itself :-(

Isn't it auto-generated by Haddock?

Re: [wxhaskell-users] Change the range of a spin control

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

Probably too late to help, but try

spinCtrlSetRange :: SpinCtrl a -> Int -> Int -> IO ()

The API documentation hasn't kept up with wxHaskell itself :-(

On 10 May 2011 10:15, Guy <guy...@ya...> wrote:

> On 10/05/2011 11:28, Guy wrote:
> > How can I change the range of a spin control after it's been created?
>
> Note: WxWidgets has a function wxSpinCtrl::SetRange, but I can't find the
> wxHaskell wrapper for it.
>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

Re: [wxhaskell-users] Property sheet

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

On Wed, Jun 01, 2011 at 09:09:55 +0100, Jeremy O'Donoghue wrote:
> wxPropertyGrid is new in wxWidgets 2.9 - at present, none of the 2.9 new
> features has been wrapped. wxPropertySheetDialog is present in 2.8, possibly
> earlier. I will try to get around to wrapping it shortly.

[Sorry, my remark is neither new nor helpful]

I wish there was a magical way for people to widgets on their own, that
over time we could collect all the ad-hoc wrappings and either bundle
them with wx or some sort of wx-extras package.

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

Re: [wxhaskell-users] newbie question, why clientSize doesn't affect textEntry?

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

The full explanation is a bit tricky (tricky enough that I don't fully
understand or I would have fixed it!), but results from the way in which
Layout works. Layout is a neat idea, but has a number of quirks. The main
thing to realize is that Layout creates an hierarchy of Sizer instances
which contain your control instances. The interaction between the Sizers and
control size constraints can be tricky to fathom, but basically the Sizer
constraints seem to override clientsize directives.

My best advice would be to use either Layout and nothing else (as Carlos
suggests) or use Sizers manually and ignore Layout. I used this alternative
approach in m Custom Control tutorial - see
http://wewantarock.wordpress.com/2010/01/10/custom-controls-in-wxhaskell-part-2/

Regards
Jeremy

On 31 May 2011 23:05, carlos gomez <car...@gm...> wrote:

> I don't understand too. Looks like some misterious thing is happening.
> But you can use the 'mimsize' layout funcion from WXCore in order to get
> what you want.
>
> Here the code:
>
>
> module Main where
>
> import Graphics.UI.WX
>
> main::IO()
>
> main = start gui
>
> gui :: IO ()
>
> gui = do f <- frame [text := "timer"]
>          panel <- panel f [clientSize := sz 200 100]
>          hr  <- textEntry   panel
>                             [ text := "hour"
>                             , clientSize := sz 10 10
>                             ]
>          min <- button      panel
>                             [ text := "min"
>                             , clientSize := sz 10 10
>                             ]
>          sec <- textEntry   panel
>                             [ text := "sec"
>                             , clientSize := sz 10 10
>                             ]
>          -- layout
>          set panel [layout := margin 10 $  row 1 [ minsize (sz 10 10) $
> widget hr
>                                                  , widget min
>                                                  , minsize (sz 10 10) $
> widget sec
>                                                  ]
>                    ]
>          set f [layout := widget panel]
>
>
>
> On 30 May 2011 05:49, 诺铁 <no...@gm...> wrote:
>
>> Hi,
>>      I am learning wxHaskell,and trying to create a small timer app. I
>> don't understand why in following code ,clientSize only affect button
>> control
>>
>> module Main where
>>
>>
>> import Graphics.UI.WX
>>
>>
>> main::IO()
>>
>>
>> main = start gui
>>
>>
>> gui :: IO ()
>>
>>
>> gui =  do
>>
>>
>>         f <- frame [text := "timer"]
>>
>>
>>         panel <- panel f [clientSize := sz 200 100]
>>
>>
>>         hr  <- textEntry panel [text := "hour",clientSize := sz 10 10]
>>
>>
>>         min <- button panel [text := "min",clientSize := sz 10 10]
>>
>>
>>         sec <- textEntry panel [text := "sec",clientSize := sz 10 10]
>>
>>
>>         -- layout
>>
>>
>>         set panel [layout := margin 10 $  row 1 [widget hr,widget min,widget sec]]
>>
>>
>>         set f [layout := widget panel]
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is
>> safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> wxhaskell-users mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

Re: [wxhaskell-users] Property sheet

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

Hi Joel,

On 1 June 2011 04:19, Joel Shellman <jo...@me...> wrote:

> Is there a property sheet/grid/panel type of widget available via
> wxHaskell?
>
> I saw a wxPropertyGrid and wxPropertySheetDialog in the wxWidgets
> docs, but couldn't find anything like that in the wxHaskell docs on
> hackage.
>

At this time, wxPropertyGrid and wxPropertySheetDialog are not wrapped.

wxPropertyGrid is new in wxWidgets 2.9 - at present, none of the 2.9 new
features has been wrapped. wxPropertySheetDialog is present in 2.8, possibly
earlier. I will try to get around to wrapping it shortly.


Regards
Jeremy

Re: [wxhaskell-users] where should I ask user questions about wxHaskell

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

On 1 June 2011 05:09, 诺铁 <no...@gm...> wrote:

> I should have subscribe to this list. I tried to subscribe again,and
> recieve
>
> "An attempt was made to subscribe your address to the mailing list
> wxh...@li....  You are already subscribed to this
> mailing list."
>
> list manager,would please check my subscribe status,thank you.
>

You are subscribed, and your 'moderate' flag has been cleared.


> On Wed, Jun 1, 2011 at 6:44 AM, Henk-Jan van Tuyl <hj...@ch...>wrote:
>
>> On Tue, 31 May 2011 22:13:42 +0200, 诺铁 <no...@gm...> wrote:
>>
>>  Hi,
>>>    it seems that this list require approval,which is quite slow. so I
>>> guess
>>> maybe it's not right place to ask user questions. so where is the right
>>> place?
>>>
>>
New subscribers to the list always have a 'moderate' flag set, so your first
posting is held in a queue to make sure that it is relevant. After your
first (relevant) post to the list, mails are no longer moderated, as you
will have noticed - this mail thread has appeared on the list without delay.

I accept that this is an inconvenience for new list users - I know that when
I have a question I always want an immediate answer, and it can be
frustrating when this doesn't happen. Unfortunately, over 95% of mail sent
to wxHaskell lists is spam, so moderation is an essential part of keeping
the list relevant and useful.

I try to moderate reasonably frequently, but you need to know that:

   1. I am located in the UK, so mail sent while I am asleep definitely
   won't get moderated until I wake up! I typically look to see if I should
   moderate once a day, so again, and depending on timing, you may be unlucky
   and get your question delayed.
   2. I am by far the moderator on the list, so if I'm away or very busy,
   things happen more slowly than daily. Actually, Eric helps out as a courtesy
   when my response is slow, but it's only a courtesy (i.e. the responsibility
   for responsiveness is mine)
   3. I am pretty busy outside of wxHaskell with a fairly heavy day job (I
   am the software lead on two significant, non-Haskell, projects with a major
   fabless semiconductor company) and a young family. Inevitably, these have to
   come first.

The moderation flag only applies to new list members, so I don't believe you
will see the problem again.


> If you subscribe to this list, your e-mails do not require approval; it is
>> the right place for user questions.
>>
>
This is definitely the correct place for questions.

I would also like to mention that the wxHaskell community is fairly small,
although we try to follow the example of the wider Haskell community in
being as helpful as possible. This means that there may not be so many
people who can give a good answer to your question.

Best regards
Jeremy

Re: [wxhaskell-users] where should I ask user questions about wxHaskell

[诺铁 <no...@gm...>]

I should have subscribe to this list. I tried to subscribe again,and recieve

"An attempt was made to subscribe your address to the mailing list
wxh...@li....  You are already subscribed to this
mailing list."

list manager,would please check my subscribe status,thank you.

On Wed, Jun 1, 2011 at 6:44 AM, Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Tue, 31 May 2011 22:13:42 +0200, 诺铁 <no...@gm...> wrote:
>
>  Hi,
>>    it seems that this list require approval,which is quite slow. so I
>> guess
>> maybe it's not right place to ask user questions. so where is the right
>> place?
>>
>
> If you subscribe to this list, your e-mails do not require approval; it is
> the right place for user questions.
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> --
>

[wxhaskell-users] Property sheet

[Joel S. <jo...@me...>]

Is there a property sheet/grid/panel type of widget available via wxHaskell?

I saw a wxPropertyGrid and wxPropertySheetDialog in the wxWidgets
docs, but couldn't find anything like that in the wxHaskell docs on
hackage.

Re: [wxhaskell-users] where should I ask user questions about wxHaskell

[Henk-Jan v. T. <hj...@ch...>]

On Tue, 31 May 2011 22:13:42 +0200, 诺铁 <no...@gm...> wrote:

> Hi,
>     it seems that this list require approval,which is quite slow. so I  
> guess
> maybe it's not right place to ask user questions. so where is the right
> place?

If you subscribe to this list, your e-mails do not require approval; it is  
the right place for user questions.

Regards,
Henk-Jan van Tuyl


-- 
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

Re: [wxhaskell-users] newbie question, why clientSize doesn't affect textEntry?

[carlos g. <car...@gm...>]

I don't understand too. Looks like some misterious thing is happening.
But you can use the 'mimsize' layout funcion from WXCore in order to get
what you want.

Here the code:


module Main where

import Graphics.UI.WX

main::IO()

main = start gui

gui :: IO ()

gui = do f <- frame [text := "timer"]
         panel <- panel f [clientSize := sz 200 100]
         hr  <- textEntry   panel
                            [ text := "hour"
                            , clientSize := sz 10 10
                            ]
         min <- button      panel
                            [ text := "min"
                            , clientSize := sz 10 10
                            ]
         sec <- textEntry   panel
                            [ text := "sec"
                            , clientSize := sz 10 10
                            ]
         -- layout
         set panel [layout := margin 10 $  row 1 [ minsize (sz 10 10) $
widget hr
                                                 , widget min
                                                 , minsize (sz 10 10) $
widget sec
                                                 ]
                   ]
         set f [layout := widget panel]



On 30 May 2011 05:49, 诺铁 <no...@gm...> wrote:

> Hi,
>      I am learning wxHaskell,and trying to create a small timer app. I
> don't understand why in following code ,clientSize only affect button
> control
>
> module Main where
>
> import Graphics.UI.WX
>
> main::IO()
>
> main = start gui
>
> gui :: IO ()
>
> gui =  do
>
>         f <- frame [text := "timer"]
>
>         panel <- panel f [clientSize := sz 200 100]
>
>         hr  <- textEntry panel [text := "hour",clientSize := sz 10 10]
>
>         min <- button panel [text := "min",clientSize := sz 10 10]
>
>         sec <- textEntry panel [text := "sec",clientSize := sz 10 10]
>
>         -- layout
>
>         set panel [layout := margin 10 $  row 1 [widget hr,widget min,widget sec]]
>
>         set f [layout := widget panel]
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

[wxhaskell-users] where should I ask user questions about wxHaskell

[诺铁 <no...@gm...>]

Hi,
    it seems that this list require approval,which is quite slow. so I guess
maybe it's not right place to ask user questions. so where is the right
place?

[wxhaskell-users] newbie question, why clientSize doesn't affect textEntry?

[诺铁 <no...@gm...>]

Hi,
     I am learning wxHaskell,and trying to create a small timer app. I don't
understand why in following code ,clientSize only affect button control

module Main where

import Graphics.UI.WX

main::IO()
main = start gui

gui :: IO ()
gui =  do
        f <- frame [text := "timer"]
        panel <- panel f [clientSize := sz 200 100]
        hr  <- textEntry panel [text := "hour",clientSize := sz 10 10]
        min <- button panel [text := "min",clientSize := sz 10 10]
        sec <- textEntry panel [text := "sec",clientSize := sz 10 10]
        -- layout
        set panel [layout := margin 10 $  row 1 [widget hr,widget
min,widget sec]]
        set f [layout := widget panel]

Re: [wxhaskell-users] OpenGL support

[Henk-Jan v. T. <hj...@ch...>]

On Thu, 26 May 2011 12:28:58 +0200, Jeremy O'Donoghue  
<jer...@gm...> wrote:

> *Question for the general user community of wxHaskell - is the addition  
> of
> an OpenGL target dependency OK with you?*

I hope OpenGL is re-introduced in wxHaskell; I am currently not using  
OpenGL, I but I will need it in the future. I am on Windows.

Regards,
Henk-Jan van Tuyl


-- 
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

Re: [wxhaskell-users] OpenGL support

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

On 26 May 2011 12:31, Henning Thielemann
<sch...@he...>wrote:

> Jeremy O'Donoghue schrieb:
>
> > On 25 May 2011 21:04, Joel Shellman <jo...@me...
> > <mailto:jo...@me...>> wrote:
> >
> >     What would it take to get full support for OpenGL in wxHaskell? My
> >     understanding is that wxWidgets supports it, we just need the Haskell
> >     binding for it, right? And I think it used to be there in a previous
> >     version of wxHaskell.
> >
> >
> > Putting support for OpenGL canvas into wxHaskell is very
> > straightforward. I could do the code in about an hour.
>
> Would it be possible to implement this in a separate package? wx-opengl
> or so? I didn't need OpenGL support so far.
>

This would need major changes to wxdirect, as it currently isn't really set
up to wrap individual packages. A good thing to do, but I fear I may not
have time to do it in the near future.

We'll develop OpenGL support in a branch for now, while I get consensus from
the community on the best way to do the packaging.

Jeremy

Re: [wxhaskell-users] OpenGL support

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

On 26 May 2011 11:38, Eric Kow <eri...@gm...> wrote:

> What are the implications (all three platforms)?
>
> My general priority is just-workingness.  Right now, installing
> wxHaskell on Mac is still a bit of pain.  I think we've got it boiled
> down to
>
>  1. install homebrew
>  2. brew install haskell-platform
>  3. brew install wxmac
>  4. [when next release is out] cabal install wx
>
> And I would be nervous about anything that deviates significantly
> from that
>

I know the build implications for Windows (wxUSE_GLCANVAS in setup.h and
USE_OPENGL=1 when compiling). A quick read up on the subject implied that
HOPENGL recommends using a different (Open Source) GLUT wrapper on Windows,
but I don't know what that means in practice.

Don't know for Mac (ISTR Mac has about the best OpenGL story of all common
platforms)

I fear that Linux will be distro-dependent, which is the worst of all
possible worlds!

That's why I need someone to convince me that it doesn't make the install
process too complicated.


> It might be a good idea to adopt the strike-whilst-iron-hot and
> reduce-friction mentality here.  In other words, rather than waiting
> indefinitely for our good but overloaded cho admins to get to it,
> just stick the branch up at darcsden in the interim so that people
> who are already keen to get hacking can get hacking (before they
> lose interest and wander off) :-)
>

I'm thinking seriously of hosting wxHaskell at darcsden anyway, since
branch/fork support is a very nice thing to have.

Currently sorting out event handling so that it works for both wxWidgets
2.9.x and 2.8.x. We support too many events which no longer exist and not
enough of those which have been added since 2.4.x :-( Will post an updated
repo once I have this working, followed by a fork which supports GLCanvas

Jeremy

Re: [wxhaskell-users] OpenGL support

[Henning T. <sch...@he...>]

Jeremy O'Donoghue schrieb:

> On 25 May 2011 21:04, Joel Shellman <jo...@me...
> <mailto:jo...@me...>> wrote:
> 
>     What would it take to get full support for OpenGL in wxHaskell? My
>     understanding is that wxWidgets supports it, we just need the Haskell
>     binding for it, right? And I think it used to be there in a previous
>     version of wxHaskell.
> 
> 
> Putting support for OpenGL canvas into wxHaskell is very
> straightforward. I could do the code in about an hour.

Would it be possible to implement this in a separate package? wx-opengl
or so? I didn't need OpenGL support so far.

Re: [wxhaskell-users] OpenGL support

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

Hi,

On Thu, May 26, 2011 at 11:28:58 +0100, Jeremy O'Donoghue wrote:
> *Question for the general user community of wxHaskell - is the addition of
> an OpenGL target dependency OK with you?* (apologies for shouting, but I
> don't want this to be missed by speed readers!)

What are the implications (all three platforms)?

My general priority is just-workingness.  Right now, installing
wxHaskell on Mac is still a bit of pain.  I think we've got it boiled
down to

  1. install homebrew
  2. brew install haskell-platform
  3. brew install wxmac
  4. [when next release is out] cabal install wx

And I would be nervous about anything that deviates significantly
from that

> Joel, I have a proposal for you: if I put support for wxGLCanvas and
> wxGLContext into a branch in the wxHaskell repo (when it gets restored)

It might be a good idea to adopt the strike-whilst-iron-hot and
reduce-friction mentality here.  In other words, rather than waiting
indefinitely for our good but overloaded cho admins to get to it,
just stick the branch up at darcsden in the interim so that people
who are already keen to get hacking can get hacking (before they
lose interest and wander off) :-)

Not sure if this sort of mentality is right; it does add a bit of
mess!  But I suspect that these sorts of trivial delays can be
costly.

Thanks for keeping this alive! We can do it! Rah! :-)

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

Re: [wxhaskell-users] OpenGL support

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

Hi Joel,

On 25 May 2011 21:04, Joel Shellman <jo...@me...> wrote:

> What would it take to get full support for OpenGL in wxHaskell? My
> understanding is that wxWidgets supports it, we just need the Haskell
> binding for it, right? And I think it used to be there in a previous
> version of wxHaskell.
>

Putting support for OpenGL canvas into wxHaskell is very straightforward. I
could do the code in about an hour.

The problem is to make wxHaskell compile and link successfully on all
supported platforms with as little user intervention as possible (basically,
I want anyone with wxWidgets to be able to 'cabal install wx' and everything
will work).

The first problem is that wxWidgets may or may not be built with OpenGL
support on any given platform, and wxDirect, which does much of the code
generation, doesn't support conditional compilation.

*Question for the general user community of wxHaskell - is the addition of
an OpenGL target dependency OK with you?* (apologies for shouting, but I
don't want this to be missed by speed readers!)

The impact is mostly to Windows users, since Windows wxWidgets builds don't
support OpenGL by default (it's only a case of adding wxUSE_GLCANVAS in
setup.h and adding USE_OPENGL=1 on the build command line), but there may be
Linux distros which don't build their wx packages with OpenGL - I don't
know).

The second problem is that wxWidgets only gives you a canvas, so we would
need to make sure that wxHaskell plays nicely with a Haskell OpenGL binding.
I don't have time to do this.

Joel, I have a proposal for you: if I put support for wxGLCanvas and
wxGLContext into a branch in the wxHaskell repo (when it gets restored), I
need evidence that it is usable on all of the supported wxHaskell targets
(i.e. Linux/Gtk, Windows, Mac) - that means working out the dependencies,
how to build and ensuring that there is a working sample application. Are
you able to co-ordinate this activity?

If you (or anyone else) can do this, my side of the bargain is that I'll
mainline OpenGL support in wxHaskell and ensure that all of the
documentation is updated to reflect whatever is needed, blog on how to use
it and generally make sure that there is information out there on which
everyone can rely.

Regards
Jeremy