From: Ross M. <rmm-haskell@z.odi.ac> - 2008-11-26 02:04:19
|
Hi all, I tried to build my gtk2hs kit with --disable-deprecated, since I saw that the previous event hook functions I had been using such as onButtonPress had been deprecated and I have no reason to develop against the old interfaces. However, it turns out that gtk2hs didn't build once I had configured with --disable-deprecated for two reasons (and I won't go into how long it took me to nail it down to this -- it's embarrassing): - FileSelection is omitted from Gtk when GTK_DISABLE_DEPRECATED is defined, which --disable-deprecated does (among others). - Same with Tooltips. FileSelection apparently has been replaced with FileChooser and has a binding in gtk2hs, and it looks like Tooltips (plural) should be replaced with Tooltip (singular), but there is apparently no binding (yet?) for Tooltip. My question, then, is twofold... what is the policy on --disable-deprecated (should I give up on it early), and does anyone have a binding of Tooltip hanging around, or is one already in there that I didn't see? I can easily make the deprecated modules in gtk2hs not be built with --disable-deprecated, but without a replacement for Tooltips it seems like a bad idea. -Ross |
From: Axel S. <Axe...@en...> - 2008-11-27 10:42:29
|
On Tue, 2008-11-25 at 21:03 -0500, Ross Mellgren wrote: > Hi all, > > I tried to build my gtk2hs kit with --disable-deprecated, since I saw > that the previous event hook functions I had been using such as > onButtonPress had been deprecated and I have no reason to develop > against the old interfaces. > > However, it turns out that gtk2hs didn't build once I had configured > with --disable-deprecated for two reasons (and I won't go into how long > it took me to nail it down to this -- it's embarrassing): > > - FileSelection is omitted from Gtk when GTK_DISABLE_DEPRECATED is > defined, which --disable-deprecated does (among others). > - Same with Tooltips. > > FileSelection apparently has been replaced with FileChooser and has a > binding in gtk2hs, and it looks like Tooltips (plural) should be > replaced with Tooltip (singular), but there is apparently no binding > (yet?) for Tooltip. > > My question, then, is twofold... what is the policy on > --disable-deprecated (should I give up on it early), and does anyone > have a binding of Tooltip hanging around, or is one already in there > that I didn't see? I can easily make the deprecated modules in gtk2hs > not be built with --disable-deprecated, but without a replacement for > Tooltips it seems like a bad idea. I haven't tested the DISABLE_DEPRECATED variant in a long time. I'll try to get it to work again. With respect to Tooltip vs Tooltips: I don't think we have any code yet that is marked as deprecated starting from a certain version number of Gtk+. So far, the --disable-deprecated option was merely meant to disable parts of the Gtk2Hs API that has been superseded by other functionality. Thus, an API that exists in Gtk+ and in Gtk2Hs but is superseded by an new API in Gtk+ remains in Gtk2Hs as long as it remains in Gtk+. That was a bit of a mouth full. In a nutshell: We shall not remove APIs from Gtk2Hs just because they have been marked as deprecated in Gtk+. Hope this helps, Axel. > -Ross > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gtk2hs-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Axel S. <Axe...@en...> - 2008-12-03 09:58:44
|
On Sat, 2008-11-29 at 13:33 -0500, Ross Mellgren wrote: > > The approach I took for whole modules that were deprecated was to > AM_PARAMETER(DISABLE_DEPRECATED) into Makefile.am, and not add them to > the sources list in that case, and modify hierarchy.list similarly. > I'm not sure if this is the approach you would take, but I figured > that it seems the semantic meaning of --disable-deprecated is to > compile something that has no deprecated APIs, either in Gtk2hs > directly or the underlying Gtk+/Glib/Gdk. Um. As I've explained in my previous mail, I though of --disable-deprecated as a flag to exclude anything in Gtk2Hs that we think shouldn't be used anymore. To also pass this flag to CPP when compiling the Gtk+ headers was probably the original intend and maybe a sensible one. I guess it depends on why one wants to use this flag for which the answer is probably "Developers want to know that they use the latest features.". However, the developer might want to know that they use features of Gtk2Hs that won't go away anytime soon (my interpretation) or they want to use the latest and most bug-free features of Gtk+ (your interpretation). My interpretation is a must for anyone who wants his/her code to compile with future versions of Gtk2Hs since we're removing deprecated features with increasing versions (until we reach version 1.0). Gtk+ never removes any functions until the next major version (3.x). You interpretation implies more work, but is easy to check (since compilation will fall over). My interpretation is useful to generate documentation (as it allows us to exclude all functions that are deprecated). Maybe we should have different flags. But that's even more work. I'm currently undecided about this, so comments welcome. Cheers, Axel. > Here's the versions of the Gtk related stuff, so you know what version > of the library I was compiling against (and got build errors due to > missing symbols from headers): > > rmm@Hugo:/Library/Frameworks/Gtk.framework/Resources/dev/lib/pkgconfig > $ grep Version *.pc > atk.pc:Version: 1.24.0 > gdk-2.0.pc:Version: 2.14.3 > gdk-pixbuf-2.0.pc:Version: 2.14.3 > gdk-quartz-2.0.pc:Version: 2.14.3 > gtk+-2.0.pc:Version: 2.14.3 > gtk+-quartz-2.0.pc:Version: 2.14.3 > gtk+-unix-print-2.0.pc:Version: 2.14.3 > ige-mac-integration.pc:Version: 0.8.2 > pango.pc:Version: 1.22.0 > pangocairo.pc:Version: 1.22.0 > > rmm@Hugo:/Library/Frameworks/GLib.framework/Resources/dev/lib/pkgconfig > $ grep Version *.pc > gio-2.0.pc:Version: 2.18.1 > gio-unix-2.0.pc:Version: 2.18.1 > glib-2.0.pc:Version: 2.18.1 > gmodule-2.0.pc:Version: 2.18.1 > gmodule-export-2.0.pc:Version: 2.18.1 > gmodule-no-export-2.0.pc:Version: 2.18.1 > gobject-2.0.pc:Version: 2.18.1 > gthread-2.0.pc:Version: 2.18.1 > > rmm@Hugo:/Library/Frameworks/Cairo.framework/Resources/dev/lib/ > pkgconfig$ grep Version *.pc > cairo-pdf.pc:Version: 1.7.6 > cairo-png.pc:Version: 1.7.6 > cairo-ps.pc:Version: 1.7.6 > cairo-quartz-font.pc:Version: 1.7.6 > cairo-quartz.pc:Version: 1.7.6 > cairo-svg.pc:Version: 1.7.6 > cairo.pc:Version: 1.7.6 > pixman-1.pc:Version: 0.12.0 > > > Thanks for taking a look! > -Ross > > On Nov 28, 2008, at 7:47 AM, Axel Simon wrote: > > > On Thu, 2008-11-27 at 14:03 -0500, Ross Mellgren wrote: > >> I spent a night trying to get --disable-deprecated to work, but I > >> didn't > >> have success. There were a bunch of places where the > >> *_DISABLE_DEPRECATED defines cause Gtk+ and the other libraries to > >> cease > >> exporting things, such as Tooltips. > >> > >> I can send you the patch I stashed before giving up on it, if you're > >> interested. > > > > Yes, that'd be helpful! > > > > Thanks, > > Axel. > >> -Ross > >> > >> > >> Axel Simon wrote: > >>> On Tue, 2008-11-25 at 21:03 -0500, Ross Mellgren wrote: > >>>> Hi all, > >>>> > >>>> I tried to build my gtk2hs kit with --disable-deprecated, since I > >>>> saw > >>>> that the previous event hook functions I had been using such as > >>>> onButtonPress had been deprecated and I have no reason to develop > >>>> against the old interfaces. > >>>> > >>>> However, it turns out that gtk2hs didn't build once I had > >>>> configured > >>>> with --disable-deprecated for two reasons (and I won't go into > >>>> how long > >>>> it took me to nail it down to this -- it's embarrassing): > >>>> > >>>> - FileSelection is omitted from Gtk when GTK_DISABLE_DEPRECATED is > >>>> defined, which --disable-deprecated does (among others). > >>>> - Same with Tooltips. > >>>> > >>>> FileSelection apparently has been replaced with FileChooser and > >>>> has a > >>>> binding in gtk2hs, and it looks like Tooltips (plural) should be > >>>> replaced with Tooltip (singular), but there is apparently no > >>>> binding > >>>> (yet?) for Tooltip. > >>>> > >>>> My question, then, is twofold... what is the policy on > >>>> --disable-deprecated (should I give up on it early), and does > >>>> anyone > >>>> have a binding of Tooltip hanging around, or is one already in > >>>> there > >>>> that I didn't see? I can easily make the deprecated modules in > >>>> gtk2hs > >>>> not be built with --disable-deprecated, but without a replacement > >>>> for > >>>> Tooltips it seems like a bad idea. > >>> > >>> I haven't tested the DISABLE_DEPRECATED variant in a long time. > >>> I'll try > >>> to get it to work again. > >>> > >>> With respect to Tooltip vs Tooltips: I don't think we have any > >>> code yet > >>> that is marked as deprecated starting from a certain version > >>> number of > >>> Gtk+. So far, the --disable-deprecated option was merely meant to > >>> disable parts of the Gtk2Hs API that has been superseded by other > >>> functionality. Thus, an API that exists in Gtk+ and in Gtk2Hs but is > >>> superseded by an new API in Gtk+ remains in Gtk2Hs as long as it > >>> remains > >>> in Gtk+. That was a bit of a mouth full. In a nutshell: We shall not > >>> remove APIs from Gtk2Hs just because they have been marked as > >>> deprecated > >>> in Gtk+. > >>> > >>> Hope this helps, > >>> Axel. > >>> > >>> > >>> > >>> > >>>> -Ross > >>>> > >>>> > >>>> ------------------------------------------------------------------------- > >>>> This SF.Net email is sponsored by the Moblin Your Move > >>>> Developer's challenge > >>>> Build the coolest Linux based applications with Moblin SDK & win > >>>> great prizes > >>>> Grand prize is a trip for two to an Open Source event anywhere in > >>>> the world > >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >>>> _______________________________________________ > >>>> Gtk2hs-devel mailing list > >>>> Gtk...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel > >>> > > > |
From: Ross M. <rmm-haskell@z.odi.ac> - 2008-12-03 14:28:52
|
Hey Axel, As I've said, I've given up on trying to make --disable-deprecated work... I also don't have a particular attachment to any interpretation of how it should work (or even work at all ;-) ). If you want to throw away my patch to do something you feel is better, that's perfectly fine by me. I just went along a path and captured my delta just before I gave up and threw away the code. My goal was to make gtk2hs compile with the flag on, and since Gtk+ stopped exposing those symbols when the _DISABLE_DEPRECATED defines were given (which I didn't add btw, those were there when I got to the scene of the crime) it seemed like the right thing to do was to stop building the Gtk2hs components that wrapped them. I only removed the whole module in the case where the whole module was affected (e.g. FileSelection) -- for single functions I just elided those particular functions. Maybe I'm not understanding where you're going with this... what do you suggest is done in particular? It sounds like your interpretation would be to remove the _DISABLE_DEPRECATED defines that Gtk+ uses from the build, so that the functions/types deprecated in Gtk+ are still available, and only those deprecated in Gtk2hs are disabled. I'm definitely confused by this thread, so sorry about the confusion :-/ -Ross On Dec 3, 2008, at 4:58 AM, Axel Simon wrote: > On Sat, 2008-11-29 at 13:33 -0500, Ross Mellgren wrote: >> >> The approach I took for whole modules that were deprecated was to >> AM_PARAMETER(DISABLE_DEPRECATED) into Makefile.am, and not add them >> to >> the sources list in that case, and modify hierarchy.list similarly. >> I'm not sure if this is the approach you would take, but I figured >> that it seems the semantic meaning of --disable-deprecated is to >> compile something that has no deprecated APIs, either in Gtk2hs >> directly or the underlying Gtk+/Glib/Gdk. > > Um. As I've explained in my previous mail, I though of > --disable-deprecated as a flag to exclude anything in Gtk2Hs that we > think shouldn't be used anymore. To also pass this flag to CPP when > compiling the Gtk+ headers was probably the original intend and > maybe a > sensible one. I guess it depends on why one wants to use this flag for > which the answer is probably "Developers want to know that they use > the > latest features.". However, the developer might want to know that they > use features of Gtk2Hs that won't go away anytime soon (my > interpretation) or they want to use the latest and most bug-free > features of Gtk+ (your interpretation). My interpretation is a must > for > anyone who wants his/her code to compile with future versions of > Gtk2Hs > since we're removing deprecated features with increasing versions > (until > we reach version 1.0). Gtk+ never removes any functions until the next > major version (3.x). > > You interpretation implies more work, but is easy to check (since > compilation will fall over). My interpretation is useful to generate > documentation (as it allows us to exclude all functions that are > deprecated). > > Maybe we should have different flags. But that's even more work. I'm > currently undecided about this, so comments welcome. > > Cheers, > Axel. > >> Here's the versions of the Gtk related stuff, so you know what >> version >> of the library I was compiling against (and got build errors due to >> missing symbols from headers): >> >> rmm@Hugo:/Library/Frameworks/Gtk.framework/Resources/dev/lib/ >> pkgconfig >> $ grep Version *.pc >> atk.pc:Version: 1.24.0 >> gdk-2.0.pc:Version: 2.14.3 >> gdk-pixbuf-2.0.pc:Version: 2.14.3 >> gdk-quartz-2.0.pc:Version: 2.14.3 >> gtk+-2.0.pc:Version: 2.14.3 >> gtk+-quartz-2.0.pc:Version: 2.14.3 >> gtk+-unix-print-2.0.pc:Version: 2.14.3 >> ige-mac-integration.pc:Version: 0.8.2 >> pango.pc:Version: 1.22.0 >> pangocairo.pc:Version: 1.22.0 >> >> rmm@Hugo:/Library/Frameworks/GLib.framework/Resources/dev/lib/ >> pkgconfig >> $ grep Version *.pc >> gio-2.0.pc:Version: 2.18.1 >> gio-unix-2.0.pc:Version: 2.18.1 >> glib-2.0.pc:Version: 2.18.1 >> gmodule-2.0.pc:Version: 2.18.1 >> gmodule-export-2.0.pc:Version: 2.18.1 >> gmodule-no-export-2.0.pc:Version: 2.18.1 >> gobject-2.0.pc:Version: 2.18.1 >> gthread-2.0.pc:Version: 2.18.1 >> >> rmm@Hugo:/Library/Frameworks/Cairo.framework/Resources/dev/lib/ >> pkgconfig$ grep Version *.pc >> cairo-pdf.pc:Version: 1.7.6 >> cairo-png.pc:Version: 1.7.6 >> cairo-ps.pc:Version: 1.7.6 >> cairo-quartz-font.pc:Version: 1.7.6 >> cairo-quartz.pc:Version: 1.7.6 >> cairo-svg.pc:Version: 1.7.6 >> cairo.pc:Version: 1.7.6 >> pixman-1.pc:Version: 0.12.0 >> >> >> Thanks for taking a look! >> -Ross >> >> On Nov 28, 2008, at 7:47 AM, Axel Simon wrote: >> >>> On Thu, 2008-11-27 at 14:03 -0500, Ross Mellgren wrote: >>>> I spent a night trying to get --disable-deprecated to work, but I >>>> didn't >>>> have success. There were a bunch of places where the >>>> *_DISABLE_DEPRECATED defines cause Gtk+ and the other libraries to >>>> cease >>>> exporting things, such as Tooltips. >>>> >>>> I can send you the patch I stashed before giving up on it, if >>>> you're >>>> interested. >>> >>> Yes, that'd be helpful! >>> >>> Thanks, >>> Axel. >>>> -Ross >>>> >>>> >>>> Axel Simon wrote: >>>>> On Tue, 2008-11-25 at 21:03 -0500, Ross Mellgren wrote: >>>>>> Hi all, >>>>>> >>>>>> I tried to build my gtk2hs kit with --disable-deprecated, since I >>>>>> saw >>>>>> that the previous event hook functions I had been using such as >>>>>> onButtonPress had been deprecated and I have no reason to develop >>>>>> against the old interfaces. >>>>>> >>>>>> However, it turns out that gtk2hs didn't build once I had >>>>>> configured >>>>>> with --disable-deprecated for two reasons (and I won't go into >>>>>> how long >>>>>> it took me to nail it down to this -- it's embarrassing): >>>>>> >>>>>> - FileSelection is omitted from Gtk when GTK_DISABLE_DEPRECATED >>>>>> is >>>>>> defined, which --disable-deprecated does (among others). >>>>>> - Same with Tooltips. >>>>>> >>>>>> FileSelection apparently has been replaced with FileChooser and >>>>>> has a >>>>>> binding in gtk2hs, and it looks like Tooltips (plural) should be >>>>>> replaced with Tooltip (singular), but there is apparently no >>>>>> binding >>>>>> (yet?) for Tooltip. >>>>>> >>>>>> My question, then, is twofold... what is the policy on >>>>>> --disable-deprecated (should I give up on it early), and does >>>>>> anyone >>>>>> have a binding of Tooltip hanging around, or is one already in >>>>>> there >>>>>> that I didn't see? I can easily make the deprecated modules in >>>>>> gtk2hs >>>>>> not be built with --disable-deprecated, but without a replacement >>>>>> for >>>>>> Tooltips it seems like a bad idea. >>>>> >>>>> I haven't tested the DISABLE_DEPRECATED variant in a long time. >>>>> I'll try >>>>> to get it to work again. >>>>> >>>>> With respect to Tooltip vs Tooltips: I don't think we have any >>>>> code yet >>>>> that is marked as deprecated starting from a certain version >>>>> number of >>>>> Gtk+. So far, the --disable-deprecated option was merely meant to >>>>> disable parts of the Gtk2Hs API that has been superseded by other >>>>> functionality. Thus, an API that exists in Gtk+ and in Gtk2Hs >>>>> but is >>>>> superseded by an new API in Gtk+ remains in Gtk2Hs as long as it >>>>> remains >>>>> in Gtk+. That was a bit of a mouth full. In a nutshell: We shall >>>>> not >>>>> remove APIs from Gtk2Hs just because they have been marked as >>>>> deprecated >>>>> in Gtk+. >>>>> >>>>> Hope this helps, >>>>> Axel. >>>>> >>>>> >>>>> >>>>> >>>>>> -Ross >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.Net email is sponsored by the Moblin Your Move >>>>>> Developer's challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>>> great prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in >>>>>> the world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> Gtk2hs-devel mailing list >>>>>> Gtk...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel >>>>> >>> >> > |
From: Axel S. <Axe...@en...> - 2008-12-03 14:32:35
|
On Wed, 2008-12-03 at 09:28 -0500, Ross Mellgren wrote: > Hey Axel, > > As I've said, I've given up on trying to make --disable-deprecated > work... I also don't have a particular attachment to any > interpretation of how it should work (or even work at all ;-) ). If > you want to throw away my patch to do something you feel is better, > that's perfectly fine by me. I just went along a path and captured my > delta just before I gave up and threw away the code. > > My goal was to make gtk2hs compile with the flag on, and since Gtk+ > stopped exposing those symbols when the _DISABLE_DEPRECATED defines > were given (which I didn't add btw, those were there when I got to the > scene of the crime) it seemed like the right thing to do was to stop > building the Gtk2hs components that wrapped them. Yes, so I guess I'm the one who's giving this flag a second interpretation now. > I only removed the whole module in the case where the whole module was > affected (e.g. FileSelection) -- for single functions I just elided > those particular functions. > > Maybe I'm not understanding where you're going with this... what do > you suggest is done in particular? It sounds like your interpretation > would be to remove the _DISABLE_DEPRECATED defines that Gtk+ uses from > the build, so that the functions/types deprecated in Gtk+ are still > available, and only those deprecated in Gtk2hs are disabled. Yes, that what was I was suggesting. If I got some time on my hands, I might make this flag work again, with either of the interpretations. Thanks for raising the issue, though, Axel. > I'm definitely confused by this thread, so sorry about the confusion :-/ > > -Ross > > > On Dec 3, 2008, at 4:58 AM, Axel Simon wrote: > > > On Sat, 2008-11-29 at 13:33 -0500, Ross Mellgren wrote: > >> > >> The approach I took for whole modules that were deprecated was to > >> AM_PARAMETER(DISABLE_DEPRECATED) into Makefile.am, and not add them > >> to > >> the sources list in that case, and modify hierarchy.list similarly. > >> I'm not sure if this is the approach you would take, but I figured > >> that it seems the semantic meaning of --disable-deprecated is to > >> compile something that has no deprecated APIs, either in Gtk2hs > >> directly or the underlying Gtk+/Glib/Gdk. > > > > Um. As I've explained in my previous mail, I though of > > --disable-deprecated as a flag to exclude anything in Gtk2Hs that we > > think shouldn't be used anymore. To also pass this flag to CPP when > > compiling the Gtk+ headers was probably the original intend and > > maybe a > > sensible one. I guess it depends on why one wants to use this flag for > > which the answer is probably "Developers want to know that they use > > the > > latest features.". However, the developer might want to know that they > > use features of Gtk2Hs that won't go away anytime soon (my > > interpretation) or they want to use the latest and most bug-free > > features of Gtk+ (your interpretation). My interpretation is a must > > for > > anyone who wants his/her code to compile with future versions of > > Gtk2Hs > > since we're removing deprecated features with increasing versions > > (until > > we reach version 1.0). Gtk+ never removes any functions until the next > > major version (3.x). > > > > You interpretation implies more work, but is easy to check (since > > compilation will fall over). My interpretation is useful to generate > > documentation (as it allows us to exclude all functions that are > > deprecated). > > > > Maybe we should have different flags. But that's even more work. I'm > > currently undecided about this, so comments welcome. > > > > Cheers, > > Axel. > > > >> Here's the versions of the Gtk related stuff, so you know what > >> version > >> of the library I was compiling against (and got build errors due to > >> missing symbols from headers): > >> > >> rmm@Hugo:/Library/Frameworks/Gtk.framework/Resources/dev/lib/ > >> pkgconfig > >> $ grep Version *.pc > >> atk.pc:Version: 1.24.0 > >> gdk-2.0.pc:Version: 2.14.3 > >> gdk-pixbuf-2.0.pc:Version: 2.14.3 > >> gdk-quartz-2.0.pc:Version: 2.14.3 > >> gtk+-2.0.pc:Version: 2.14.3 > >> gtk+-quartz-2.0.pc:Version: 2.14.3 > >> gtk+-unix-print-2.0.pc:Version: 2.14.3 > >> ige-mac-integration.pc:Version: 0.8.2 > >> pango.pc:Version: 1.22.0 > >> pangocairo.pc:Version: 1.22.0 > >> > >> rmm@Hugo:/Library/Frameworks/GLib.framework/Resources/dev/lib/ > >> pkgconfig > >> $ grep Version *.pc > >> gio-2.0.pc:Version: 2.18.1 > >> gio-unix-2.0.pc:Version: 2.18.1 > >> glib-2.0.pc:Version: 2.18.1 > >> gmodule-2.0.pc:Version: 2.18.1 > >> gmodule-export-2.0.pc:Version: 2.18.1 > >> gmodule-no-export-2.0.pc:Version: 2.18.1 > >> gobject-2.0.pc:Version: 2.18.1 > >> gthread-2.0.pc:Version: 2.18.1 > >> > >> rmm@Hugo:/Library/Frameworks/Cairo.framework/Resources/dev/lib/ > >> pkgconfig$ grep Version *.pc > >> cairo-pdf.pc:Version: 1.7.6 > >> cairo-png.pc:Version: 1.7.6 > >> cairo-ps.pc:Version: 1.7.6 > >> cairo-quartz-font.pc:Version: 1.7.6 > >> cairo-quartz.pc:Version: 1.7.6 > >> cairo-svg.pc:Version: 1.7.6 > >> cairo.pc:Version: 1.7.6 > >> pixman-1.pc:Version: 0.12.0 > >> > >> > >> Thanks for taking a look! > >> -Ross > >> > >> On Nov 28, 2008, at 7:47 AM, Axel Simon wrote: > >> > >>> On Thu, 2008-11-27 at 14:03 -0500, Ross Mellgren wrote: > >>>> I spent a night trying to get --disable-deprecated to work, but I > >>>> didn't > >>>> have success. There were a bunch of places where the > >>>> *_DISABLE_DEPRECATED defines cause Gtk+ and the other libraries to > >>>> cease > >>>> exporting things, such as Tooltips. > >>>> > >>>> I can send you the patch I stashed before giving up on it, if > >>>> you're > >>>> interested. > >>> > >>> Yes, that'd be helpful! > >>> > >>> Thanks, > >>> Axel. > >>>> -Ross > >>>> > >>>> > >>>> Axel Simon wrote: > >>>>> On Tue, 2008-11-25 at 21:03 -0500, Ross Mellgren wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I tried to build my gtk2hs kit with --disable-deprecated, since I > >>>>>> saw > >>>>>> that the previous event hook functions I had been using such as > >>>>>> onButtonPress had been deprecated and I have no reason to develop > >>>>>> against the old interfaces. > >>>>>> > >>>>>> However, it turns out that gtk2hs didn't build once I had > >>>>>> configured > >>>>>> with --disable-deprecated for two reasons (and I won't go into > >>>>>> how long > >>>>>> it took me to nail it down to this -- it's embarrassing): > >>>>>> > >>>>>> - FileSelection is omitted from Gtk when GTK_DISABLE_DEPRECATED > >>>>>> is > >>>>>> defined, which --disable-deprecated does (among others). > >>>>>> - Same with Tooltips. > >>>>>> > >>>>>> FileSelection apparently has been replaced with FileChooser and > >>>>>> has a > >>>>>> binding in gtk2hs, and it looks like Tooltips (plural) should be > >>>>>> replaced with Tooltip (singular), but there is apparently no > >>>>>> binding > >>>>>> (yet?) for Tooltip. > >>>>>> > >>>>>> My question, then, is twofold... what is the policy on > >>>>>> --disable-deprecated (should I give up on it early), and does > >>>>>> anyone > >>>>>> have a binding of Tooltip hanging around, or is one already in > >>>>>> there > >>>>>> that I didn't see? I can easily make the deprecated modules in > >>>>>> gtk2hs > >>>>>> not be built with --disable-deprecated, but without a replacement > >>>>>> for > >>>>>> Tooltips it seems like a bad idea. > >>>>> > >>>>> I haven't tested the DISABLE_DEPRECATED variant in a long time. > >>>>> I'll try > >>>>> to get it to work again. > >>>>> > >>>>> With respect to Tooltip vs Tooltips: I don't think we have any > >>>>> code yet > >>>>> that is marked as deprecated starting from a certain version > >>>>> number of > >>>>> Gtk+. So far, the --disable-deprecated option was merely meant to > >>>>> disable parts of the Gtk2Hs API that has been superseded by other > >>>>> functionality. Thus, an API that exists in Gtk+ and in Gtk2Hs > >>>>> but is > >>>>> superseded by an new API in Gtk+ remains in Gtk2Hs as long as it > >>>>> remains > >>>>> in Gtk+. That was a bit of a mouth full. In a nutshell: We shall > >>>>> not > >>>>> remove APIs from Gtk2Hs just because they have been marked as > >>>>> deprecated > >>>>> in Gtk+. > >>>>> > >>>>> Hope this helps, > >>>>> Axel. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -Ross > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------------- > >>>>>> This SF.Net email is sponsored by the Moblin Your Move > >>>>>> Developer's challenge > >>>>>> Build the coolest Linux based applications with Moblin SDK & win > >>>>>> great prizes > >>>>>> Grand prize is a trip for two to an Open Source event anywhere in > >>>>>> the world > >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >>>>>> _______________________________________________ > >>>>>> Gtk2hs-devel mailing list > >>>>>> Gtk...@li... > >>>>>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel > >>>>> > >>> > >> > > |