gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: System & System Extension color lists


From: Sheldon Gill
Subject: Re: System & System Extension color lists
Date: Tue, 07 Feb 2006 13:38:04 +0800
User-agent: Thunderbird 1.5 (Windows/20051201)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]