On 11 Jul 2013, at 07:45, Daniel Wagner <dan...@wagner-home.com> 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 Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
