Re: [wxhaskell-devel] using graphicscontext inside a paint event
On Mon, 10 Mar 2014 15:25:59 +0100, Kristof Bastiaensen kris...@resonata.be wrote: On 10-03-14 14:13, Henk-Jan van Tuyl wrote: On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen kris...@resonata.be 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 -- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] using graphicscontext inside a paint event
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=122218951iu=/4140/ostg.clktrk ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net 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=122218951iu=/4140/ostg.clktrk ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] using graphicscontext inside a paint event
On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen kris...@resonata.be 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 -- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] using graphicscontext inside a paint event
On 10-03-14 14:13, Henk-Jan van Tuyl wrote: On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen kris...@resonata.be 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 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] using graphicscontext inside a paint event
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=122218951iu=/4140/ostg.clktrk ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] using graphicscontext inside a paint event
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=122218951iu=/4140/ostg.clktrk ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net 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=122218951iu=/4140/ostg.clktrk ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
