You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(6) |
Jul
(27) |
Aug
(17) |
Sep
|
Oct
(8) |
Nov
(23) |
Dec
(17) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(43) |
Feb
(12) |
Mar
(10) |
Apr
(12) |
May
(16) |
Jun
(15) |
Jul
(15) |
Aug
|
Sep
(1) |
Oct
(25) |
Nov
(39) |
Dec
(7) |
2004 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
(48) |
May
(44) |
Jun
(17) |
Jul
(38) |
Aug
(42) |
Sep
(17) |
Oct
(12) |
Nov
(7) |
Dec
(14) |
2005 |
Jan
(67) |
Feb
(59) |
Mar
(47) |
Apr
(78) |
May
(15) |
Jun
(59) |
Jul
(38) |
Aug
(28) |
Sep
(11) |
Oct
(16) |
Nov
(27) |
Dec
(7) |
2006 |
Jan
(11) |
Feb
(17) |
Mar
(16) |
Apr
(8) |
May
(16) |
Jun
(22) |
Jul
(5) |
Aug
(1) |
Sep
(6) |
Oct
(32) |
Nov
(42) |
Dec
(24) |
2007 |
Jan
(44) |
Feb
(25) |
Mar
(54) |
Apr
(21) |
May
(47) |
Jun
(13) |
Jul
(30) |
Aug
(34) |
Sep
(9) |
Oct
(37) |
Nov
(28) |
Dec
(27) |
2008 |
Jan
(21) |
Feb
(17) |
Mar
(38) |
Apr
(26) |
May
(15) |
Jun
(44) |
Jul
(62) |
Aug
(49) |
Sep
(66) |
Oct
(86) |
Nov
(43) |
Dec
(128) |
2009 |
Jan
(134) |
Feb
(120) |
Mar
(113) |
Apr
(39) |
May
(121) |
Jun
(81) |
Jul
(79) |
Aug
(87) |
Sep
(54) |
Oct
(40) |
Nov
(26) |
Dec
(21) |
2010 |
Jan
(30) |
Feb
(44) |
Mar
(57) |
Apr
(46) |
May
(117) |
Jun
(69) |
Jul
(51) |
Aug
(103) |
Sep
(62) |
Oct
(24) |
Nov
(37) |
Dec
(50) |
2011 |
Jan
(21) |
Feb
(12) |
Mar
(16) |
Apr
(9) |
May
(25) |
Jun
(19) |
Jul
(13) |
Aug
(8) |
Sep
(31) |
Oct
(26) |
Nov
(16) |
Dec
(10) |
2012 |
Jan
(5) |
Feb
(9) |
Mar
(19) |
Apr
(17) |
May
(7) |
Jun
(16) |
Jul
(11) |
Aug
(14) |
Sep
(10) |
Oct
(1) |
Nov
(10) |
Dec
(38) |
2013 |
Jan
(9) |
Feb
(16) |
Mar
(11) |
Apr
(1) |
May
(3) |
Jun
(3) |
Jul
|
Aug
(11) |
Sep
(11) |
Oct
(3) |
Nov
(4) |
Dec
(8) |
2014 |
Jan
|
Feb
(4) |
Mar
(13) |
Apr
(3) |
May
(17) |
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(4) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Axel S. <Axe...@in...> - 2013-06-22 07:33:23
|
Hi Inaki, that's very interesting to see. It seems to me that the long-term future of Gtk2Hs should probably embrace auto generating code using introspection more. I think was is needed, in particular with respect to documentation, is a way to merge in hand-written stuff into the generated code. This could be specific documentation or a replacement for certain function etc. The most generic approach would be some sort of (XML?) document that is read in when generating the code. An alternative: Duncan Coutts once implemented this generator that created bindings from some XML description. It annotated each function with a hash code that was computed from the auto-generated code. If the Gtk2Hs maintainer changes the function by hand but the hash code of the generated function stayed the same, the generated would simply retain the modified version. There are certain things that are completely written by hand, so these always need to be kept alongside the generated code. Examples are the TreeView models. My 2p, Axel On 21.06.2013, at 23:16, Inaki Garcia Etxebarria <ga...@gm...> wrote: > Dear all, > > For the last few weeks, as an exercise in learning Haskell better, I > have been playing around with haskell-gi, adding support for a bunch of > features. I based my work on the versions started by Will Thompson, > found in > https://gitorious.org/haskell-gi > and > http://git.rhydd.org/?p=haskell-gi;a=summary > > Thanks to the excellent foundations there, and with a bit of work, I > think that the code is now reaching a stage that it may start to be > useful in actually generating bindings (at least for adventurous > folks :) ), hence this message. You can find my changes at > https://github.com/garetxe/haskell-gi > > I tried to model the generated API on gtk2hs as much as possible, > although there are some divergences here and there. You can view some > examples of the generated code for the gtk3 stack at > http://cern.ch/inaki/haskell-gi > (Some example of actual usage of the bindings is given below) > > What works: > ----------- > + Typeclasses for modeling the GObject hierarchy, so if you have a > GtkButton "button" and want to pass it to a function expecting a > GtkWidget it will work without casting (see below for examples). > + Signals. > + Proper reference counting for GObjects and boxed structs/unions, > including automatic handling of ownership transfer on function > calls/returns. > + Automatic conversion between C types and Haskell types. (So, for > example, GLists are converted to ordinary Haskell lists.) > + GError handling, by throwing exceptions. Same notation as in gtk2hs, > with the addition of a type-specific (catch/handle)GErrorJustDomain, > named (catch/handle)DBusError, for instance. > + Setting/getting GObject properties. A nice feature is that the > readable/writable/constructOnly constraint are enforced at compile time, > so if you try to write a read-only properly you will get a (hopefully > clear) compile time error. > + "new" notation for constructing GObjects (see example of usage below, > feels nice to use). > > What doesn't: > ------------- > + GHash type elements are not converted to native Haskell types yet. > + GVariant and GHash valued properties are not yet supported. > + Struct/union field accessors (I will probably tackle this next). > + Structs/unions which are not boxed. > + Callbacks. > + Documentation. This is a big one, not sure what to do here. Since the > generated API is automatically translated from C, the C API > documentation is pretty useful already if one squints, but maybe we can > do better (perhaps reusing the gtk2hs documentation when it applies?). > Documentation for methods etc. is included in the introspection data, > but it is generally written with the C API in mind. Suggestions? > + Other things I am probably forgetting right now. > > The generated code has not been battle tested yet, beyond some very > simple toy examples (see test/testGtk.hs in the git repo). If someone > finds it interesting and wants to take it for a spin, any comments about > the experience/suggestions would be very welcome. Or if anyone feels > like implementing any of the features above I would be glad to assist. > > Well, I hope that someone finds this useful. It is being a good learning > experience anyway :) I will keep on implementing some of the points > above as time allows. > > Any comments are very welcome! > > Cheers, > Iñaki > > Here's a not completely trivial example of use of the API, so you get an > idea of the flavor: > > -------------- > > import GI.Gtk hiding (main) > import qualified GI.Gtk as Gtk > > import GI.Utils.Attributes > import GI.Utils.Properties (new) > > import System.Environment (getProgName, getArgs) > import Data.ByteString.Char8 (unpack) > import Control.Applicative ((<$>)) > > main = do > args <- getArgs > progName <- getProgName > _ <- Gtk.init (progName : args) > > win <- new Window [windowType := WindowTypeToplevel] > onWidgetDestroy win mainQuit > > grid <- new Grid [orientableOrientation := OrientationVertical, > gridRowSpacing := 5] > set win [containerChild := grid] > > button <- new Button [buttonLabel := "Click me!", > widgetMargin := 5] > onButtonClicked button $ set button [widgetSensitive := False, > buttonLabel := "Hello, world!"] > containerAdd grid button > > fileChooser <- new FileChooserButton > [fileChooserButtonTitle := "Please choose a file", > fileChooserShowHidden := True] > > onFileChooserButtonFileSet fileChooser $ do > selectedFile <- unpack <$> fileChooserGetFilename fileChooser > message <- new MessageDialog > [windowTransientFor := win, > messageDialogButtons := ButtonsTypeOk, > messageDialogText := "You selected <i>" > ++ selectedFile ++ "</i>", > messageDialogUseMarkup := True] > dialogRun message > widgetDestroy message > > containerAdd grid fileChooser > > widgetShowAll win > > Gtk.main > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Inaki G. E. <ga...@gm...> - 2013-06-21 21:16:52
|
Dear all, For the last few weeks, as an exercise in learning Haskell better, I have been playing around with haskell-gi, adding support for a bunch of features. I based my work on the versions started by Will Thompson, found in https://gitorious.org/haskell-gi and http://git.rhydd.org/?p=haskell-gi;a=summary Thanks to the excellent foundations there, and with a bit of work, I think that the code is now reaching a stage that it may start to be useful in actually generating bindings (at least for adventurous folks :) ), hence this message. You can find my changes at https://github.com/garetxe/haskell-gi I tried to model the generated API on gtk2hs as much as possible, although there are some divergences here and there. You can view some examples of the generated code for the gtk3 stack at http://cern.ch/inaki/haskell-gi (Some example of actual usage of the bindings is given below) What works: ----------- + Typeclasses for modeling the GObject hierarchy, so if you have a GtkButton "button" and want to pass it to a function expecting a GtkWidget it will work without casting (see below for examples). + Signals. + Proper reference counting for GObjects and boxed structs/unions, including automatic handling of ownership transfer on function calls/returns. + Automatic conversion between C types and Haskell types. (So, for example, GLists are converted to ordinary Haskell lists.) + GError handling, by throwing exceptions. Same notation as in gtk2hs, with the addition of a type-specific (catch/handle)GErrorJustDomain, named (catch/handle)DBusError, for instance. + Setting/getting GObject properties. A nice feature is that the readable/writable/constructOnly constraint are enforced at compile time, so if you try to write a read-only properly you will get a (hopefully clear) compile time error. + "new" notation for constructing GObjects (see example of usage below, feels nice to use). What doesn't: ------------- + GHash type elements are not converted to native Haskell types yet. + GVariant and GHash valued properties are not yet supported. + Struct/union field accessors (I will probably tackle this next). + Structs/unions which are not boxed. + Callbacks. + Documentation. This is a big one, not sure what to do here. Since the generated API is automatically translated from C, the C API documentation is pretty useful already if one squints, but maybe we can do better (perhaps reusing the gtk2hs documentation when it applies?). Documentation for methods etc. is included in the introspection data, but it is generally written with the C API in mind. Suggestions? + Other things I am probably forgetting right now. The generated code has not been battle tested yet, beyond some very simple toy examples (see test/testGtk.hs in the git repo). If someone finds it interesting and wants to take it for a spin, any comments about the experience/suggestions would be very welcome. Or if anyone feels like implementing any of the features above I would be glad to assist. Well, I hope that someone finds this useful. It is being a good learning experience anyway :) I will keep on implementing some of the points above as time allows. Any comments are very welcome! Cheers, Iñaki Here's a not completely trivial example of use of the API, so you get an idea of the flavor: -------------- import GI.Gtk hiding (main) import qualified GI.Gtk as Gtk import GI.Utils.Attributes import GI.Utils.Properties (new) import System.Environment (getProgName, getArgs) import Data.ByteString.Char8 (unpack) import Control.Applicative ((<$>)) main = do args <- getArgs progName <- getProgName _ <- Gtk.init (progName : args) win <- new Window [windowType := WindowTypeToplevel] onWidgetDestroy win mainQuit grid <- new Grid [orientableOrientation := OrientationVertical, gridRowSpacing := 5] set win [containerChild := grid] button <- new Button [buttonLabel := "Click me!", widgetMargin := 5] onButtonClicked button $ set button [widgetSensitive := False, buttonLabel := "Hello, world!"] containerAdd grid button fileChooser <- new FileChooserButton [fileChooserButtonTitle := "Please choose a file", fileChooserShowHidden := True] onFileChooserButtonFileSet fileChooser $ do selectedFile <- unpack <$> fileChooserGetFilename fileChooser message <- new MessageDialog [windowTransientFor := win, messageDialogButtons := ButtonsTypeOk, messageDialogText := "You selected <i>" ++ selectedFile ++ "</i>", messageDialogUseMarkup := True] dialogRun message widgetDestroy message containerAdd grid fileChooser widgetShowAll win Gtk.main |
From: Felipe A. L. <fel...@gm...> - 2013-05-27 20:59:50
|
Great! =) On Fri, May 24, 2013 at 9:45 PM, Daniel Wagner <wag...@se...> wrote: > Hello all, > > I'd like to officially welcome Hamish Mackenzie as the new maintainer > of the webkit and sourceview subprojects of gtk2hs. He's been doing a > lot of work recently to modernize these and other chunks of the > bindings, so it's great to have him aboard! > > ~d > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users -- Felipe. |
From: Daniel W. <wag...@se...> - 2013-05-25 00:45:10
|
Hello all, I'd like to officially welcome Hamish Mackenzie as the new maintainer of the webkit and sourceview subprojects of gtk2hs. He's been doing a lot of work recently to modernize these and other chunks of the bindings, so it's great to have him aboard! ~d |
From: Daniel W. <wag...@se...> - 2013-05-09 01:01:57
|
Applied, with some minor changes. Thanks! ~d On 2013-04-07 14:57, Hamish Mackenzie wrote: > I have pushed a patch to https://patch-tag.com/r/hamish/gtk2hs/home > that > adds the missing "draw" event needed to use cairo. It uses the cairo > "Render" monad. > > You should be able to replace "onExpose" events with something like... > > someWidget `on` draw $ do > moveTo 0 0 > lineTo 10 10 > > The patch also adds "Region" and "RectangleInt" cairo types. > > If you have time, please try it out and let me know if it works > ok for you. > > Thanks, > Hamish > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Hamish M. <ham...@gm...> - 2013-04-07 18:57:24
|
I have pushed a patch to https://patch-tag.com/r/hamish/gtk2hs/home that adds the missing "draw" event needed to use cairo. It uses the cairo "Render" monad. You should be able to replace "onExpose" events with something like... someWidget `on` draw $ do moveTo 0 0 lineTo 10 10 The patch also adds "Region" and "RectangleInt" cairo types. If you have time, please try it out and let me know if it works ok for you. Thanks, Hamish |
From: Karl S. <kar...@gm...> - 2013-03-19 06:07:53
|
Thanks for the information---I'll hold off on moving to GTK3 full time for the moment then. Is the new draw callback the preferred way of handling this then and, If so, will I be able to force a draw signal manually when necessary? On Mon, Mar 18, 2013 at 12:35 PM, <wag...@se...> wrote: > I believe one of the advertised drawbacks of the current patches for > GTK3 support is that they don't yet have a way to do this. It is of > course on the list of things it's important to have before a release. > > ~d > > Quoting Karl Smeltzer <kar...@gm...>: > >> I'm still a bit of a rookie when it comes to GTK and Cairo, so please >> bear with me. I have some code that works with GTK2, but would like >> to bring it up to date. >> >> Most everything I've figured out, except the best way to replace the >> `renderWithDrawable` function. If I have a DrawingArea (or the >> corresponding DrawWindow) what is the best way to draw to it directly? >> I see various bits of information about a "draw" callback and >> surfaces, but nothing that has been entirely clear to me. >> >> Thanks in advance. >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> Gtk2hs-users mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users >> >> > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: <wag...@se...> - 2013-03-18 19:35:20
|
I believe one of the advertised drawbacks of the current patches for GTK3 support is that they don't yet have a way to do this. It is of course on the list of things it's important to have before a release. ~d Quoting Karl Smeltzer <kar...@gm...>: > I'm still a bit of a rookie when it comes to GTK and Cairo, so please > bear with me. I have some code that works with GTK2, but would like > to bring it up to date. > > Most everything I've figured out, except the best way to replace the > `renderWithDrawable` function. If I have a DrawingArea (or the > corresponding DrawWindow) what is the best way to draw to it directly? > I see various bits of information about a "draw" callback and > surfaces, but nothing that has been entirely clear to me. > > Thanks in advance. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > |
From: Karl S. <kar...@gm...> - 2013-03-18 18:56:33
|
I'm still a bit of a rookie when it comes to GTK and Cairo, so please bear with me. I have some code that works with GTK2, but would like to bring it up to date. Most everything I've figured out, except the best way to replace the `renderWithDrawable` function. If I have a DrawingArea (or the corresponding DrawWindow) what is the best way to draw to it directly? I see various bits of information about a "draw" callback and surfaces, but nothing that has been entirely clear to me. Thanks in advance. |
From: Hristo A. <nj...@ya...> - 2013-03-16 19:36:05
|
http://asam.ir/afyks/rvprgioludy |
From: Axel S. <Axe...@in...> - 2013-03-13 20:32:00
|
On 13.03.2013, at 20:09, wag...@se... wrote: > Quoting wag...@se...: > >> Quoting Damien Radtke <dam...@gm...>: >> >>> 2. How and where is TagList implemented? >> >> This type is exposed from Media.Streaming.GStreamer.Core.Types. I'm >> not really sure why Hackage doesn't have the documentation page for >> that. I'll look into it. > > Turns out M.S.G.C.Types just had {-# OPTIONS_HADDOCK hide #-} at the > top. There's probably a good reason for that, so for now I've just > exposed Tag and TagList from M.S.G.C.TagList as well (along with a > sentence of documentation admonishing you not to abuse the fact that > you know they're type aliases for something else). This should ease > things for future visitors without spilling all the beans, so to speak. The Type modules have traditionally not been exposed since they often contain some internals that shouldn't be presented to the user (but have to be exported). So the Types module is exported by the individual types are exported from where they are used. Cheers, Axel |
From: <wag...@se...> - 2013-03-13 19:09:23
|
Quoting wag...@se...: > Quoting Damien Radtke <dam...@gm...>: > >> 2. How and where is TagList implemented? > > This type is exposed from Media.Streaming.GStreamer.Core.Types. I'm > not really sure why Hackage doesn't have the documentation page for > that. I'll look into it. Turns out M.S.G.C.Types just had {-# OPTIONS_HADDOCK hide #-} at the top. There's probably a good reason for that, so for now I've just exposed Tag and TagList from M.S.G.C.TagList as well (along with a sentence of documentation admonishing you not to abuse the fact that you know they're type aliases for something else). This should ease things for future visitors without spilling all the beans, so to speak. ~d |
From: Hamish M. <ham...@gm...> - 2013-03-07 06:46:16
|
I am not able to reproduce this on my Ubuntu 12.10 VM. What version of GHC are you using? Do you have anything in your ~/.ghci file? What command are you running? Does putStrLn "Hello World" work? What is the active .cabal project? The GHCi interface is sensitive to changes in the way GHCi formats it output, so it is a bit fragile. Some things that will currently break it are... * Anything that tries to read input on stdin * :set prompt (Leksah uses the prompt to detect when the output finishes) I added some tests a while back to try to catch issues running GHCi. Can you please try this... cd leksah/vendor/leksah-server cabal install --enable-tests --force-reinstall You should see this near the end... Running 1 test suites... Test suite test-tool: RUNNING... Test suite test-tool: PASS Test suite logged to: dist/test/leksah-server-0.13.0.0-test-tool.log 1 of 1 test suites (1 of 1 test cases) passed. Thanks, Hamish On 7 Mar 2013, at 08:48, Alejandro Toribio Bello Ruiz <ale...@gm...> wrote: > Leksah 0.13.2 compiled successfully on Ubuntu 12.10 following the new instructions on .travis.yml, but arise the old problem where the GHCi integration break when the first command set is from the debug scratch pane. This bug was fixed on Leksah 0.12.1.3. What happened? This issue is very import for my students. Would be very grateful if you fix this bug. > > Regards > > El viernes, 1 de marzo de 2013 23:04:59 UTC-5, Hamish escribió: > 12.10 uses webkit 1.10 so the -fwebkit1.8 was probably tripping it up. > > I have updated webkit so that webkit 1.8 is detected automatically and > updated the .travis.yml file. > > Please try again. > > On 23 Feb 2013, at 06:20, alejandr...@gmail.com wrote: > >> I compiled Leksah 0.13.2 using Ubuntu 12.04 (I followed the instructions on .travis.yml). It was OK, but when I tried to compile with Ubuntu 12.10, I got the following error: >> >> Building webkit-0.12.5... >> Preprocessing library webkit-0.12.5... >> gtk2hsC2hs: Errors during expansion of binding hooks: >> >> webkit1.8/Graphics/UI/Gtk/WebKit/DOM/File.chs:17: (column 14) [ERROR] >> >>> Unknown identifier! >> Cannot find a definition for `webkit_dom_file_get_file_name' in the header file. >> webkit1.8/Graphics/UI/Gtk/WebKit/DOM/File.chs:23: (column 16) [ERROR] >> >>> Unknown identifier! >> Cannot find a definition for `webkit_dom_file_get_file_size' in the header file. >> >> Can you help me, please? >> >> Alejandro T. Bello Ruiz >> >> >> -- >> You received this message because you are subscribed to the Google Groups "leksah" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to leksah+un...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > You received this message because you are subscribed to the Google Groups "leksah" group. > To unsubscribe from this group and stop receiving emails from it, send an email to lek...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > > |
From: <wag...@se...> - 2013-03-05 23:05:31
|
Pushed. I guess it's a bit fragile (you have to make sure to build gtk and webkit either both with -fgtk3 or both with -f-gtk3) but I don't really see a way around that. Thanks for your hard work! ~d Quoting Hamish Mackenzie <ham...@gm...>: > Sorry I did not get to this last weekend. Luite and I both caught a > nasty cold at mloc-js and I spent the whole of last weekend in bed. > > I have pushed a patch that removes the webkit1.8 flag and uses the > CPP instead... > https://patch-tag.com/r/hamish/webkit/home > > Here is in action... > https://travis-ci.org/leksah/leksah > > Hamish > > On 22 Feb 2013, at 02:42, wag...@se... wrote: > >> Quoting Hamish Mackenzie <ham...@gm...>: >> >>> I would like to keep the 1.8 support (that is what is available on >>> travis-ci). >> >> Oh, absolutely. I just mean the *flag* is unfortunate, not that the >> support is unfortunate. >> >>> I'll try to have a look at it this weekend. If the changes are >>> not to great I will try to #ifdefs to the main source directory >>> (and just leave out anything that is out of date or missing in 1.8). >>> >>> On 16 Feb 2013, at 15:21, wag...@se... wrote: >>> >>>> Hi Hamish -- >>>> >>>> I'm taking a look at the webkit patches. I understand the gtk3 >>>> flag is pretty unavoidable, but the webkit1-8 flag is a bit >>>> unfortunate. Do you have a feeling for how difficult it would be >>>> to do as in the gtk package and use CPP to choose code based on >>>> which version of webkit is available? >>>> >>>> I guess the main piece of interest is how to expose the >>>> G.U.G.W.DOM hierarchy or not; I wonder how painful it would be >>>> for those modules to just be empty if the version of webkit is >>>> too low (i.e. always exposed). >>>> >>>> ~d >>>> >>>> Quoting Hamish Mackenzie <ham...@gm...>: >>>> >>>>> Hi, >>>>> >>>>> I want to do a release of Leksah to Hackage that uses Gtk3 and >>>>> WebKit (preferably in the next week or two). >>>>> >>>>> This will need the following patches: >>>>> https://patch-tag.com/r/hamish/gtk2hs >>>>> http://leksah.org/gtksourceview3.patches (repo still seems to be darcs1) >>>>> https://patch-tag.com/r/hamish/webkit >>>>> >>>>> Although these packages default to gtk3 you can still use them >>>>> with gtk2 (cabal install -f-gtk3) >>>>> >>>>> I think we have three options: >>>>> 1) Push the Gtk3 patches into the Gtk2Hs repo in preparation for >>>>> a regular release (perhaps 0.13.0). >>>>> 2) Create a new repo for them and release it as gtk on Hackage >>>>> (version 1.0.0 or 0.13.0) and continue merging 0.12 repo changes >>>>> in. >>>>> 3) Add gtk-gtk3, gtksourceview-gtk3 and webkit-gtk3 to Hackage. >>>>> >>>>> Please can we start the ball rolling on option 1 or can you let >>>>> me know which of the other two options you would prefer? >>>>> >>>>> Thanks, >>>>> Hamish >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > |
From: <wag...@se...> - 2013-03-02 12:25:02
|
I'm at a go tournament this weekend, but will take a look Monday or Tuesday. Thanks! ~d Quoting Hamish Mackenzie <ham...@gm...>: > Sorry I did not get to this last weekend. Luite and I both caught a > nasty cold at mloc-js and I spent the whole of last weekend in bed. > > I have pushed a patch that removes the webkit1.8 flag and uses the > CPP instead... > https://patch-tag.com/r/hamish/webkit/home > > Here is in action... > https://travis-ci.org/leksah/leksah > > Hamish > > On 22 Feb 2013, at 02:42, wag...@se... wrote: > >> Quoting Hamish Mackenzie <ham...@gm...>: >> >>> I would like to keep the 1.8 support (that is what is available on >>> travis-ci). >> >> Oh, absolutely. I just mean the *flag* is unfortunate, not that the >> support is unfortunate. >> >>> I'll try to have a look at it this weekend. If the changes are >>> not to great I will try to #ifdefs to the main source directory >>> (and just leave out anything that is out of date or missing in 1.8). >>> >>> On 16 Feb 2013, at 15:21, wag...@se... wrote: >>> >>>> Hi Hamish -- >>>> >>>> I'm taking a look at the webkit patches. I understand the gtk3 >>>> flag is pretty unavoidable, but the webkit1-8 flag is a bit >>>> unfortunate. Do you have a feeling for how difficult it would be >>>> to do as in the gtk package and use CPP to choose code based on >>>> which version of webkit is available? >>>> >>>> I guess the main piece of interest is how to expose the >>>> G.U.G.W.DOM hierarchy or not; I wonder how painful it would be >>>> for those modules to just be empty if the version of webkit is >>>> too low (i.e. always exposed). >>>> >>>> ~d >>>> >>>> Quoting Hamish Mackenzie <ham...@gm...>: >>>> >>>>> Hi, >>>>> >>>>> I want to do a release of Leksah to Hackage that uses Gtk3 and >>>>> WebKit (preferably in the next week or two). >>>>> >>>>> This will need the following patches: >>>>> https://patch-tag.com/r/hamish/gtk2hs >>>>> http://leksah.org/gtksourceview3.patches (repo still seems to be darcs1) >>>>> https://patch-tag.com/r/hamish/webkit >>>>> >>>>> Although these packages default to gtk3 you can still use them >>>>> with gtk2 (cabal install -f-gtk3) >>>>> >>>>> I think we have three options: >>>>> 1) Push the Gtk3 patches into the Gtk2Hs repo in preparation for >>>>> a regular release (perhaps 0.13.0). >>>>> 2) Create a new repo for them and release it as gtk on Hackage >>>>> (version 1.0.0 or 0.13.0) and continue merging 0.12 repo changes >>>>> in. >>>>> 3) Add gtk-gtk3, gtksourceview-gtk3 and webkit-gtk3 to Hackage. >>>>> >>>>> Please can we start the ball rolling on option 1 or can you let >>>>> me know which of the other two options you would prefer? >>>>> >>>>> Thanks, >>>>> Hamish >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > |
From: Hamish M. <ham...@gm...> - 2013-03-02 04:05:12
|
12.10 uses webkit 1.10 so the -fwebkit1.8 was probably tripping it up. I have updated webkit so that webkit 1.8 is detected automatically and updated the .travis.yml file. Please try again. On 23 Feb 2013, at 06:20, ale...@gm... wrote: > I compiled Leksah 0.13.2 using Ubuntu 12.04 (I followed the instructions on .travis.yml). It was OK, but when I tried to compile with Ubuntu 12.10, I got the following error: > > Building webkit-0.12.5... > Preprocessing library webkit-0.12.5... > gtk2hsC2hs: Errors during expansion of binding hooks: > > webkit1.8/Graphics/UI/Gtk/WebKit/DOM/File.chs:17: (column 14) [ERROR] > >>> Unknown identifier! > Cannot find a definition for `webkit_dom_file_get_file_name' in the header file. > webkit1.8/Graphics/UI/Gtk/WebKit/DOM/File.chs:23: (column 16) [ERROR] > >>> Unknown identifier! > Cannot find a definition for `webkit_dom_file_get_file_size' in the header file. > > Can you help me, please? > > Alejandro T. Bello Ruiz > > > -- > You received this message because you are subscribed to the Google Groups "leksah" group. > To unsubscribe from this group and stop receiving emails from it, send an email to lek...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > > |
From: Hamish M. <ham...@gm...> - 2013-03-02 04:02:40
|
Sorry I did not get to this last weekend. Luite and I both caught a nasty cold at mloc-js and I spent the whole of last weekend in bed. I have pushed a patch that removes the webkit1.8 flag and uses the CPP instead... https://patch-tag.com/r/hamish/webkit/home Here is in action... https://travis-ci.org/leksah/leksah Hamish On 22 Feb 2013, at 02:42, wag...@se... wrote: > Quoting Hamish Mackenzie <ham...@gm...>: > >> I would like to keep the 1.8 support (that is what is available on travis-ci). > > Oh, absolutely. I just mean the *flag* is unfortunate, not that the support is unfortunate. > >> I'll try to have a look at it this weekend. If the changes are not to great I will try to #ifdefs to the main source directory (and just leave out anything that is out of date or missing in 1.8). >> >> On 16 Feb 2013, at 15:21, wag...@se... wrote: >> >>> Hi Hamish -- >>> >>> I'm taking a look at the webkit patches. I understand the gtk3 flag is pretty unavoidable, but the webkit1-8 flag is a bit unfortunate. Do you have a feeling for how difficult it would be to do as in the gtk package and use CPP to choose code based on which version of webkit is available? >>> >>> I guess the main piece of interest is how to expose the G.U.G.W.DOM hierarchy or not; I wonder how painful it would be for those modules to just be empty if the version of webkit is too low (i.e. always exposed). >>> >>> ~d >>> >>> Quoting Hamish Mackenzie <ham...@gm...>: >>> >>>> Hi, >>>> >>>> I want to do a release of Leksah to Hackage that uses Gtk3 and WebKit (preferably in the next week or two). >>>> >>>> This will need the following patches: >>>> https://patch-tag.com/r/hamish/gtk2hs >>>> http://leksah.org/gtksourceview3.patches (repo still seems to be darcs1) >>>> https://patch-tag.com/r/hamish/webkit >>>> >>>> Although these packages default to gtk3 you can still use them with gtk2 (cabal install -f-gtk3) >>>> >>>> I think we have three options: >>>> 1) Push the Gtk3 patches into the Gtk2Hs repo in preparation for a regular release (perhaps 0.13.0). >>>> 2) Create a new repo for them and release it as gtk on Hackage (version 1.0.0 or 0.13.0) and continue merging 0.12 repo changes in. >>>> 3) Add gtk-gtk3, gtksourceview-gtk3 and webkit-gtk3 to Hackage. >>>> >>>> Please can we start the ball rolling on option 1 or can you let me know which of the other two options you would prefer? >>>> >>>> Thanks, >>>> Hamish >>>> >>>> >>>> >>> >>> >> >> >> > > |
From: <wag...@se...> - 2013-02-23 02:04:19
|
Okay, in that case you should create a bound thread to run your Gtk code in when you play in ghci. You can use forkOS for this. See also http://dmwit.com/gtk2hs for low-level details. ~d Quoting Karl Smeltzer <kar...@gm...>: > That actually does work! Thanks. I'm a bit ashamed I didn't think to > try that on my own first. > > On Fri, Feb 22, 2013 at 3:03 PM, <wag...@se...> wrote: >> Hah! I'm not too surprised I guess. I'll try to take a look and see if >> I can spot anything obvious. In the meantime, does turning off ghci's >> extra sandbox thread (with -fno-ghci-sandbox) change anything? >> >> ~d >> >> Quoting Karl Smeltzer <kar...@gm...>: >> >>> I'm using the latest darcs code to get GTK3 support on OSX (very >>> excited to see this hit Hackage!) and would like to improve my >>> workflow a bit. If I compile using "ghc --make" then everything works >>> great, but using GHCi, runhaskell, and runghc all produce an empty >>> window. Nothing is ever rendered and the process seems to hang. >>> >>> Does anyone know a way around this? >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> _______________________________________________ >>> Gtk2hs-users mailing list >>> Gtk...@li... >>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Gtk2hs-users mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > > On Fri, Feb 22, 2013 at 3:03 PM, <wag...@se...> wrote: >> Hah! I'm not too surprised I guess. I'll try to take a look and see if >> I can spot anything obvious. In the meantime, does turning off ghci's >> extra sandbox thread (with -fno-ghci-sandbox) change anything? >> >> ~d >> >> Quoting Karl Smeltzer <kar...@gm...>: >> >>> I'm using the latest darcs code to get GTK3 support on OSX (very >>> excited to see this hit Hackage!) and would like to improve my >>> workflow a bit. If I compile using "ghc --make" then everything works >>> great, but using GHCi, runhaskell, and runghc all produce an empty >>> window. Nothing is ever rendered and the process seems to hang. >>> >>> Does anyone know a way around this? >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> _______________________________________________ >>> Gtk2hs-users mailing list >>> Gtk...@li... >>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Gtk2hs-users mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > |
From: Karl S. <kar...@gm...> - 2013-02-23 01:53:16
|
That actually does work! Thanks. I'm a bit ashamed I didn't think to try that on my own first. On Fri, Feb 22, 2013 at 3:03 PM, <wag...@se...> wrote: > Hah! I'm not too surprised I guess. I'll try to take a look and see if > I can spot anything obvious. In the meantime, does turning off ghci's > extra sandbox thread (with -fno-ghci-sandbox) change anything? > > ~d > > Quoting Karl Smeltzer <kar...@gm...>: > >> I'm using the latest darcs code to get GTK3 support on OSX (very >> excited to see this hit Hackage!) and would like to improve my >> workflow a bit. If I compile using "ghc --make" then everything works >> great, but using GHCi, runhaskell, and runghc all produce an empty >> window. Nothing is ever rendered and the process seems to hang. >> >> Does anyone know a way around this? >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Gtk2hs-users mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users >> >> > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users On Fri, Feb 22, 2013 at 3:03 PM, <wag...@se...> wrote: > Hah! I'm not too surprised I guess. I'll try to take a look and see if > I can spot anything obvious. In the meantime, does turning off ghci's > extra sandbox thread (with -fno-ghci-sandbox) change anything? > > ~d > > Quoting Karl Smeltzer <kar...@gm...>: > >> I'm using the latest darcs code to get GTK3 support on OSX (very >> excited to see this hit Hackage!) and would like to improve my >> workflow a bit. If I compile using "ghc --make" then everything works >> great, but using GHCi, runhaskell, and runghc all produce an empty >> window. Nothing is ever rendered and the process seems to hang. >> >> Does anyone know a way around this? >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Gtk2hs-users mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users >> >> > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: <wag...@se...> - 2013-02-22 23:03:16
|
Hah! I'm not too surprised I guess. I'll try to take a look and see if I can spot anything obvious. In the meantime, does turning off ghci's extra sandbox thread (with -fno-ghci-sandbox) change anything? ~d Quoting Karl Smeltzer <kar...@gm...>: > I'm using the latest darcs code to get GTK3 support on OSX (very > excited to see this hit Hackage!) and would like to improve my > workflow a bit. If I compile using "ghc --make" then everything works > great, but using GHCi, runhaskell, and runghc all produce an empty > window. Nothing is ever rendered and the process seems to hang. > > Does anyone know a way around this? > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > |
From: Karl S. <kar...@gm...> - 2013-02-22 22:16:09
|
I'm using the latest darcs code to get GTK3 support on OSX (very excited to see this hit Hackage!) and would like to improve my workflow a bit. If I compile using "ghc --make" then everything works great, but using GHCi, runhaskell, and runghc all produce an empty window. Nothing is ever rendered and the process seems to hang. Does anyone know a way around this? |
From: <wag...@se...> - 2013-02-21 13:42:17
|
Quoting Hamish Mackenzie <ham...@gm...>: > I would like to keep the 1.8 support (that is what is available on > travis-ci). Oh, absolutely. I just mean the *flag* is unfortunate, not that the support is unfortunate. > I'll try to have a look at it this weekend. If the changes are not > to great I will try to #ifdefs to the main source directory (and > just leave out anything that is out of date or missing in 1.8). > > On 16 Feb 2013, at 15:21, wag...@se... wrote: > >> Hi Hamish -- >> >> I'm taking a look at the webkit patches. I understand the gtk3 flag >> is pretty unavoidable, but the webkit1-8 flag is a bit unfortunate. >> Do you have a feeling for how difficult it would be to do as in the >> gtk package and use CPP to choose code based on which version of >> webkit is available? >> >> I guess the main piece of interest is how to expose the G.U.G.W.DOM >> hierarchy or not; I wonder how painful it would be for those >> modules to just be empty if the version of webkit is too low (i.e. >> always exposed). >> >> ~d >> >> Quoting Hamish Mackenzie <ham...@gm...>: >> >>> Hi, >>> >>> I want to do a release of Leksah to Hackage that uses Gtk3 and >>> WebKit (preferably in the next week or two). >>> >>> This will need the following patches: >>> https://patch-tag.com/r/hamish/gtk2hs >>> http://leksah.org/gtksourceview3.patches (repo still seems to be darcs1) >>> https://patch-tag.com/r/hamish/webkit >>> >>> Although these packages default to gtk3 you can still use them >>> with gtk2 (cabal install -f-gtk3) >>> >>> I think we have three options: >>> 1) Push the Gtk3 patches into the Gtk2Hs repo in preparation for a >>> regular release (perhaps 0.13.0). >>> 2) Create a new repo for them and release it as gtk on Hackage >>> (version 1.0.0 or 0.13.0) and continue merging 0.12 repo changes in. >>> 3) Add gtk-gtk3, gtksourceview-gtk3 and webkit-gtk3 to Hackage. >>> >>> Please can we start the ball rolling on option 1 or can you let me >>> know which of the other two options you would prefer? >>> >>> Thanks, >>> Hamish >>> >>> >>> >> >> > > > |
From: Hamish M. <ham...@gm...> - 2013-02-21 00:45:00
|
I would like to keep the 1.8 support (that is what is available on travis-ci). I'll try to have a look at it this weekend. If the changes are not to great I will try to #ifdefs to the main source directory (and just leave out anything that is out of date or missing in 1.8). On 16 Feb 2013, at 15:21, wag...@se... wrote: > Hi Hamish -- > > I'm taking a look at the webkit patches. I understand the gtk3 flag is pretty unavoidable, but the webkit1-8 flag is a bit unfortunate. Do you have a feeling for how difficult it would be to do as in the gtk package and use CPP to choose code based on which version of webkit is available? > > I guess the main piece of interest is how to expose the G.U.G.W.DOM hierarchy or not; I wonder how painful it would be for those modules to just be empty if the version of webkit is too low (i.e. always exposed). > > ~d > > Quoting Hamish Mackenzie <ham...@gm...>: > >> Hi, >> >> I want to do a release of Leksah to Hackage that uses Gtk3 and WebKit (preferably in the next week or two). >> >> This will need the following patches: >> https://patch-tag.com/r/hamish/gtk2hs >> http://leksah.org/gtksourceview3.patches (repo still seems to be darcs1) >> https://patch-tag.com/r/hamish/webkit >> >> Although these packages default to gtk3 you can still use them with gtk2 (cabal install -f-gtk3) >> >> I think we have three options: >> 1) Push the Gtk3 patches into the Gtk2Hs repo in preparation for a regular release (perhaps 0.13.0). >> 2) Create a new repo for them and release it as gtk on Hackage (version 1.0.0 or 0.13.0) and continue merging 0.12 repo changes in. >> 3) Add gtk-gtk3, gtksourceview-gtk3 and webkit-gtk3 to Hackage. >> >> Please can we start the ball rolling on option 1 or can you let me know which of the other two options you would prefer? >> >> Thanks, >> Hamish >> >> >> > > |
From: <wag...@se...> - 2013-02-16 02:21:58
|
Hi Hamish -- I'm taking a look at the webkit patches. I understand the gtk3 flag is pretty unavoidable, but the webkit1-8 flag is a bit unfortunate. Do you have a feeling for how difficult it would be to do as in the gtk package and use CPP to choose code based on which version of webkit is available? I guess the main piece of interest is how to expose the G.U.G.W.DOM hierarchy or not; I wonder how painful it would be for those modules to just be empty if the version of webkit is too low (i.e. always exposed). ~d Quoting Hamish Mackenzie <ham...@gm...>: > Hi, > > I want to do a release of Leksah to Hackage that uses Gtk3 and > WebKit (preferably in the next week or two). > > This will need the following patches: > https://patch-tag.com/r/hamish/gtk2hs > http://leksah.org/gtksourceview3.patches (repo still seems to be darcs1) > https://patch-tag.com/r/hamish/webkit > > Although these packages default to gtk3 you can still use them with > gtk2 (cabal install -f-gtk3) > > I think we have three options: > 1) Push the Gtk3 patches into the Gtk2Hs repo in preparation for a > regular release (perhaps 0.13.0). > 2) Create a new repo for them and release it as gtk on Hackage > (version 1.0.0 or 0.13.0) and continue merging 0.12 repo changes in. > 3) Add gtk-gtk3, gtksourceview-gtk3 and webkit-gtk3 to Hackage. > > Please can we start the ball rolling on option 1 or can you let me > know which of the other two options you would prefer? > > Thanks, > Hamish > > > |
From: <wag...@se...> - 2013-02-15 01:38:34
|
Quoting Hamish Mackenzie <ham...@gm...>: > Hi, > > I want to do a release of Leksah to Hackage that uses Gtk3 and > WebKit (preferably in the next week or two). > > This will need the following patches: > https://patch-tag.com/r/hamish/gtk2hs > http://leksah.org/gtksourceview3.patches (repo still seems to be darcs1) > https://patch-tag.com/r/hamish/webkit > > Although these packages default to gtk3 you can still use them with > gtk2 (cabal install -f-gtk3) > > I think we have three options: > 1) Push the Gtk3 patches into the Gtk2Hs repo in preparation for a > regular release (perhaps 0.13.0). > 2) Create a new repo for them and release it as gtk on Hackage > (version 1.0.0 or 0.13.0) and continue merging 0.12 repo changes in. > 3) Add gtk-gtk3, gtksourceview-gtk3 and webkit-gtk3 to Hackage. > > Please can we start the ball rolling on option 1 or can you let me > know which of the other two options you would prefer? Hey Hamish. Patches to gtk are in -- let's see what breaks! Looking at patches to gtksourceview and webkit next. Thanks again for all your (and Peter's) hard work. ~d |