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
Re: System & System Extension color lists
On 7 Feb 2006, at 04:25, Sheldon Gill wrote: 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? I'm certain this has come up before ... but I can't find the thread on the web or in my personal email (but a big chunk of my email got lost when my machine died in november). Anyway ... I think the 'Systyem extension' list is wrong ... if we have to add new colors we should add them to the system list so they are all in one place. BUT ... I recall querying whether GSToolbar should be adding two new colors at all ... on the theory that things should be kept simple and existing system colors should be used where possible. What I can't remember is who brought the subject up and what their answer to that query was (or even if they had an answer). So ... 1. if there is no good reason for having toolbar specific colors ... we should scrap them and use system colors 2. if there *is* a good reason for having new colors, we should add them to the system color list I would be inclined to (1) as the simplest solution on the basis of what I know/remember at the moment. 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. Sounds good to me. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
