Re: Windows and libraries, again
$(GNUSTEP_INSTANCE)_OBJC_LIBS is what you want to use. Björn Giesler wrote: Hi, OK, found the problem. $(GNUSTEP_INSTANCE)_LDFLAGS ends up in the link command *before* any of the instance's object files, which causes the link command not to see the libraries specified there. Could somebody fix this? It's in target.make:885 Move $(ALL_LDFLAGS) after $(INTERNAL_LIBRARIES_DEPEND_UPON) and Instance/application.make:118 Move $(ALL_LDFLAGS) directly in front of $(ALL_GUI_LIBS) Sorry for not providing a patch, but stupidly I didn't copy the old state first... anyway, this is trivial. I'm referring to the base-1.11.1-gui-0.10.1 installer, of course. These changes cause everything to build and link fine. AddressManager starts up, but displays only the menu, and every attempt to make it show a window (info panel, preference panel) make it crash... can somebody tell me where to get gdb for GNUstep for MinGW for Windows? :-) Thanks in advance, Björn ___ 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
System & System Extension color lists
Unification of the System color list To support better theming and user configurability generally it is desirable for users to be able to specify the use of colors. Currently this is done through the System color list, which is created at initialisation through hardcode values or by loading a user created list. GSToolbar uses a "System extension" to add it's two color values. Is there any reason why we can't unite these additions into the System color list? Saving of the color list At the moment, in NSColor.m -> initSystemColors() If there is no previously saved System color list, it will automatically write one out. I'd like to change this. That is: if there is no previously saved list, we don't simply write a default one out but rather rely on the initialiser every time. Any objections? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: System & System Extension color lists
On Feb 6, 2006, at 11:25 PM, Sheldon Gill wrote: Hi, Saving of the color list At the moment, in NSColor.m -> initSystemColors() If there is no previously saved System color list, it will automatically write one out. I'd like to change this. That is: if there is no previously saved list, we don't simply write a default one out but rather rely on the initialiser every time. What rationale? (Playing devil's advocate, I can imagine the writing of the default one speeding future startups and being useful to give the user something to edit, although clearly things should move towards a Preferences.app style approach to customization.) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: System & System Extension color lists
Adrian Robert wrote: Saving of the color list At the moment, in NSColor.m -> initSystemColors() If there is no previously saved System color list, it will automatically write one out. I'd like to change this. That is: if there is no previously saved list, we don't simply write a default one out but rather rely on the initialiser every time. What rationale? (Playing devil's advocate, I can imagine the writing of the default one speeding future startups and being useful to give the user something to edit, although clearly things should move towards a Preferences.app style approach to customization.) 1) Users have complained about creating files, seemingly "unnecessarily". If they're relying on the default colors, why is it 'making a mess' (minor) 2) It writes to the user specific color lists. It is then impossible to tell if it is a list the user decided to use or one the system simply wrote by its own accord. 3) Many environments have system colors defined elsewhere. Think KDE, GNOME and Win32. WindowMaker also has some. Its desirable for GNUstep to 'play nice' on those systems and rely on externally supplied lists. 4) Those other environments support changing colors and all applications responding. With current GNUstep, it becomes difficult to support this nicely. Essentially we either clobber user settings or not. Considering your "pro" items: a) Giving the user something to edit shouldn't be a "System.clr" text file but an application or tool which will help them do it. Most users aren't happy playing with separate numbers for RGB values in text format, IMHO. b) Giving the user something to edit as a "System.clr" file is easy. Give them an URL c) If it's a good idea in a particular configuration to speed things up then it is really a packaging issue. In this case, provide a default System.clr installed in SYSTEM_ROOT\Library\Colors (Happily engaging in debate...) Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
