From: Kristof B. <kr...@re...> - 2014-03-09 19:34:09
|
Hi, I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't allow me to create a graphicscontext from a paint event. The reason is the type of the function: graphicsContextCreate :: WindowDC a -> IO (GraphicsContext ()) while the paint event callback takes a DC () as argument, which is more general. It seem wxwidgets needs to know the type of the DC to create a graphicscontext. Also wxwidgets 2.8 doesn't have a function to create one from a memoryDC, but 3.0 has. One solution I came up with would be to replace DC () in the paint-event to MemoryDC (), since it's double buffered, and to PaintDC in a paint-raw event. This callback would also work with a more general function. Unfortunately it fails on Mac-OS since no memoryDc is used in the paint callback. And it still feels like a low level solution, it would be nicer to have a higher level API that can abstract away these problems. Maybe making a new paint callback that already includes the graphiccontext? Also creating a graphicspath from a haskell datatype would be nice. I am willing to help coding this functionality. Regards, Kristof Bastiaensen |
From: Kristof B. <kr...@re...> - 2014-03-09 22:33:59
|
I implemented this idea of adding a new paint event handler: https://github.com/kuribas/wxHaskell/commit/a779f8e7e34fe03822f380c4cdd1aa8a9ed97e81 I could be tidied up, because I duplicated a lot of code... Regards, Kristof Bastiaensen On 09-03-14 20:10, Kristof Bastiaensen wrote: > Hi, > > I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't > allow > me to create a graphicscontext from a paint event. > > The reason is the type of the function: > > graphicsContextCreate :: WindowDC a -> IO (GraphicsContext ()) > > while the paint event callback takes a DC () as argument, which is more > general. It seem wxwidgets needs to know the type of the DC to create > a graphicscontext. Also wxwidgets 2.8 doesn't have a function to create > one from a memoryDC, but 3.0 has. > > One solution I came up with would be to replace DC () in the paint-event > to MemoryDC (), since it's double buffered, and to PaintDC in a paint-raw > event. This callback would also work with a more general function. > Unfortunately it fails on Mac-OS since no memoryDc is used in the paint > callback. > > And it still feels like a low level solution, it would be nicer to have > a higher level > API that can abstract away these problems. Maybe making a new paint > callback that already includes the graphiccontext? Also creating a > graphicspath from a haskell datatype would be nice. > > I am willing to help coding this functionality. > > Regards, > Kristof Bastiaensen > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel |
From: Kristof B. <kr...@re...> - 2014-03-10 11:10:45
|
I have made some changes on my github fork, which I like better: paintRaw now has type: paintRaw :: Event w (PaintDC () -> Rect -> [Rect] -> IO ()) So you can use "graphicsContextCreate paintDC". I removed my new handler paintRawContext, since it isn't needed. This should be mostly compatible with old code, since (PaintDC ()) should work with (DC a) I currently have: paintContext :: Event w (DC () -> GraphicsContext () -> Rect -> IO ()) Maybe it would be better to have the following handler? paintGcdc :: Event w (GCDC () -> Rect -> IO ()) I have read that gcdc implements anti-aliasing, but I didn't try it yet... I also duplicated the code of dcBufferWithRefEx to take an extra graphicscontext argument, but I'd like to find a way to tidy that up... Regards, Kristof On 09-03-14 23:21, Kristof Bastiaensen wrote: > I implemented this idea of adding a new paint event handler: > https://github.com/kuribas/wxHaskell/commit/a779f8e7e34fe03822f380c4cdd1aa8a9ed97e81 > > I could be tidied up, because I duplicated a lot of code... > > Regards, > Kristof Bastiaensen > > On 09-03-14 20:10, Kristof Bastiaensen wrote: >> Hi, >> >> I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't >> allow >> me to create a graphicscontext from a paint event. >> >> The reason is the type of the function: >> >> graphicsContextCreate :: WindowDC a -> IO (GraphicsContext ()) >> >> while the paint event callback takes a DC () as argument, which is more >> general. It seem wxwidgets needs to know the type of the DC to create >> a graphicscontext. Also wxwidgets 2.8 doesn't have a function to create >> one from a memoryDC, but 3.0 has. >> >> One solution I came up with would be to replace DC () in the paint-event >> to MemoryDC (), since it's double buffered, and to PaintDC in a paint-raw >> event. This callback would also work with a more general function. >> Unfortunately it fails on Mac-OS since no memoryDc is used in the paint >> callback. >> >> And it still feels like a low level solution, it would be nicer to have >> a higher level >> API that can abstract away these problems. Maybe making a new paint >> callback that already includes the graphiccontext? Also creating a >> graphicspath from a haskell datatype would be nice. >> >> I am willing to help coding this functionality. >> >> Regards, >> Kristof Bastiaensen >> >> ------------------------------------------------------------------------------ >> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. >> With Perforce, you get hassle-free workflows. Merge that actually works. >> Faster operations. Version large binaries. Built-in WAN optimization and the >> freedom to use Git, Perforce or both. Make the move to Perforce. >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >> _______________________________________________ >> wxhaskell-devel mailing list >> wxh...@li... >> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel |
From: Henk-Jan v. T. <hj...@ch...> - 2014-03-10 13:13:10
|
On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen <kr...@re...> wrote: > I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't > allow > me to create a graphicscontext from a paint event. : : > I am willing to help coding this functionality. It's always great if someone is willing to help improve wxHaskell, but I can't say anything about this, until I have done some studying on the subject. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- |
From: Kristof B. <kr...@re...> - 2014-03-10 14:26:07
|
On 10-03-14 14:13, Henk-Jan van Tuyl wrote: > On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen > <kr...@re...> wrote: > >> I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't >> allow >> me to create a graphicscontext from a paint event. > : > : >> I am willing to help coding this functionality. > > It's always great if someone is willing to help improve wxHaskell, but > I can't say anything about this, until I have done some studying on > the subject. > I see. I am coding this up because I really need it, but feedback is welcome of course. My final version is here: https://github.com/kuribas/wxHaskell If you like it I'll put a pull request. I basically have this, plus helper functions (there was no wxGCDC API). paintGc is new, and the type for paintRaw has changed: class Paint w where -- | Paint double buffered to a device context. The context is always -- cleared before drawing. Takes the current view rectangle (adjusted -- for scrolling) as an argument. paint :: Event w (DC () -> Rect -> IO ()) -- | Paint directly to the on-screen device context. Takes the current -- view rectangle and a list of dirty rectangles as arguments.\ paintRaw :: Event w (PaintDC () -> Rect -> [Rect] -> IO ()) -- | Paint double buffered to a 'GCDC' device context, for -- anti-aliased drawing. The context is always cleared before -- drawing. Takes the current view rectangle (adjusted for -- scrolling) as an argument. paintGc :: Event w (GCDC () -> Rect -> IO ()) -- | Emit a paint event to the specified widget. repaint :: w -> IO () The change of type for the paintRaw event shouldn't pose compatibility problems in most cases, otherwise it would be as simple as changing the type from (DC ()) to (DC a). Kristof |
From: Henk-Jan v. T. <hj...@ch...> - 2015-02-23 14:52:53
|
On Mon, 10 Mar 2014 15:25:59 +0100, Kristof Bastiaensen <kr...@re...> wrote: > On 10-03-14 14:13, Henk-Jan van Tuyl wrote: >> On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen >> <kr...@re...> wrote: >> >>> I need to use a graphicpath to draw bezier curves, but wxhaskell >>> doesn't >>> allow >>> me to create a graphicscontext from a paint event. >> : >> : >>> I am willing to help coding this functionality. >> >> It's always great if someone is willing to help improve wxHaskell, but >> I can't say anything about this, until I have done some studying on >> the subject. >> > I see. I am coding this up because I really need it, but feedback > is welcome of course. My final version is here: > > https://github.com/kuribas/wxHaskell > > If you like it I'll put a pull request. > I have merged your updates with the current wxHaskell in my own branch[0]; it seems that wxWidgets must be recompiled with wxUSE_GRAPHICS_CONTEXT defined, how did you accomplish that? Regards, Henk-Jan van Tuyl [0] https://github.com/HJvT/wxHaskell -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- |
From: Kristof B. <kr...@re...> - 2015-02-24 12:36:34
|
On 23-02-15 15:34, Henk-Jan van Tuyl wrote: > On Mon, 10 Mar 2014 15:25:59 +0100, Kristof Bastiaensen > <kr...@re...> wrote: > >> On 10-03-14 14:13, Henk-Jan van Tuyl wrote: >>> On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen >>> <kr...@re...> wrote: >>> >>>> I need to use a graphicpath to draw bezier curves, but wxhaskell >>>> doesn't >>>> allow >>>> me to create a graphicscontext from a paint event. >>> : >>> : >>>> I am willing to help coding this functionality. >>> >>> It's always great if someone is willing to help improve wxHaskell, but >>> I can't say anything about this, until I have done some studying on >>> the subject. >>> >> I see. I am coding this up because I really need it, but feedback >> is welcome of course. My final version is here: >> >> https://github.com/kuribas/wxHaskell >> >> If you like it I'll put a pull request. >> > > I have merged your updates with the current wxHaskell in my own > branch[0]; it seems that wxWidgets must be recompiled with > wxUSE_GRAPHICS_CONTEXT defined, how did you accomplish that? > > Regards, > Henk-Jan van Tuyl > > [0] https://github.com/HJvT/wxHaskell > > I compiled wxWidgets from source, since the version was too old on my system. Regards, Kristof Bastiaensen |