You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(52) |
Apr
(78) |
May
(134) |
Jun
(64) |
Jul
(110) |
Aug
(88) |
Sep
(2) |
Oct
(33) |
Nov
(41) |
Dec
(25) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(56) |
Feb
(5) |
Mar
(25) |
Apr
(22) |
May
(6) |
Jun
(2) |
Jul
(12) |
Aug
(11) |
Sep
(3) |
Oct
(16) |
Nov
(19) |
Dec
(31) |
2007 |
Jan
(17) |
Feb
(28) |
Mar
(9) |
Apr
(14) |
May
(47) |
Jun
(16) |
Jul
(45) |
Aug
(31) |
Sep
(28) |
Oct
(37) |
Nov
(46) |
Dec
(19) |
2008 |
Jan
(51) |
Feb
(22) |
Mar
(18) |
Apr
(25) |
May
(19) |
Jun
(51) |
Jul
(18) |
Aug
(5) |
Sep
(4) |
Oct
(21) |
Nov
(18) |
Dec
(11) |
2009 |
Jan
(39) |
Feb
(13) |
Mar
(9) |
Apr
(27) |
May
(34) |
Jun
(9) |
Jul
(17) |
Aug
(3) |
Sep
(37) |
Oct
(32) |
Nov
(71) |
Dec
(36) |
2010 |
Jan
(11) |
Feb
(16) |
Mar
(44) |
Apr
(208) |
May
(133) |
Jun
(24) |
Jul
(39) |
Aug
(9) |
Sep
(20) |
Oct
(82) |
Nov
(19) |
Dec
|
2011 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
(3) |
May
(7) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(3) |
Oct
(4) |
Nov
(18) |
Dec
(3) |
2012 |
Jan
(12) |
Feb
(12) |
Mar
(18) |
Apr
(14) |
May
(10) |
Jun
(4) |
Jul
(14) |
Aug
(9) |
Sep
(16) |
Oct
(10) |
Nov
(20) |
Dec
(8) |
2013 |
Jan
(13) |
Feb
(7) |
Mar
(2) |
Apr
(12) |
May
(13) |
Jun
(1) |
Jul
(8) |
Aug
(3) |
Sep
(11) |
Oct
(7) |
Nov
(1) |
Dec
(1) |
2014 |
Jan
(14) |
Feb
(20) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(3) |
Nov
(2) |
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Daniel W. <da...@wa...> - 2013-10-16 20:58:07
|
Hey, neat, thanks! I really need to push out a release, but I want to run some Windows build tests before I do, and I've been dreading booting up my VM again and remembering how to do that. Is this a thing Travis can help with? ~d On 2013-10-15 01:19, Hamish Mackenzie wrote: > Since no one seemed to have any objections, I have made a start... > > https://github.com/gtk2hs > > and... > > https://travis-ci.org/gtk2hs/gtk2hs > > On 5 Oct 2013, at 20:36, Hamish Mackenzie > <Ham...@gm...> wrote: > >> Ben suggested it might be a good way to make it easier for people to >> contribute. I agree. There are lots of great tools for git (I use >> SmartGit all the time) and we can set up Travis-CI. >> >> +1 >> >> Hamish |
From: Eugene K. <eki...@gm...> - 2013-10-16 05:08:35
|
Awesome, thanks! On Mon Oct 14 2013 at 10:19:25 PM, Hamish Mackenzie < ham...@gm...> wrote: > Since no one seemed to have any objections, I have made a start... > > https://github.com/gtk2hs > > and... > > https://travis-ci.org/gtk2hs/**gtk2hs<https://travis-ci.org/gtk2hs/gtk2hs> > > On 5 Oct 2013, at 20:36, Hamish Mackenzie <Ham...@gm...> > wrote: > > > Ben suggested it might be a good way to make it easier for people to > contribute. I agree. There are lots of great tools for git (I use > SmartGit all the time) and we can set up Travis-CI. > > > > +1 > > > > Hamish > > > ------------------------------**------------------------------** > ------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.**net/gampad/clk?id=60135031&iu=** > /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk> > ______________________________**_________________ > Gtk2hs-devel mailing list > Gtk2hs-devel@lists.**sourceforge.net <Gtk...@li...> > https://lists.sourceforge.net/**lists/listinfo/gtk2hs-devel<https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel> > |
From: Hamish M. <ham...@gm...> - 2013-10-15 05:19:17
|
Since no one seemed to have any objections, I have made a start... https://github.com/gtk2hs and... https://travis-ci.org/gtk2hs/gtk2hs On 5 Oct 2013, at 20:36, Hamish Mackenzie <Ham...@gm...> wrote: > Ben suggested it might be a good way to make it easier for people to contribute. I agree. There are lots of great tools for git (I use SmartGit all the time) and we can set up Travis-CI. > > +1 > > Hamish |
From: Ben G. <bga...@gm...> - 2013-10-05 15:01:13
|
Hamish Mackenzie <ham...@gm...> writes: > Ben suggested it might be a good way to make it easier for people to > contribute. I agree. There are lots of great tools for git (I use > SmartGit all the time) and we can set up Travis-CI. > +1 |
From: Dominic S. <do...@st...> - 2013-10-05 10:20:16
|
+1 Sent from my iPhone On 5 Oct 2013, at 08:36, Hamish Mackenzie <ham...@gm...> wrote: > Ben suggested it might be a good way to make it easier for people to contribute. I agree. There are lots of great tools for git (I use SmartGit all the time) and we can set up Travis-CI. > > +1 > > Hamish > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Hamish M. <ham...@gm...> - 2013-10-05 07:36:17
|
Ben suggested it might be a good way to make it easier for people to contribute. I agree. There are lots of great tools for git (I use SmartGit all the time) and we can set up Travis-CI. +1 Hamish |
From: Daniel W. <da...@wa...> - 2013-09-24 20:17:35
|
On 2013-09-24 16:08, Ben Gamari wrote: > Thanks for this reference. That indeed confirms my suspicion. That > being > said, why the "-0" suffix for the Gtk+ 2 Cabal file? No good reason. I suspect you should think of it like the "nought" in math texts -- this was the original, -3 is the modified one. =) Happy to change it to whatever; no big deal. ~d |
From: Ben G. <bga...@gm...> - 2013-09-24 20:09:07
|
Daniel Wagner <da...@wa...> writes: > It's a good idea. I believe the problem I had when I tried it last was > that cabal doesn't like ".." as part of an hs-source-dirs directive. > But my memory is a bit fuzzy. Hmmm, that could be problematic. I'll look into this. > After I have a look at the various cabal-1.18 patches floating around > it seems like a good thing to think about. > You may want to have a look at https://github.com/bgamari/gtk2hs/tree/cabal-1.18 for this. I've been meaning to get these patches back into Darcs for submission. > Of course, the idea is that our moderately experienced Haskeller will be > installing from Hackage, not darcs, and so most of these things are > aimed at very experienced Haskellers who need to hack on gtk2hs. > Fair enough. Of course, the lower the bar to contributing the better. > But your point stands: it would be nice to have more and/or easier > instructions. > > See also bootstrap.sh, which builds both the gtk and gtk3 packages. > Thanks for this reference. That indeed confirms my suspicion. That being said, why the "-0" suffix for the Gtk+ 2 Cabal file? Cheers, - Ben |
From: Ben G. <bga...@gm...> - 2013-09-24 20:04:51
|
Ben Gamari <bga...@gm...> writes: > After having demonstrated to myself repeatedly that I'm incapable of > operating Darcs correctly, I finally broke down and imported Gtk2hs > into Git. My cabal-1.18 branch[1] has the current state of my work to > get Gtk2hs building with Cabal 1.18. My intention is to export these > patches to apply against my Darcs tree when they are > ready. Unfortunately, it's not clear to me how to manage various Cabal > changes made in interfaces used by Gtk2HsSetup.hs (in particular > programFindLocation) without breaking backwards compatibility. This is > particularly problematic as Gtk2HsSetup.hs apparently doesn't have > access to the CPP macros typically defined by Cabal. > > Cheers, > > - Ben > > > [1] http://github.com/bgamari/gtk2hs/tree/cabal-1.18 For the record, this branch should now be in a condition where it will work with Cabals both pre- and post-1.18. Cheers, - Ben |
From: Daniel W. <da...@wa...> - 2013-09-24 19:58:22
|
It's a good idea. I believe the problem I had when I tried it last was that cabal doesn't like ".." as part of an hs-source-dirs directive. But my memory is a bit fuzzy. After I have a look at the various cabal-1.18 patches floating around it seems like a good thing to think about. Of course, the idea is that our moderately experienced Haskeller will be installing from Hackage, not darcs, and so most of these things are aimed at very experienced Haskellers who need to hack on gtk2hs. But your point stands: it would be nice to have more and/or easier instructions. See also bootstrap.sh, which builds both the gtk and gtk3 packages. ~d On 2013-09-22 11:00, Ben Gamari wrote: > Since Daniel Wagner's patch[1] from 11 July 2012, gtk/gtk.cabal in the > gtk2hs repository declares the package name to be gtk3. This is a fine > approach to take for differentiating the Gtk3 bindings from their Gtk2 > counterparts but the implementation needs to be finished. > > In addition to editing gtk.cabal, the patch also adds gtk.cabal-0 and > gtk.cabal-3. The naming of these files is quite mysterious (why does > the > Gtk 2 cabal file end in "-0"?) and it's completely unclear how to > convince cabal-install to build bindings for a given Gtk version short > of copying one of these files over gtk.cabal. At very least, we need to > add some notes to INSTALL describing how to build both the Gtk3 and > Gtk2 bindings. > > Really, it would be better if things were laid out in such a way that > the desired workflow was apparent to a moderately experienced > Haskeller. > One way to accomplish this would be, > > * remove gtk/gtk.cabal > * move gtk/gtk.cabal-0 to gtk2/gtk.cabal and gtk/gtk.cabal-3 to > gtk3/gtk3.cabal > * possibly rename gtk/ to gtk-common/ to suggest to the user that > this > directory contains no package of its own > * add hs-source-dirs definitions pointing to gtk/ to both files > * move Gtk2/3 specific files in gtk-common/ to the appropriate > version-specific directory > * Of course, update installation documentation in INSTALL > > Thoughts? > > Cheers, > > - Ben > > > [1] > https://github.com/bgamari/gtk2hs/commit/adf06373654d32b5b5838b813807faeb8bb3819b |
From: Ben G. <bga...@gm...> - 2013-09-22 15:00:15
|
Since Daniel Wagner's patch[1] from 11 July 2012, gtk/gtk.cabal in the gtk2hs repository declares the package name to be gtk3. This is a fine approach to take for differentiating the Gtk3 bindings from their Gtk2 counterparts but the implementation needs to be finished. In addition to editing gtk.cabal, the patch also adds gtk.cabal-0 and gtk.cabal-3. The naming of these files is quite mysterious (why does the Gtk 2 cabal file end in "-0"?) and it's completely unclear how to convince cabal-install to build bindings for a given Gtk version short of copying one of these files over gtk.cabal. At very least, we need to add some notes to INSTALL describing how to build both the Gtk3 and Gtk2 bindings. Really, it would be better if things were laid out in such a way that the desired workflow was apparent to a moderately experienced Haskeller. One way to accomplish this would be, * remove gtk/gtk.cabal * move gtk/gtk.cabal-0 to gtk2/gtk.cabal and gtk/gtk.cabal-3 to gtk3/gtk3.cabal * possibly rename gtk/ to gtk-common/ to suggest to the user that this directory contains no package of its own * add hs-source-dirs definitions pointing to gtk/ to both files * move Gtk2/3 specific files in gtk-common/ to the appropriate version-specific directory * Of course, update installation documentation in INSTALL Thoughts? Cheers, - Ben [1] https://github.com/bgamari/gtk2hs/commit/adf06373654d32b5b5838b813807faeb8bb3819b |
From: Ben G. <bga...@gm...> - 2013-09-20 12:38:45
|
Dominic Steinitz <do...@st...> writes: > Hi Ben, > > I have pull request against your 1.18 branch which fixes backwards > compatibility (untested on 1.16). > Awesome! That's a pretty clever hack although it still irks me that the interface was changed on the Cabal side in the first place. > Is there any point to exporting to cabal now? Why don't we just stick > with git? It's pretty much the de facto standard these days and I used > to be a big darcs user. > I would certainly prefer to move to git. I've never felt very comfortable with darcs and I believe that many other potential contributors feel similarly. Cheers, - Ben |
From: Dominic S. <do...@st...> - 2013-09-20 08:01:34
|
Hi Ben, I have pull request against your 1.18 branch which fixes backwards compatibility (untested on 1.16). Is there any point to exporting to cabal now? Why don't we just stick with git? It's pretty much the de facto standard these days and I used to be a big darcs user. Dominic Steinitz do...@st... http://idontgetoutmuch.wordpress.com On 18 Sep 2013, at 14:40, Ben Gamari <bga...@gm...> wrote: > > After having demonstrated to myself repeatedly that I'm incapable of > operating Darcs correctly, I finally broke down and imported Gtk2hs > into Git. My cabal-1.18 branch[1] has the current state of my work to > get Gtk2hs building with Cabal 1.18. My intention is to export these > patches to apply against my Darcs tree when they are > ready. Unfortunately, it's not clear to me how to manage various Cabal > changes made in interfaces used by Gtk2HsSetup.hs (in particular > programFindLocation) without breaking backwards compatibility. This is > particularly problematic as Gtk2HsSetup.hs apparently doesn't have > access to the CPP macros typically defined by Cabal. > > Cheers, > > - Ben > > > [1] http://github.com/bgamari/gtk2hs/tree/cabal-1.18 > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk_______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Ben G. <bga...@gm...> - 2013-09-18 13:40:42
|
After having demonstrated to myself repeatedly that I'm incapable of operating Darcs correctly, I finally broke down and imported Gtk2hs into Git. My cabal-1.18 branch[1] has the current state of my work to get Gtk2hs building with Cabal 1.18. My intention is to export these patches to apply against my Darcs tree when they are ready. Unfortunately, it's not clear to me how to manage various Cabal changes made in interfaces used by Gtk2HsSetup.hs (in particular programFindLocation) without breaking backwards compatibility. This is particularly problematic as Gtk2HsSetup.hs apparently doesn't have access to the CPP macros typically defined by Cabal. Cheers, - Ben [1] http://github.com/bgamari/gtk2hs/tree/cabal-1.18 |
From: <bga...@gm...> - 2013-09-07 02:06:08
|
Attached are two patches adding Cabal 1.18 compatibility and another updating some uses of the old IOError interfaces from GHC <7.6. 3 patches for repository http://code.haskell.org/gtk2hs: Fri Sep 6 22:01:08 EDT 2013 bg...@gm... * Cabal-1.18: Hide Distribution.Simple.Utils.moreRecentFile Fri Sep 6 22:01:41 EDT 2013 bg...@gm... * pango/Gtk2HsSetup: Update programFindLocation usage for Cabal 1.18 Fri Sep 6 22:02:43 EDT 2013 bg...@gm... * c2hs: Update IOError usage for GHC >= 7.6 |
From: Daniel W. <da...@wa...> - 2013-09-06 19:29:24
|
On 2013-09-04 23:48, Oliver Batchelor wrote: > I made a patch for a couple of small build script changes which let me > compile with cabal 1.18. > One of them at least would not be backward compatible (seems new > argument to a findProgramLocation) Awesome, thanks, I'll take a look. > On the other hand, the gtk package fails to compile with: > > Graphics/UI/Gtk/Printing/PrintOperation.chs:409:6: > Couldn't match expected type `Ptr ()' with actual type `Window' > In the return type of a call of `toWindow' > > On lines 409, 504 and 530. Yikes. Before I try to reproduce this, could you tell me whether you're trying to build gtk or gtk3, and what versions of GHC, gtk2hs-buildtools, and the gtk libraries you're using? ~d |
From: Daniel W. <da...@wa...> - 2013-08-12 17:27:20
|
Applied, thanks for both the patch and the reminder. ~d On 2013-08-12 06:35, Roman Cheplyaka wrote: > Hi, > > Could someone please apply my patch? > > http://sourceforge.net/mailarchive/forum.php?forum_name=gtk2hs-devel&max_rows=25&style=nested&viewmonth=201306 > > Roman > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Roman C. <ro...@ro...> - 2013-08-12 11:02:34
|
Hi, Could someone please apply my patch? http://sourceforge.net/mailarchive/forum.php?forum_name=gtk2hs-devel&max_rows=25&style=nested&viewmonth=201306 Roman |
From: Hamish M. <ham...@gm...> - 2013-08-11 12:31:28
|
On 11 Aug 2013, at 23:58, Carlo Hamalainen <ca...@ca...> wrote: > I copied the whole build tree here, along with a 'script' of the session Cool. This is the key line from those logs... setup: The pkg-config package gtk+-3.0 is required but it could not be found. It is looking in pkg-config for the gtk+-3.0 C header files and libraries. You probably just need to run... sudo apt-get install libgtksourceview-3.0-dev libwebkitgtk-3.0-dev This should make sure you have all the C headers and libraries for the gtk3 things that leksah uses. Hamish |
From: Daniel W. <wag...@se...> - 2013-07-17 13:44:23
|
On 2013-07-14 04:06, Hamish Mackenzie wrote: > cabal-meta does not like the gtk3 cabal file to be called gtk.cabal. > Please can we > > darcs move gtk.cabal gtk3.cabal Hm. I'm happy to do this; but will it work? Presumably then we would run into the problem that cabal-meta will want the gtk cabal file to be called gtk.cabal and not gtk3.cabal. Perhaps we should just not track a plain .cabal file at all, and just have gtk.cabal-invisible and gtk3.cabal-invisible, then copy the appropriate one to .cabal to make it visible when necessary. > We will need to update the build scripts. They also need to do a > clean in between building the gtk2 and gtk3 versions (to make sure > the hierarchy and chs files are reprocessed. Right, well spotted. > Everything else looked fine. > > I have prepared the gtk3 versions of the following packages... Cool, I'll take a look. I can't muck about with this stuff today, but I'll send a follow-up email when I know when I can muck with it. Possibly this weekend, but no promises yet. ~d > http://code.haskell.org/gtksourceview > gtksourceview2.cabal-renamed > gtksourceview3.cabal > > http://code.haskell.org/webkit > webkit.cabal-renamed > webkit3.cabal > > https://github.com/ghcjs/webkit-javascriptcore > webkit-javascriptcore.cabal-renamed > webkit3-javascriptcore.cabal > > http://code.haskell.org/ige-mac-integration > gtk-mac-integration.cabal-renamed > gtk3-mac-integration.cabal > > In each case there is an install-both.sh file if you want both > gtk2 and gtk3 versions installed. > > I have also tried to make sure the following packages can be installed > with gtk3 (or without by passing -f-gtk3). > > https://github.com/ghcjs/ghcjs-dom > https://github.com/ghcjs/jsc > https://github.com/leksah/haskellVCSGUI > https://github.com/leksah/ltk > https://github.com/leksah/leksah |
From: Daniel W. <wag...@se...> - 2013-07-17 13:42:46
|
On 2013-07-14 15:19, Hamish Mackenzie wrote: > One other thing. Removing the deprecated functions in gtk3.cabal is > fine with me, but toolbarSetIconSize is deprecated and I don't think > it should have been. > > The gtk3 docs for gtk_toolbar_set_icon_size list it as deprecated. > > We use it in Leksah like this... > > toolbarSetIconSize toolbar IconSizeSmallToolbar > > I have worked around this for now, but I think we should un-deprecate > it. Okay, I'll take a look. ~d |
From: Hamish M. <ham...@gm...> - 2013-07-14 19:19:31
|
One other thing. Removing the deprecated functions in gtk3.cabal is fine with me, but toolbarSetIconSize is deprecated and I don't think it should have been. The gtk3 docs for gtk_toolbar_set_icon_size list it as deprecated. We use it in Leksah like this... toolbarSetIconSize toolbar IconSizeSmallToolbar I have worked around this for now, but I think we should un-deprecate it. On 12 Jul 2013, at 04:31, Daniel Wagner <wag...@se...> wrote: > Okay, I obliterated the old patches. People following along at home > should do the same; specifically, I obliterated the patches named "add > the gtk3 package" and "begin a split into gtk and gtk3 packages". I also > pushed Hamish's changes and a few add-on cleanup ones of my own, > including making the two cabal files have different package names. > > Let me know if things aren't working for you. > > ~d > > On 2013-07-10 21:59, Hamish Mackenzie wrote: >> On 11 Jul 2013, at 07:45, Daniel Wagner <da...@wa...> wrote: >> >>> Awesome. I'll take a look in the morning. I might want the gtk3 bits >>> to go in their own package, rather than managing the difference with >>> version numbers; other than that a cursory glance says this is just >>> spot on. >> >> I think you are right, that would be better. >> * "cabal install gtk" and "cabal install gtk3" are nicer ways to >> choose versions >> * #ifdef MIN_VERSION_gtk3 is a bit nicer than #if >> MIN_VERSION_gtk(3,0,0) >> * Anyone with build depends of "gtk -any" will not get the rug pulled >> out from under them >> * I can't think of any disadvantages. >> >> It may even be possible to simplify gtk2hs version number checks if >> they both use the same version. For instance in leksah we use >> MIN_VERSION_gtk a lot and I was not looking forward to changing it. >> But we might be able to do something like... >> >> #ifdef MIN_VERSION_gtk3 >> #define MIN_VERSION_gtk(A,B,C) MIN_VERSION_gtk3(A,B,C) >> #endif >> >> At the top of files that use MIN_VERSION_gtk and it will work as >> expected if the version numbers are the same. >> >>> I'm not sure about the Hackage complaint... the thing uploaded to >>> Hackage predates all gtk3 efforts, doesn't it? >> >> I must have been fooled by cabal-src (I probably cabal-src-installed a >> gtk-0.12.4 that was broken). >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gtk2hs-devel mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Hamish M. <ham...@gm...> - 2013-07-14 08:06:23
|
Looks good just a couple of minor issues... cabal-meta does not like the gtk3 cabal file to be called gtk.cabal. Please can we darcs move gtk.cabal gtk3.cabal We will need to update the build scripts. They also need to do a clean in between building the gtk2 and gtk3 versions (to make sure the hierarchy and chs files are reprocessed. Everything else looked fine. I have prepared the gtk3 versions of the following packages... http://code.haskell.org/gtksourceview gtksourceview2.cabal-renamed gtksourceview3.cabal http://code.haskell.org/webkit webkit.cabal-renamed webkit3.cabal https://github.com/ghcjs/webkit-javascriptcore webkit-javascriptcore.cabal-renamed webkit3-javascriptcore.cabal http://code.haskell.org/ige-mac-integration gtk-mac-integration.cabal-renamed gtk3-mac-integration.cabal In each case there is an install-both.sh file if you want both gtk2 and gtk3 versions installed. I have also tried to make sure the following packages can be installed with gtk3 (or without by passing -f-gtk3). https://github.com/ghcjs/ghcjs-dom https://github.com/ghcjs/jsc https://github.com/leksah/haskellVCSGUI https://github.com/leksah/ltk https://github.com/leksah/leksah On 12 Jul 2013, at 04:31, Daniel Wagner <wag...@se...> wrote: > Okay, I obliterated the old patches. People following along at home > should do the same; specifically, I obliterated the patches named "add > the gtk3 package" and "begin a split into gtk and gtk3 packages". I also > pushed Hamish's changes and a few add-on cleanup ones of my own, > including making the two cabal files have different package names. > > Let me know if things aren't working for you. > > ~d > > On 2013-07-10 21:59, Hamish Mackenzie wrote: >> On 11 Jul 2013, at 07:45, Daniel Wagner <da...@wa...> wrote: >> >>> Awesome. I'll take a look in the morning. I might want the gtk3 bits >>> to go in their own package, rather than managing the difference with >>> version numbers; other than that a cursory glance says this is just >>> spot on. >> >> I think you are right, that would be better. >> * "cabal install gtk" and "cabal install gtk3" are nicer ways to >> choose versions >> * #ifdef MIN_VERSION_gtk3 is a bit nicer than #if >> MIN_VERSION_gtk(3,0,0) >> * Anyone with build depends of "gtk -any" will not get the rug pulled >> out from under them >> * I can't think of any disadvantages. >> >> It may even be possible to simplify gtk2hs version number checks if >> they both use the same version. For instance in leksah we use >> MIN_VERSION_gtk a lot and I was not looking forward to changing it. >> But we might be able to do something like... >> >> #ifdef MIN_VERSION_gtk3 >> #define MIN_VERSION_gtk(A,B,C) MIN_VERSION_gtk3(A,B,C) >> #endif >> >> At the top of files that use MIN_VERSION_gtk and it will work as >> expected if the version numbers are the same. >> >>> I'm not sure about the Hackage complaint... the thing uploaded to >>> Hackage predates all gtk3 efforts, doesn't it? >> >> I must have been fooled by cabal-src (I probably cabal-src-installed a >> gtk-0.12.4 that was broken). >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gtk2hs-devel mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Daniel W. <wag...@se...> - 2013-07-11 16:31:16
|
Okay, I obliterated the old patches. People following along at home should do the same; specifically, I obliterated the patches named "add the gtk3 package" and "begin a split into gtk and gtk3 packages". I also pushed Hamish's changes and a few add-on cleanup ones of my own, including making the two cabal files have different package names. Let me know if things aren't working for you. ~d On 2013-07-10 21:59, Hamish Mackenzie wrote: > On 11 Jul 2013, at 07:45, Daniel Wagner <da...@wa...> wrote: > >> Awesome. I'll take a look in the morning. I might want the gtk3 bits >> to go in their own package, rather than managing the difference with >> version numbers; other than that a cursory glance says this is just >> spot on. > > I think you are right, that would be better. > * "cabal install gtk" and "cabal install gtk3" are nicer ways to > choose versions > * #ifdef MIN_VERSION_gtk3 is a bit nicer than #if > MIN_VERSION_gtk(3,0,0) > * Anyone with build depends of "gtk -any" will not get the rug pulled > out from under them > * I can't think of any disadvantages. > > It may even be possible to simplify gtk2hs version number checks if > they both use the same version. For instance in leksah we use > MIN_VERSION_gtk a lot and I was not looking forward to changing it. > But we might be able to do something like... > > #ifdef MIN_VERSION_gtk3 > #define MIN_VERSION_gtk(A,B,C) MIN_VERSION_gtk3(A,B,C) > #endif > > At the top of files that use MIN_VERSION_gtk and it will work as > expected if the version numbers are the same. > >> I'm not sure about the Hackage complaint... the thing uploaded to >> Hackage predates all gtk3 efforts, doesn't it? > > I must have been fooled by cabal-src (I probably cabal-src-installed a > gtk-0.12.4 that was broken). > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Hamish M. <ham...@gm...> - 2013-07-11 01:59:57
|
On 11 Jul 2013, at 07:45, Daniel Wagner <da...@wa...> wrote: > Awesome. I'll take a look in the morning. I might want the gtk3 bits to go in their own package, rather than managing the difference with version numbers; other than that a cursory glance says this is just spot on. I think you are right, that would be better. * "cabal install gtk" and "cabal install gtk3" are nicer ways to choose versions * #ifdef MIN_VERSION_gtk3 is a bit nicer than #if MIN_VERSION_gtk(3,0,0) * Anyone with build depends of "gtk -any" will not get the rug pulled out from under them * I can't think of any disadvantages. It may even be possible to simplify gtk2hs version number checks if they both use the same version. For instance in leksah we use MIN_VERSION_gtk a lot and I was not looking forward to changing it. But we might be able to do something like... #ifdef MIN_VERSION_gtk3 #define MIN_VERSION_gtk(A,B,C) MIN_VERSION_gtk3(A,B,C) #endif At the top of files that use MIN_VERSION_gtk and it will work as expected if the version numbers are the same. > I'm not sure about the Hackage complaint... the thing uploaded to Hackage predates all gtk3 efforts, doesn't it? I must have been fooled by cabal-src (I probably cabal-src-installed a gtk-0.12.4 that was broken). |