headers in sub-subdirectories, and gnustep-make 2.2.1
I implemented having headers in sub-subdirectories. For example, consider a framework called Beauty. Let's you have headers Beauty_HEADER_FILES = Beauty.h Vanity.h then your headers would be in Beauty/Beauty.h Beauty/Vanity.h and end up installed as in Beauty.framework/Beauty/Beauty.h Beauty.framework/Beauty/Vanity.h and you include them as in #import #import Now the new feature is that you can specify headers that live in subdirectories, as in Beauty_HEADER_FILES = Beauty.h Vanity.h Pride/Pride.h (note the last one, Pride/Pride.h) then your headers would be in Beauty/Beauty.h Beauty/Vanity.h Beauty/Pride/Pride.h and end up installed as in Beauty.framework/Headers/Beauty.h Beauty.framework/Headers/Vanity.h Beauty.framework/Headers/Pride/Pride.h (note: the last header requires creating a directory, which is now automatically created for you) and you include them as in #import #import #import --- As soon as this change has been tested, I'd like to release gnustep- make trunk as gnustep-make 2.2.1. I guess we could wait a week or two, then we could release. :-) I have other changes I'd like to make, but it's worth shipping the current batch of changes to end-users first. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: headers in sub-subdirectories, and gnustep-make 2.2.1
Am 07.02.2010 21:06, schrieb Nicola Pero: > I implemented having headers in sub-subdirectories. > > For example, consider a framework called Beauty. Let's you have headers > > Beauty_HEADER_FILES = Beauty.h Vanity.h > > then your headers would be in > > Beauty/Beauty.h > Beauty/Vanity.h > > and end up installed as in > > Beauty.framework/Beauty/Beauty.h > Beauty.framework/Beauty/Vanity.h > > and you include them as in > > #import > #import > > > Now the new feature is that you can specify headers that live in > subdirectories, as in > > Beauty_HEADER_FILES = Beauty.h Vanity.h Pride/Pride.h > > (note the last one, Pride/Pride.h) then your headers would be in > > Beauty/Beauty.h > Beauty/Vanity.h > Beauty/Pride/Pride.h > > and end up installed as in > > Beauty.framework/Headers/Beauty.h > Beauty.framework/Headers/Vanity.h > Beauty.framework/Headers/Pride/Pride.h > > (note: the last header requires creating a directory, which is now > automatically created for you) What does this mean? Do you have to break the installation in three steps. First install the rest, then create a directory manually and then install the last header file? I don't believe this is what you implemented. Could you just explain it a bit more? > and you include them as in > > #import > #import > #import > > --- > > As soon as this change has been tested, I'd like to release gnustep-make > trunk as gnustep-make 2.2.1. > > I guess we could wait a week or two, then we could release. :-) > > I have other changes I'd like to make, but it's worth shipping the > current batch of changes to end-users first. :-) > > Thanks > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r29500 - in /libs/gui/trunk: ChangeLog Source/NSToolbarItem.m
Am 07.02.2010 19:41, schrieb Riccardo Mottola: > Author: rmottola > Date: Sun Feb 7 19:41:04 2010 > New Revision: 29500 > > URL: http://svn.gna.org/viewcvs/gnustep?rev=29500&view=rev > Log: > use proper class check instead of quick and dirty size check for flexible > space property > > Modified: > libs/gui/trunk/ChangeLog > libs/gui/trunk/Source/NSToolbarItem.m Could you please explain why you changed this? I had made the opposite change a while ago to allow people to define their own flexible spaced toolbar items. This was in response to bug report #26339. I never learned whether my changed helped or not. But this seems to be normal for GNUstep bug reports. For some time now I decided that when people stop complaining after a fix their problem is most likely solved. But your change should break thinks again. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r29500 - in /libs/gui/trunk: ChangeLog Source/NSToolbarItem.m
Fred, sure, I discovered with a freely available open-source application (namely Grr, in GAP) that toolbar items did not work correctly. The current code in Grr yields a working and resizing toolbar on cocoa, but not on gnustep, where the last item after the flexible white space gets chopped off badly. The "old" code of Grr worked on GNUstep and not on Cocoa... Cocoa requires the min and max sizes of a toolbar item to be set if the toolbar item gets set a view (and the search field in Grr does so). The old GNUstep code just assumed that if min and max width were the same then the item was flexible space, I think this was wrong since it doesn't allow to have resizable items apart from the space. With my fix, the proper class is checked. The toolbar at least displays correctly and is usable! Resizing is however not as smart as on the mac, since it does not take in account of min and max size at all! In the whole toolbar code those sizes are not checked. I am trying to implement the smarter resizing code, I think I have the algorithm, but probably fail to correctly get the space to allocate. If I don't get a solution to, I'll share the patch with you. Riccardo Fred Kiefer wrote: Am 07.02.2010 19:41, schrieb Riccardo Mottola: Author: rmottola Date: Sun Feb 7 19:41:04 2010 New Revision: 29500 URL: http://svn.gna.org/viewcvs/gnustep?rev=29500&view=rev Log: use proper class check instead of quick and dirty size check for flexible space property Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/NSToolbarItem.m Could you please explain why you changed this? I had made the opposite change a while ago to allow people to define their own flexible spaced toolbar items. This was in response to bug report #26339. I never learned whether my changed helped or not. But this seems to be normal for GNUstep bug reports. For some time now I decided that when people stop complaining after a fix their problem is most likely solved. But your change should break thinks again. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r28556 - in /libs/gui/trunk: ChangeLog Source/GSTextStorage.h Source/GSTextStorage.
Hi Richard, Author: rfm Date: Thu Aug 27 16:57:00 2009 New Revision: 28556 URL: http://svn.gna.org/viewcvs/gnustep?rev=28556&view=rev Log: Fix bad return of proxy to user code Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/GSTextStorage.h libs/gui/trunk/Source/GSTextStorage.m I don't know what you attempted to fix here, but your change is definitely wrong and the old code which did return a proxy was correct. Here is the relevant quote from Apple's documentation of the NSAttributedString - string method: "For performance reasons, this method returns the current backing store of the attributed string object. If you want to maintain a snapshot of this as you manipulate the returned string, you should make a copy of the appropriate substring. This primitive method must guarantee efficient access to an attributed string's characters; subclasses should implement it to execute in O (1) time." Your change has introduced a nasty O(n^2) performance bug that makes a machine with a GB of RAM start thrashing during text layout when loading a ~100kB log file into a text view. Wolfgang PS: I've notice that GSAttributedString contains the same bug. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
