Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 5:31 PM, David Ayers wrote: Tim McIntosh schrieb: GNUstep seems to do a lot of mucking with the runtime structures that are no longer visible with Obj-C 2.0, so I think the changes I made were just barely scratching the surface in view of what is actually needed. Not being familiar enough with the GNUstep code base, I have to wonder if all of the direct use of the runtime APIs is really needed; I can see where it would be necessary on occasion within -base, but I was surprised by the number of times I saw it being used in higher-level frameworks. Indeed we heavily rely on that mucking in GDL2. But let me state this clearly... we are not mucking in the runtime for performance reasons... we are just trying to get WO45 compatibility. So if anyone has better ideas on how we can solve these issues with the public API of Foundation, I'm up for it! Thanks for the info and clarification. I didn't mean to pick on GDL2 here; I had just gotten the impression from experimenting with various things that the runtime API is used in a number of places outside of -base, and sometimes it was not clear why. I think part of this impression may have come from GSObjCRuntime.h getting pulled in by GSCategories.h in cases where it is not necessarily needed. This is why I was attempting to eliminate that #include. In any case, it looked to me like there may be a lot of work to do wrt supporting the GSObjCRuntime.h interface on the Apple's Obj-C 2.0 runtime (which is probably really only needed to support 64-bit; I can't see them removing the old APIs in the 32-bit version any time soon). Regards, Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
Tim McIntosh schrieb: > GNUstep seems to do a lot of mucking with the runtime structures that > are no longer visible with Obj-C 2.0, so I think the changes I made were > just barely scratching the surface in view of what is actually needed. > Not being familiar enough with the GNUstep code base, I have to wonder > if all of the direct use of the runtime APIs is really needed; I can > see where it would be necessary on occasion within -base, but I was > surprised by the number of times I saw it being used in higher-level > frameworks. Indeed we heavily rely on that mucking in GDL2. 1) KVC semantics... WO45 and -base/Cocoa just differ. (I'm still owe you a reply wrt but I still need clear up some misconception I might have had before I continue here). 2) EOEditingContext does not (necessarily) retain the objects it observes but should automagically remove them when the get dealloced. So here we muck with NSObjects -dealloc (yes, painful and I'm open to suggestions) (there maybe more... I haven't checked) Now if we would stop supporting OS X, I'm sure we could work something out with -base to make this cleaner... but I kind of doubt that would be in your interest ;-) But let me state this clearly... we are not mucking in the runtime for performance reasons... we are just trying to get WO45 compatibility. So if anyone has better ideas on how we can solve these issues with the public API of Foundation, I'm up for it! Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) Agreed. Please note that the option to set is -Wno-deprecated- declarations, not -Wno-deprecated. The latter is specific to C++. OK - thanks :-) The one question I have for you is will base.make be included when compiling something else, such as GDL2? Yes :-) BTW, it appears that clean_os.sh is a bit out of date (it only goes up through darwin7). Here's a patch that won't require each version of darwin to be listed separately. When the os is like darwin*, it strips everything from the first '.' on. This does introduce a dependency on sed, but my assumption is that any platform that has sh and can run this script will have sed. Do you agree? Yes, I agree that we can assume that sed is available ... It's an excellent patch, and I applied it. :-) Thanks PS: I made a tiny change to the patch due to my performance paranoia - won't make (almost) any difference. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 9:27 AM, Nicola Pero wrote: The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) It's been a few months, so I'm starting to forget everything, but IIRC, I did a small bit of work in this area when creating the GNUstepWeb packages for Mac OS X: http://hoth.radiofreeomaha.net:3000/~tmcintos/GNUstepWeb/ I believe I was also trying to reorganize some code to eliminate the need to include GSObjCRuntime.h in GSCategories.h and minimize the inclusion of GSObjCRuntime.h in general outside of -base. I was planning to go back and sort all of this out when I found some time-- reviewing everything, eliminating unnecessary changes, and breaking the remaining changes down into smaller patches that I could submit for consideration--but I haven't gotten around to that yet. GNUstep seems to do a lot of mucking with the runtime structures that are no longer visible with Obj-C 2.0, so I think the changes I made were just barely scratching the surface in view of what is actually needed. Not being familiar enough with the GNUstep code base, I have to wonder if all of the direct use of the runtime APIs is really needed; I can see where it would be necessary on occasion within - base, but I was surprised by the number of times I saw it being used in higher-level frameworks. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 10:27 AM, Nicola Pero wrote: On 30 Mar 2008, at 14:55, Blake Nicholson wrote: Nicola, Unfortunately, I think the sample output I sent was not a good representation. Sorry about that. I went ahead and built base under apple-apple-apple and redirected stderr to a file. I've attached the file so you can see all the error messages (many, many duplicates). Most of the error messages are from things in objc- gnu2next.h and GSObjCRuntime.h. Thanks ... OK, so we need to add the -Wno-deprecated everywhere in apple-gnu-gnu (and presumably, if you're compiling the gnustep-base Additions, also on apple-apple-apple). The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) Agreed. Please note that the option to set is -Wno-deprecated- declarations, not -Wno-deprecated. The latter is specific to C++. So I think that the right approach is: * have core/base/configure.ac detect that we're using the "new" Apple runtime [this test will be good in the future as well for when we actually add support for the new runtime ;-)] * in that case, have core/base/configure.ac add -Wno-deprecated to some autoconf output variable (eg, let's call it WNO_DEPRECATED_OBJCFLAGS), else leave it empty * have base.make.in set AUXILIARY_OBJFLAGS += @WNO_DEPRECATED_OBJCFLAGS@ when running with the Apple runtime Does that make any sense to you ? Thanks for your help The one question I have for you is will base.make be included when compiling something else, such as GDL2? Since other projects include GSCategories.h, which includes GSObjCRuntime.h and preface.h, AUXILIARY_OBJCFLAGS needs to be set for GNUstep projects besides base as well. BTW, it appears that clean_os.sh is a bit out of date (it only goes up through darwin7). Here's a patch that won't require each version of darwin to be listed separately. When the os is like darwin*, it strips everything from the first '.' on. This does introduce a dependency on sed, but my assumption is that any platform that has sh and can run this script will have sed. Do you agree? Index: clean_os.sh === --- clean_os.sh (revision 26396) +++ clean_os.sh (working copy) @@ -32,18 +32,10 @@ exit 0 ;; # Remove version number for Darwin -darwin7*) -echo darwin7 +darwin*) +echo `echo "$1" | sed s/..*//` exit 0 ;; -darwin6*) -echo darwin6 -exit 0 -;; -darwin5*) -echo darwin5 -exit 0 -;; *) echo $1 exit 0 Thanks, Blake ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: bindings and Renaissance
One thing I feel compelled to mention... Gorm is now "angostic" about the format it reads and saves. The reader/builder classes are what handle transformation to and from the internal data structures. Also, Gorm's editors allow editing of any kind of object (auto layout enabled or not). One of the features I'm going to add to Gorm soon is the ability to have "plugins" that will allow you to extend Gorm's capabilities without adding a palette. This will make it easier to add a reader/builder for Renaissance (or any other format you fancy). My dream for Gorm is to make it a "universal" GUI builder that can be adapted to almost anything. Later, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Nicola Pero <[EMAIL PROTECTED]> To: Gregory John Casamento <[EMAIL PROTECTED]> Cc: Xavier Glattard <[EMAIL PROTECTED]>; Fred Kiefer <[EMAIL PROTECTED]>; gnustep-dev@gnu.org Sent: Sunday, March 30, 2008 6:04:13 AM Subject: Re: bindings and Renaissance > Aren't you effectively writing code when you create the XML by hand? Good question. The Renaissance XML format was designed to be "a pleasure" to edit by hand; I personally like to edit the Renaissance XML files in emacs and find it very productive - very simple, short, logical, to the point, quick to edit, with all and only the relevant information displayed. :-) But I completely understand people who use Gorm which is a fantastic tool if you like visual editing. It's a different approach. The ideal scenario was to have a Renaissance/Gorm GUI builder (as we have discussed countless times, this would allow a lot of different approaches from an integrated app), but I have come to the realization that I'm not alone and there are other developers who actually like to edit the Renaissance XML files in their editor too! In fact the most exciting/excited users don't seem to care that much about the GUI builder. So I'm ignoring the GUI builder issue, and aiming for a stable, robust and complete Renaissance 1.0 release which will be complete but won't have a GUI builder. We'll work on the Gorm/Renaissance integration later, for Renaissance 2.0. :-) Btw, having different tools to build GUIs is great as it gives people a choice. Different tasks/developers are more or less suited to different tools. So it enriches GNUstep as a project to have various options available. :-) Also, we have two ways of attracting Apple developers to GNUstep / GNU; Gorm provides them with a free tool similar to the Apple one (attracting developers looking for something similar to Interface Builder); Renaissance provides them with something new/different (attracting developers looking for something different from Interface Builder). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On 30 Mar 2008, at 14:55, Blake Nicholson wrote: Nicola, Unfortunately, I think the sample output I sent was not a good representation. Sorry about that. I went ahead and built base under apple-apple-apple and redirected stderr to a file. I've attached the file so you can see all the error messages (many, many duplicates). Most of the error messages are from things in objc- gnu2next.h and GSObjCRuntime.h. Thanks ... OK, so we need to add the -Wno-deprecated everywhere in apple-gnu-gnu (and presumably, if you're compiling the gnustep-base Additions, also on apple-apple-apple). The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) So I think that the right approach is: * have core/base/configure.ac detect that we're using the "new" Apple runtime [this test will be good in the future as well for when we actually add support for the new runtime ;-)] * in that case, have core/base/configure.ac add -Wno-deprecated to some autoconf output variable (eg, let's call it WNO_DEPRECATED_OBJCFLAGS), else leave it empty * have base.make.in set AUXILIARY_OBJFLAGS += @WNO_DEPRECATED_OBJCFLAGS@ when running with the Apple runtime Does that make any sense to you ? Thanks for your help ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: bindings and Renaissance
If writting xml for Renaissance is coding then yes. When you write a Renaissance file you define the properties of the objects, and links between objects. When you write code you define the behavior of the objects. To write a gui for an application you can write objc code, you can use IB/Gorm, or you can write gsmarkup for Renaissance. I prefer the third way. If i could write the whole app the same way i would be happy :-) Selon Gregory John Casamento <[EMAIL PROTECTED]>: > Aren't you effectively writing code when you create the XML by hand? > > Gregory Casamento -- Principal Consultant - OLC, Inc > # GNUstep Chief Maintainer > > - Original Message > From: Xavier Glattard <[EMAIL PROTECTED]> > To: Gregory John Casamento <[EMAIL PROTECTED]> > Cc: Xavier Glattard <[EMAIL PROTECTED]>; Nicola Pero > <[EMAIL PROTECTED]>; Fred Kiefer <[EMAIL PROTECTED]>; > gnustep-dev@gnu.org > Sent: Saturday, March 29, 2008 6:28:52 PM > Subject: Re: bindings and Renaissance > > Selon Gregory John Casamento <[EMAIL PROTECTED]>: > > > One thing that springs immediately to mind is the connector classes for > > Binding. They have to be finished. Are you going to be using these in > > Renaissance? Do you currently use the existing connector classes? > > > > Mostly curious. :) > > > > GJC > > > > Gregory Casamento -- Principal Consultant - OLC, Inc > > # GNUstep Chief Maintainer > > I don't currently use any other connector, i'm new to Renaissance, but i'll > work > on it. > > Well... i'm lazy > Renaissance is a tool to build a gui without code. > Bindings are tools to bind a gui to a model without code. > I'm looking to Core Data that is a tool to build model without code. > > So : yes i would like to use Bindings in Renaissance. > > I would like to get a full RAD environment with GNUstep that allows to build > an > application without... you know what. Only XML. > > And if i really need some code i might use steptalk. > > Xavier, > lazy dreamer ^_^ > > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: bindings and Renaissance
> Aren't you effectively writing code when you create the XML by hand? Good question. The Renaissance XML format was designed to be "a pleasure" to edit by hand; I personally like to edit the Renaissance XML files in emacs and find it very productive - very simple, short, logical, to the point, quick to edit, with all and only the relevant information displayed. :-) But I completely understand people who use Gorm which is a fantastic tool if you like visual editing. It's a different approach. The ideal scenario was to have a Renaissance/Gorm GUI builder (as we have discussed countless times, this would allow a lot of different approaches from an integrated app), but I have come to the realization that I'm not alone and there are other developers who actually like to edit the Renaissance XML files in their editor too! In fact the most exciting/excited users don't seem to care that much about the GUI builder. So I'm ignoring the GUI builder issue, and aiming for a stable, robust and complete Renaissance 1.0 release which will be complete but won't have a GUI builder. We'll work on the Gorm/Renaissance integration later, for Renaissance 2.0. :-) Btw, having different tools to build GUIs is great as it gives people a choice. Different tasks/developers are more or less suited to different tools. So it enriches GNUstep as a project to have various options available. :-) Also, we have two ways of attracting Apple developers to GNUstep / GNU; Gorm provides them with a free tool similar to the Apple one (attracting developers looking for something similar to Interface Builder); Renaissance provides them with something new/different (attracting developers looking for something different from Interface Builder). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
