Re: Looking like Windows on Windows
On 7/11/05, Jonathan 'Wolf' Rentzsch <[EMAIL PROTECTED]> wrote: > Hi all, > > What can I do to make my GNUstep/Windows app look like a 'native' windows > app? > > I know there's still work to me done making the menubar act like Windows' > per-window menubar, so I'm not asking about that. > > Instead, I'd like my app to look less foreign. Using the system-supplied > colors and at least paint widgets that look like WinXP widgets. > > I know WindowMaker is themeable, but I haven't seen a WinXP-style theme > for it. In fact, WindowMaker themes seem limited to just replacing widget > backgrounds and fonts. Keep in mind that WindowMaker has NO relations with GNUstep, other than beeing the prefferred window manager under X11. WindowMaker doesn't use GNUstep, is programmed in C, etc. It uses its own toolkit, so any toolkit comparisons between GNUstep and wmaker are meaningless... The "plan" (at least mine) to have GNUstep apps looking like windows apps is to create a Camaelon theme, and possibly another gui bundle so that GNUstep system colors would be read from the windows system colorlist. Note that you could also change the system colorlist on gnustep already, either by hand (add them in your defaults), by code, or by using the Preferences.app colorpref module. With the right colors (http://www.roard.com/screenshots/gnustep-windows.png) gnustep apps looks more integrated (I believe the gdi backend has now resolved the "black" parts in transparent images, right?). Note the winzip window in the lower right of the sshot. Of course, a real "windows theme" would be ideal. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Mon Jul 11 06:34:11 EDT 2005 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf2.0.2 Mon Jul 11 03:58:24 CEST 2005 Success Compile powerpc-apple-darwin7.9.0 Mon Jul 11 03:22:19 MDT 2005 Success Compile sparc-sun-solaris2.7 Mon Jul 11 02:09:25 EDT 2005
Re: Looking like Windows on Windows
On 2005-07-11 11:44:33 +0100 Nicolas Roard <[EMAIL PROTECTED]> wrote: The "plan" (at least mine) to have GNUstep apps looking like windows apps is to create a Camaelon theme, and possibly another gui bundle so that GNUstep system colors would be read from the windows system colorlist. Note that you could also change the system colorlist on gnustep already, either by hand (add them in your defaults), by code, or by using the Preferences.app colorpref module. With the right colors (http://www.roard.com/screenshots/gnustep-windows.png) gnustep apps looks more integrated (I believe the gdi backend has now resolved the "black" parts in transparent images, right?). Note the winzip window in the lower right of the sshot. Of course, a real "windows theme" would be ideal. I heartily endorse this ... I do not want my GNUstep applications to look like windows applications (I don't like the windows look and feel), but I do want to have that available ... so I would really like to see a good windows theme that could be bundled with windows distributions so that people clearly have the various native looks available to them. I'm looking forward to the next release of Camaeleon. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:15:27 Modified files: dev-apps/Gorm : ChangeLog Log message: improve NSForm / update documentation CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.702&tr2=1.703&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/2Controls/Contro...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:12:12 Modified files: dev-apps/Gorm/Palettes/2Controls/ControlsPalette.gorm: data.info objects.gorm Log message: Fix bad layout when doing a matrix of NSForms CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/2Controls/ControlsPalette.gorm/data.info.diff?tr1=1.4&tr2=1.5&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/2Controls/ControlsPalette.gorm/objects.gorm.diff?tr1=1.5&tr2=1.6&r1=text&r2=text
Re: GUI/back changes in CVS
Adrian Robert wrote: > > On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: > >> I just added changes to GUI and back that will in the end allow pattern >> images for GNUstep and the new MacOSX composite operator that uses an >> addtional alpha value. I wanted these changes to go into the next >> release as this will break binary compatibility between GUI and back. I >> have tested this change with xlib. It would be great, if somebody could >> test it before the release with art and winlib. > > Is there an easy way to test it? Is there something in the new test > suite that exercises this facility? > > Here is the simple application I tested with. But I am not even sure if the different operators have been implemented correctly for xlib, but thenm only one of the images I use has alpha values. Perhaps I should test with to transparent images. composite.tgz Description: application/compressed-tar ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 14:01:58 Modified files: dev-apps/Gorm : ChangeLog Log message: set intialFirstResponder to some inspectors CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.703&tr2=1.704&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/English.lproj/GormViewSiz...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 14:01:07 Modified files: dev-apps/Gorm/English.lproj/GormViewSizeInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/English.lproj/GormViewSizeInspector.gorm/objects.gorm.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/English.lproj/GormScrollV...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 14:00:18 Modified files: dev-apps/Gorm/English.lproj/GormScrollViewAttributesInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/English.lproj/GormScrollViewAttributesInspector.gorm/objects.gorm.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/English.lproj/GormCustomC...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:59:23 Modified files: dev-apps/Gorm/English.lproj/GormCustomClassInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/English.lproj/GormCustomClassInspector.gorm/objects.gorm.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/4Data/GormNSNumb...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:57:55 Modified files: dev-apps/Gorm/Palettes/4Data/GormNSNumberFormatterInspector.gorm: data.info objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/4Data/GormNSNumberFormatterInspector.gorm/data.info.diff?tr1=1.2&tr2=1.3&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/4Data/GormNSNumberFormatterInspector.gorm/objects.gorm.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/4Data/GormNSDate...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:57:10 Modified files: dev-apps/Gorm/Palettes/4Data/GormNSDateFormatterInspector.gorm: data.info objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/4Data/GormNSDateFormatterInspector.gorm/data.info.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/4Data/GormNSDateFormatterInspector.gorm/objects.gorm.diff?tr1=1.8&tr2=1.9&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/3Containers/Gorm...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:55:32 Modified files: dev-apps/Gorm/Palettes/3Containers/GormNSTableColumnInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/3Containers/GormNSTableColumnInspector.gorm/objects.gorm.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/2Controls/GormNS...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:53:58 Modified files: dev-apps/Gorm/Palettes/2Controls/GormNSCellInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/2Controls/GormNSCellInspector.gorm/objects.gorm.diff?tr1=1.5&tr2=1.6&r1=text&r2=text
Re: GUI/back changes in CVS
Nicolas Roard wrote: > On 7/11/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: >>Adrian Robert wrote: >>>On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: >>> I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. >>>Is there an easy way to test it? Is there something in the new test >>>suite that exercises this facility? >>> >>> >>Here is the simple application I tested with. But I am not even sure if >>the different operators have been implemented correctly for xlib, but >>thenm only one of the images I use has alpha values. Perhaps I should >>test with to transparent images. > > This test is only for composition, but what about the pattern images ? > The "filling patterns" you are talking about, is setting an image to > a color and then fill something with this color, right ? > > I'm asking because when I profiled Camaelon, pattern filling was one > of the thing that took lots of time, and i'm hoping that by having the > possibility to use filling pattern directly it will be faster (as you > shouldn't need context switching during the filling). > > And, does it properly follow the current path mask ? (actually I think > that doesn't work on xlib, only with art, anyway...) > Sorry, some things seem to have gotten mixed here. I wrote that "in the end" this will "allow pattern images". They are not already there after the first patch. Support for pattern colours requires two steps in the backend: It needs to know, which image pattern to use, which is what I implemented (the result of a pattern colour set command). And it needs to draw this image, when a fill operation happens. I did not even work on this second bit. Now art has an implementation of the very powerfull shfill PS command. This allows, amongst other things, a pattern fill. So here the second bit is already persent, while the first bit was missing. It should be rather simple to implement full pattern colours drawing for the art backend now. But this is nothing I am planning to do. The whole structure of the art backend is very foreign to me. I don't dare to touch anything here, because I may easily break things in an environment that is so contrary to the way I normally program. What I was planning to do was add a simple (and of course slow) pattern drawing mechanism for the gsc classes and perhaps overwrite this with a faster one for the xlib backend. Perhaps you could add the art pattern fill bit and I provide the rest? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/2Controls/GormNS...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:52:36 Modified files: dev-apps/Gorm/Palettes/2Controls/GormNSButtonInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/2Controls/GormNSButtonInspector.gorm/objects.gorm.diff?tr1=1.8&tr2=1.9&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/0Menus/GormMenuI...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:49:36 Modified files: dev-apps/Gorm/Palettes/0Menus/GormMenuItemAttributesInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/0Menus/GormMenuItemAttributesInspector.gorm/objects.gorm.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/1Windows/GormNSW...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:50:17 Modified files: dev-apps/Gorm/Palettes/1Windows/GormNSWindowSizeInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/1Windows/GormNSWindowSizeInspector.gorm/objects.gorm.diff?tr1=1.6&tr2=1.7&r1=text&r2=text
Re: GUI/back changes in CVS
On 7/11/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Adrian Robert wrote: > > > > On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: > > > >> I just added changes to GUI and back that will in the end allow pattern > >> images for GNUstep and the new MacOSX composite operator that uses an > >> addtional alpha value. I wanted these changes to go into the next > >> release as this will break binary compatibility between GUI and back. I > >> have tested this change with xlib. It would be great, if somebody could > >> test it before the release with art and winlib. > > > > Is there an easy way to test it? Is there something in the new test > > suite that exercises this facility? > > > > > Here is the simple application I tested with. But I am not even sure if > the different operators have been implemented correctly for xlib, but > thenm only one of the images I use has alpha values. Perhaps I should > test with to transparent images. This test is only for composition, but what about the pattern images ? The "filling patterns" you are talking about, is setting an image to a color and then fill something with this color, right ? I'm asking because when I profiled Camaelon, pattern filling was one of the thing that took lots of time, and i'm hoping that by having the possibility to use filling pattern directly it will be faster (as you shouldn't need context switching during the filling). And, does it properly follow the current path mask ? (actually I think that doesn't work on xlib, only with art, anyway...) Thanks, -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/dev-apps/Gorm/Palettes/0Menus/GormMenuA...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:49:14 Modified files: dev-apps/Gorm/Palettes/0Menus/GormMenuAttributesInspector.gorm: objects.gorm Log message: set firstInitialFirstResponder CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Palettes/0Menus/GormMenuAttributesInspector.gorm/objects.gorm.diff?tr1=1.8&tr2=1.9&r1=text&r2=text
[Gnustep-cvs] gnustep/dev-apps/Gorm/GormCore GormInspectorsMa...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fabien VALLON <[EMAIL PROTECTED]> 05/07/11 13:45:35 Modified files: dev-apps/Gorm/GormCore: GormInspectorsManager.m Log message: make setInitialFirstResponder working with inspector CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/GormCore/GormInspectorsManager.m.diff?tr1=1.8&tr2=1.9&r1=text&r2=text
Re: GUI/back changes in CVS
On 7/11/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Sorry, some things seem to have gotten mixed here. I wrote that "in the > end" this will "allow pattern images". They are not already there after > the first patch. Support for pattern colours requires two steps in the > backend: It needs to know, which image pattern to use, which is what I > implemented (the result of a pattern colour set command). And it needs > to draw this image, when a fill operation happens. I did not even work > on this second bit. Ah ok, my mistake. > Now art has an implementation of the very powerfull shfill PS command. > This allows, amongst other things, a pattern fill. So here the second > bit is already persent, while the first bit was missing. It should be > rather simple to implement full pattern colours drawing for the art > backend now. But this is nothing I am planning to do. The whole > structure of the art backend is very foreign to me. I don't dare to > touch anything here, because I may easily break things in an environment > that is so contrary to the way I normally program. > What I was planning to do was add a simple (and of course slow) pattern > drawing mechanism for the gsc classes and perhaps overwrite this with a > faster one for the xlib backend. > > Perhaps you could add the art pattern fill bit and I provide the rest? Well, I don't know about the art backend internals either -- It probably would be quicker if alex does it :-P -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: higher-fidelity nib2gmodel?
Gregory John Casamento, [EMAIL PROTECTED], wrote: >The gmodel import feature of Gorm is still experimental. Could you send >me the >.nib you had this trouble with? Also, would it be possible to get one of the >in which the table/outline view was skipped? Perhaps. It's a commercial app that I work on, so it's not my project to toss you pieces of. I probably can reproduce it, however. >> Is nib2gmodel the current best way to move .nibs over? Perhaps Gorm or >> another tool could deal with 10.2's text-archive .nib format? > >Work on this is ongoing. I (and others) am currently working on making >GNUstep capable of reading the keyed nibs. How far along is this? What needs to be done to make this work? I may be able to throw in cycles here. | Jonathan 'Wolf' Rentzsch http://rentzsch.com | Red Shed Software http://redshed.net | "better" necessarily means "different" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Looking like Windows on Windows
Richard Frith-Macdonald wrote: I'm looking forward to the next release of Camaeleon. that makes two of us ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: higher-fidelity nib2gmodel?
Jonathan, --- Jonathan 'Wolf' Rentzsch <[EMAIL PROTECTED]> wrote: > Gregory John Casamento, [EMAIL PROTECTED], wrote: > >The gmodel import feature of Gorm is still experimental. Could you send > >me the > >.nib you had this trouble with? Also, would it be possible to get one of > the > >in which the table/outline view was skipped? > > Perhaps. It's a commercial app that I work on, so it's not my project to > toss you pieces of. I probably can reproduce it, however. Please email me the .gmodel you create from this, if you can. > >> Is nib2gmodel the current best way to move .nibs over? Perhaps Gorm or > >> another tool could deal with 10.2's text-archive .nib format? > > > >Work on this is ongoing. I (and others) am currently working on making > >GNUstep capable of reading the keyed nibs. > > How far along is this? What needs to be done to make this work? I may be > able to throw in cycles here. There's still quite a bit of work to be done here. Many of the GNUstep classes now have the necessary logic to read the keyed nibs, but many still don't. Also it's necessary to determine, from looking at the xml output for an object of each class to reverse engineer the meaning of some of the flags. > | Jonathan 'Wolf' Rentzsch http://rentzsch.com > | Red Shed Software http://redshed.net > | "better" necessarily means "different" GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Nicolas Roard wrote: On 7/11/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: Perhaps you could add the art pattern fill bit and I provide the rest? Well, I don't know about the art backend internals either -- It probably would be quicker if alex does it :-P he seems to have vanished into thin air :( ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: higher-fidelity nib2gmodel?
Work on this is ongoing. I (and others) am currently working on making GNUstep capable of reading the keyed nibs. How far along is this? What needs to be done to make this work? I may be able to throw in cycles here. There's still quite a bit of work to be done here. Many of the GNUstep classes now have the necessary logic to read the keyed nibs, but many still don't. Also it's necessary to determine, from looking at the xml output for an object of each class to reverse engineer the meaning of some of the flags. For this latter task Fred Kiefer and I worked on a utility that automates some of this task. It's an Xcode project that you compile and run on an OS X machine. Either he or I could send it to you if you decide to work in this area.. -Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
