Issue 61174 - modify User Interface colors on Mac OS X
Summary: modify User Interface colors on Mac OS X
Alias: None
Product: porting
Classification: Code
Component: MacOSX (show other issues)
Version: 680m152
Hardware: PowerPC (PPC) Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 2.0.3
Assignee: eric.bachard
QA Contact: issues@porting
: 61172 61173 (view as issue list)
Depends on:
Blocks: 67331
  Show dependency tree
Reported: 2006-01-26 07:52 UTC by eric.bachard
Modified: 2006-07-19 18:11 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

patch for change User Interface colors on Mac OS X (1.50 KB, patch)
2006-01-26 08:19 UTC, eric.bachard
no flags Details | Diff
as reminder, the list of COL_BLUE I found (7.85 KB, text/plain)
2006-01-26 22:05 UTC, eric.bachard
no flags Details
the same for COL_LIGHTGRAY (22.79 KB, text/plain)
2006-01-26 22:07 UTC, eric.bachard
no flags Details
First try at implementing GetStyleSettings for Mac OS X (10.68 KB, patch)
2006-01-27 23:59 UTC, moxfox
no flags Details | Diff
A settings resources file for color settings (601 bytes, text/plain)
2006-01-28 00:01 UTC, moxfox
no flags Details
A new version that may compile (11.42 KB, patch)
2006-01-28 00:49 UTC, moxfox
no flags Details | Diff
updated colors (600 bytes, text/plain)
2006-01-28 02:07 UTC, moxfox
no flags Details
patch adapted to m154 source code (10.46 KB, patch)
2006-01-29 20:14 UTC, eric.bachard
no flags Details | Diff
Color settings for v4 (1.13 KB, text/plain)
2006-01-29 22:28 UTC, moxfox
no flags Details
Color settings patch v4 (13.51 KB, patch)
2006-01-29 22:29 UTC, moxfox
no flags Details | Diff
status of aquacolors (scp2 not tested) (4.70 KB, patch)
2006-01-31 00:38 UTC, eric.bachard
no flags Details | Diff
aquacolors v8 patches (5.84 KB, application/x-gzip)
2006-01-31 21:31 UTC, moxfox
no flags Details
Updated patch set. Does not affect kde-files. Ready for integration to the cws aquacolors (4.85 KB, application/x-gzip)
2006-02-07 18:12 UTC, moxfox
no flags Details
v10 of the patch (4.43 KB, patch)
2006-02-22 13:08 UTC, moxfox
no flags Details | Diff
updates to the UI font settings (see my comment in i57252, on Feb 23) (5.54 KB, application/x-compressed)
2006-02-23 16:38 UTC, moxfox
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description eric.bachard 2006-01-26 07:56:34 UTC
One step forward to match Aqua interface is first use Aqua colors

Apple colors are : 

grey light : 0xF4 0xF4 0xF4
blue   : 0x34 0x70 0xCC (52,112,204 in decimal) 

I propose to change the colors of Mac OS X User Interface using these colors

Patch arrives
Comment 1 eric.bachard 2006-01-26 08:19:12 UTC
Created attachment 33569 [details]
patch for change User Interface colors on Mac OS X
Comment 2 eric.bachard 2006-01-26 08:54:10 UTC
fixed in aquacolors 
Comment 3 ace_dent 2006-01-26 19:34:43 UTC
*** Issue 61173 has been marked as a duplicate of this issue. ***
Comment 4 pavel 2006-01-26 19:55:29 UTC
*** Issue 61172 has been marked as a duplicate of this issue. ***
Comment 5 pavel 2006-01-26 20:14:39 UTC
ericb: sorry but I do not like to change the colors this way.

Where are UI colors used? Can't we simply use the new colors triplet there
instead of COL_BLUE and COL_LIGHTGRAY and not change the real COL_*?

Right now *all* places where these colors are used are affected. This is wrong
approach. You should change *only* the place(s) for UI colors.
Comment 6 eric.bachard 2006-01-26 20:39:08 UTC

In fact, I already was searching in that direction : in my post on mac@porting I
was talking about " #include <color.hxx> "used 445 times, but just some times

I'm investigating exactly were..

And I agree, directly use the triplet just when needed is the better choice, and
I'll change that way.  I wanted to say I still have not found a bad case.

The bad side is around 25 modules (maxi) are concerned, and this changes a lot
of things..

Comment 7 eric.bachard 2006-01-26 21:03:53 UTC

Other idea : 

Maybe define new colors like COL_BLUE_AQUA and COL_LIGHTGRAY_AQUA is more clean,
to avoir #ifdef MACOSX ... #endif

BTW : I found a lot of COL_LIGHTGRAY and COL_BLUE 
Comment 8 eric.bachard 2006-01-26 22:05:44 UTC
Created attachment 33590 [details]
as reminder, the list of COL_BLUE I found
Comment 9 eric.bachard 2006-01-26 22:07:46 UTC
Created attachment 33591 [details]
the same for COL_LIGHTGRAY
Comment 10 moxfox 2006-01-27 07:53:51 UTC
Ah well, so I guess this won't be a quick fix after all.

I agree that it does not make sense to redefine color BLUE to something else 
for the whole application (that would make the text documents and 
presentations use different colors on Mac OS X). Only UI should be affected.

Interesting files from the gray-list:

Would one of these solutions be good? :
a)  in color.hxx, define new COL_UI_BLUE, COL_UI_LIGHTGRAY and map them to the 
existing colors by default (and to aqua colors on OSX). Then change all the 
places that affect the UI: from COL_BLUE to COL_UI_BLUE.

b) How gtk themes do this? Is there a function or a setting somewhere that 
would allow us to just specify a configure setting or to set the correct 
colors in runtime?
Comment 11 stephan_schaefer 2006-01-27 10:34:46 UTC
Sorry, but I must say that the current patch is the wrong approach and must not
be integrated! VCL provides functionality to adapt the system colors and you
have to set the correct colors into the corresponding settings and not redefine
what blue or gray should be.

The function void DtIntegrator::GetSystemLook( AllSettings& rSettings ) in
vcl/unx/source/gdi/dtint.cxx can be used to fill in the right colors. There are
multiple Integrators available but on plain X11 the base class (DtIntegrator) is
used, so you can put an #ifdef MAC block here and provide your colors in the
StyleSettings object. Have a look at the other GetSystemLook() implementations
to get an idea. You should start with setting the face color which is used quite
often, so you can easily see your changes and then continue from there.

Again, please forget the idea about redefining color values ! A patch like this
will never be integrated.
Comment 12 pavel 2006-01-27 11:51:15 UTC
adding me to CC:.
Comment 13 eric.bachard 2006-01-27 23:57:47 UTC

Please correct me if I'm wrong :

DtIntegrator::GetSystemLook uses StyleSettings::StyleSettings() ( found in setting.cxx)  
In setting.cxx, StyleSettings::StyleSettings() allocate memory for a pointer on ImplStyleData(), 
and  ImplStyleData() does contain a lot of definitions, included colors.

What Ì do not understand : can we modify directly the content of ImpleStyleData(), or do we create a 
new similar object (where ? ). For example replacing directly could give :

maFaceColor  = Color (COL_LIGHTGRAY);
+ all color changes to test 
with : 

replaced by :

#ifdef MACOSX
  maFaceColor  = Color (RGB_COLORDATA(0xF4, 0xF4, 0xF4));
  + all color changes to test on Mac OS X
(same for COL_BLUE)
  maFaceColor  = Color (COL_LIGHTGRAY);
  + all collor changes for !MACOSX
(same for COL_BLUE)

Or something completely different must be done ?

Thank's in advance for  any help/sugggestion

Comment 14 moxfox 2006-01-27 23:59:10 UTC
Created attachment 33627 [details]
First try at implementing GetStyleSettings for Mac OS X
Comment 15 moxfox 2006-01-28 00:01:39 UTC
Created attachment 33628 [details]
A settings resources file for color settings
Comment 16 moxfox 2006-01-28 00:11:57 UTC
Using kde files from OOo 2.0.1 as a template, I have made a first try at
implementing the color settings for Mac OS X.

Since the KDE version uses a file with the settings, I have used this approach
in the Mac OS X version as well. This enables the user to manually change the
colors to her liking.

The patch will not work out of the box and probably will not compile either.
Anyone willing to help to make the necessary modifications to makefiles and
delivery stuff? 

All the necessary .hxx and .cxx have been created. When it compiles and
delivers, it will be probably necessary to define environment variable
"OOO_FORCE_DESKTOP=macosx" to get it working as automatic detection will not
probably work.

The settings file should be put to "~/Library/Application Support/OpenOffice.org2/"
Comment 17 moxfox 2006-01-28 00:49:15 UTC
Created attachment 33629 [details]
A new version that may compile
Comment 18 moxfox 2006-01-28 00:51:43 UTC
The v2 of the patch may compile. But does it deliver? It's all so confusing...

Sidenote: the IZ 59303 does the _opposite_ for kde (cws vcl50)
Comment 19 moxfox 2006-01-28 02:07:50 UTC
Created attachment 33630 [details]
updated colors
Comment 20 moxfox 2006-01-28 02:11:25 UTC
I have successfully compiled a local build (OOo 2.0.1) with these changes and
the themed colors appear :) (requires the OOO_FORCE_DESKTOP=macosx -variable)

The colors are themed in almost all the other places, but the main menu is not
themed. (bug somewhere)

If you change the colors in the rc file, you have to restart OOo to see the changes.
Comment 21 eric.bachard 2006-01-28 07:53:45 UTC

One more time you did a great work ! I really learned a lot of things.  Unfortunaly, I'm working all the day, 
so I won't be able to test before this evening (sure I'll do)

Waiting, Stephan will give his opinion/suggestions, and if things are ok, I'll commit your changes (if none 

Comment 22 eric.bachard 2006-01-29 20:10:56 UTC

Your patch does not apply on m154, because some kde stuff has been removed.

I have written a patch that you can apply with m154.  vcl builds fine with it on m153, but I don't know if 
I'm wrong or not.

The problem I have is :

when instantiate MACOSXIntegrator()  ?  In your code, it was made twice, and I have not understood 
why. From my side, instead of use (KDEIntegrator is missing in m154) :

 @@ -118,6 +121,8 @@
         if( aOver.equalsIgnoreAsciiCase( "kde" ) )
             return new KDEIntegrator();
+        if( aOver.equalsIgnoreAsciiCase( "macosx" ))
 # nclude <sareturn new MACOSXIntegrator();
         if( aOver.equalsIgnoreAsciiCase( "none" ) )
   )         return new DtIntegrator();
@@ -138,6 +143,9 @@
+    if( pSalDisplay->getWMAdaptor()->getWindowManagerName().EqualsAscii( "Syste" ) )
+               return new MACOSXIntegrator();
        // default: generic implementation
        return new DtIntegrator();

I just create MACOSXIntegrator if WindowManagerName().EqualsAscii is  :

@@ -142,8 +145,12 @@
+    if( pSalDisplay->getWMAdaptor()->getWindowManagerName().EqualsAscii( "" ) )
+               return new MACOSXIntegrator();
+    else

I have not tested. Of course, if I'm wrong, please let me know

Comment 23 eric.bachard 2006-01-29 20:14:33 UTC
Created attachment 33665 [details]
patch adapted to m154 source code
Comment 24 moxfox 2006-01-29 20:18:24 UTC
ericb: the first instantiation is used when you force the integrator with
OOO_FORCE_DESKTOP=macosx environment variable. (this works)

The second instantiation is when autodetection is working. (but this does not
work currently). I don't know the proper name for WindowManagerName() on Mac OS
X. The current thing is just a placeholder.

Comment 25 eric.bachard 2006-01-29 20:51:23 UTC

Ok, thank's for your quick answer :-)  Anyway, m154 is building, and I'll test/modify what needs to be 
tomorrow, or this night if the build ends not too late.

IMHO, with two instanciations, one is too much, and it should work with only one.

BTW Kendy may certainly help us too, and I'll ask him some tips tomorrow.

Comment 26 moxfox 2006-01-29 22:28:26 UTC
Created attachment 33668 [details]
Color settings for v4
Comment 27 moxfox 2006-01-29 22:29:24 UTC
Created attachment 33669 [details]
Color settings patch v4
Comment 28 moxfox 2006-01-29 22:37:45 UTC
I'm still building OOo 2.0.1, but I applied the kde-removal patch to it, so the
v4 of the patch should apply pretty well to m154 as well.

The latest patch sets more colors and thus also the menubar uses now correct colors.

Could someone please provide a correct line to this:
fprintf( stderr, "getWindowManagerName(): \"%s\" \n",

Currently that crashes, because I don't know how to handle the string

Stumbled upon a similar enhancement in NeoOffice at
They use a more brute force method, but more interesting is, should we use the
same colors as them? Does that need permission from Patrick?
Comment 29 philipp.lohmann 2006-01-30 09:56:03 UTC
mox: the correct line would be

fprintf( stderr, "getWindowManagerName(): \"%s\" \n",
rtl::OUStringToOString( pSalDisplay->getWMAdaptor()->getWindowManagerName(),
osl_getThreadTextEncoding() ).getStr() );

also please surround the creation of MACOSXIntegrator with #ifdef MACOSX like
you did with the #include directive, else the code will not compile on not
MacOSX. Also you might want to make the compilation of macosxint.cxx conditional
for MacOSX (like the compilation for CDEIntegrator is conditional for Solaris,
please have a look at

Aside from these minor technicalities the patch looks good to me, if you want to
go with an RC file. Are there possibly methods to ask the Mac API for these
colors instead of using a file ?
Comment 30 eric.bachard 2006-01-30 11:04:19 UTC

IMHO, a config file is an intermediate, but sufficient solution : we'd prefer concentrate on native 
changes, and stop with X11 development. Mox and me are working on it because change the look was 
a big request : 1 Mac user over 2 complains about the awfull "grey and blue" used in the interface. 

This is of course a little change regarding the size of the existing source code, but very important, 
believe me.

In fact (please, Mox, correct me if I'm wrong), we don't know how and/or if it's possible to use existing 
code to change colors on the fly, so any suggestion is welcome : it's 10 times more hard to discover 
everything than have some tips to start, like : prefer use that, this method  does exist, this object will 
help you, an example is there, have a look at ... 

Last but not least, what I have learned around this change was very interesting, and I'm the first ready 
to learn more.

...and thank you very much for your time :-)


About the color, the aqua one looks good for me. I'm not sure neither we will have to ask Patrick if we 
want to use the same, but sure, it's more fair/correct to do this way. 

About your patch : I have used your changes, but I cannot apply them directly to m154. So, after some 
modifications it works. Last, you'll have to modify the place where macosxrc is located. 

Correct path is : ~/Library/Application Support/ 2.0

Other changes we have to do are : protect the build for other archs and commit the changes.
For that, discussing with obr 5 minutes ago on IRC, remaining modifications could be :

desktop  : 
- put macosxrc file in desktop/macosx/misc
- deliver it in solver

scp2 :

- add macosxrc file 
- maybe modify profileitem 

And if it still does not work, that's because I forgot something :-)
Comment 31 philipp.lohmann 2006-01-30 12:43:02 UTC
ericb: Changing colors on the fly in OOo or the desktop ? To make OOo read the
system settings again, simply call SendInternalEvent( pThis, NULL,
SALEVENT_SETTINGSCHANGED ) on your SalDisplay - pThis is a pointer to a live
SalFrame. this will cause SalFrame::UpdateSettings (and hence
DtIntegrator::GetSystemLook) to be called again.
Comment 32 eric.bachard 2006-01-31 00:37:16 UTC

Thank you very much for the information. Very interesting, and I'll take note. To be more precise, I 
mean change the content of the macosxrc file from OOo, e.g. using a dialog box. IMHO, this is not 
necessary to implement such feature. Just one simple config file with Aqua colors,and  the objective is 
reached : stop to use the default grey/blue :-)


I'll attach all the changes I have in mind (excepted scp2 not tested, the rest works) :

- in desktop  :  create macosx/source/misc directory, with macosxrc and corresponding makefile (to 
make macosxrc delivered) + prj/build.lst and prj/d.lst modified + modified wit 
OOO_FORCE_DESKTOP environment checked, only if uname returns Darwin ( means Mac OS X is 

- in vcl (aqua-colors-v7.patch) : my changes, in sync with m154, including #ifdef MACOSX , to protect 
other archs/OS for the build

- scp2 : add macosxrc in packaging, with good directory (I'm not sure, and I have not verified)

What is not clear, is in macosxint.cxx :  obr (Oliver Braun) told me about use Bootstrap::get ( in rtl/
bootstrap.hxx), using something like :

OUString Bootstrap::get( OUString(RTL_CONSTASCII_USTRINGPARAM("BaseInstallation")); 
BaseInstallation, OUString);

But I have not found (using bootstrap.hxx as example) how to use it correctly in macosxint.cxx.

The idea is to search first in ~/Library/Application Support/ 2.0 if macosxrc does exist, 
and if not, search -using Bootstrap::get()-  in <INSTALL_DIR>/share/config, 
whith <INSTALL_DIR> ==  /Applications/, by default, 
but not always...

This way, we could have a default configuration, and for the users interested with experiences, they will 
just have to create macosxrc in ~/Library/Application Support/ 2.0

Our problem is to check default macosxrc wherever 2.0 is installed ...
Of course, all attached files are draft, and I wait for opinion before to commit something.

Last but not least, I'll be away all the week, so I'll probably slow down the work for some times.

Comment 33 eric.bachard 2006-01-31 00:38:14 UTC
Created attachment 33725 [details]
status of aquacolors (scp2 not tested)
Comment 34 moxfox 2006-01-31 19:51:38 UTC
Thanks for the correct fprintf! It worked fine, although it turns out that on
MacOSX it returns just an empty string.

Yes, there are native functions to query the colors. However, this is not really
worth the effort, because:
a) X11 is not native looking, so there's no point in making lot of effort on
that side
b) Mac OS X actually uses pictures and patterns in some places in the UI, where
OOo only defines a single color. Thus the single colors that we define in
rc-file are an approximation, not a direct match to a system color.


Thanks for the scp2 and desktop work! It would have taken me years to understand
that stuff :)

I think it is more userfriendly to have the macosxrc only in user settings
directory. This way, all the user has to do, is to browse to that directory and
click on the file to edit. Actually, perhaps the filename should be
macosxrc.txt, so that it would open in TextEdit by default.

If we use a separate macosxrc in system settings directory, then user would have
to browse inside the .app, copy that file to correct place (user settings dir)
and then edit it. This would be much more difficult to do correctly.


Since the pSalDisplay->getWMAdaptor()->getWindowManagerName() returns an empty
string on Mac OS X, I think we should just brute force the "return new
MACOSXIntegrator();" on Mac OS X (i.e. no need for OOO_FORCE_DESKTOP). It can be
loaded always. 

I am not sure, but it seems that those who use GTK or KDE vclplugins in Mac OS
X, the vclplugin will override the settings in MACOSXIntegrator. So even when
vclplugins are used, it would be OK to brute force the "return new
Comment 35 moxfox 2006-01-31 21:29:33 UTC
Oh BTW, 
the m154 still includes the files "vcl/unx/source/gdi/kdeint.cxx" and
"vcl/unx/inc/kdeint.hxx", even though all the other KDEIntegrator stuff was
removed... It is not built in the anymore. Maybe we can do a little
cleanup at the same time :)


The following v8 of the code uses the ideas that I presented before, and also
finishes the KDE cleanup.

That code is against m154 and should be ready to integrate to aquacolors cws and
for testing. Is there anything that should be done differently?
Comment 36 moxfox 2006-01-31 21:31:45 UTC
Created attachment 33753 [details]
aquacolors v8 patches
Comment 37 philipp.lohmann 2006-02-01 08:23:02 UTC
FYI: kdeint.[hc]xx removal is already done in CWS vcl54 (issue 61234) :-)
Comment 38 moxfox 2006-02-07 18:12:34 UTC
Created attachment 33927 [details]
Updated patch set. Does not affect kde-files. Ready for integration to the cws aquacolors
Comment 39 moxfox 2006-02-07 18:15:17 UTC
The v9 of the patch should applies against m154 and probably later ones as well.
It uses macosxrc.txt as a configuration file.

This should be now tested and integrated to cws.
Comment 40 eric.bachard 2006-02-12 20:21:16 UTC
I have solved the scp2 problem, and I'll be able to commit tomorrow morning.
Today it was not possible to commit (see #i61941# ).

Before, last thing to do is to resync with m156 .

macosxrc (or macosxrc.txt if you prefer) will go -as expected- inside
~/Library/Application Support/ 2.0/user directory.  (macosxint.cxx
has been modified to match this new dir )

Concerned modules for aquacolors are  :  vcl, desktop and scp2 if you want to
give it a try.

Important : we discussed a lot on IRC with Oliver Braun about the best places
for put everything. That's the reason why we decided to not do something too
complicated (use .xcu ) just for this little change.

Note : Oliver is my QA team for aquacolors cws.

Comment 41 moxfox 2006-02-12 20:38:19 UTC

Ok, the user -folder is good.

Yes, I want the file to be "macosxrc.txt"

I do not quite understand what is the problem with scp2, but it doesn't matter,
I'll check the cws, once you've committed...

Please note that my v9 patch above does not use OOO_FORCE_DESKTOP and that
environment variable should not be used for cws aquacolors.
Comment 42 pavel 2006-02-13 12:06:24 UTC
re-target to 2.0.3.

Comment 43 eric.bachard 2006-02-14 22:26:43 UTC
CC for Oliver (my QA)


We have tried using macosxrc : a double click on it and TextEdit can open it.
If it really is a problem, I'll change for macosxrc.txt.

Fixed in aquacolors, but waiting for Oliver opinion before to declare this cws
ready for QA
Comment 44 moxfox 2006-02-15 14:40:53 UTC
Yes, macosxrc can be opened with TextEdit, but manually. 

The idea is that macosxrc.txt is _by default_ opened with TextEdit, i.e.
automatically. This is a more userfriendly approach. 
Comment 45 moxfox 2006-02-22 13:08:43 UTC
Created attachment 34380 [details]
v10 of the patch
Comment 46 moxfox 2006-02-22 13:13:13 UTC
The v10 of the patch fixes the compilation of scp2 -module.

@all: Although I signed the JCA already in January, it still has not appeared to :( Do you know who I
should ask if my JCA is still in some queue somewhere?
Comment 47 moxfox 2006-02-23 16:38:21 UTC
Created attachment 34411 [details]
updates to the UI font settings (see my comment in i57252, on Feb 23)
Comment 48 eric.bachard 2006-03-03 20:59:51 UTC

Please check the last changes in aquacolors.

-> Following your recommandations, I have :

- renamed macosxrc into  macosxrc.txt
- modified default font for Lucida Grande (great choice!)
In runtime :  
when macosxrc.txt is not present in ~/Library/Application Support/ 2.0/user folder, a 
default macosxrc.txt , present in <install_dir>/preset is used. bootstrap key mechanism has been used 
(thank's to JoergB  for his time)

Build (m156) currently in progress (vcl is successfull, binfilter 125th part over 148 is building) 

If everything goes fine for me, I'll set aquacolors as ready for QA

Comment 49 eric.bachard 2006-03-03 21:08:28 UTC

I forgot to mention : aquacolors is only resynced with m156.

Comment 50 moxfox 2006-03-03 21:16:00 UTC
Your changes look good (checked from bonsai):

Comment 51 eric.bachard 2006-03-04 08:20:44 UTC
Fixed in aquacolors

ericb->pjanik : may you please verify the changes does not break Linux nor Windows builds ? thank's in 

Suggested QA process :

Point 1 :build should be ok for all archs/OS's : no interaction

Point 2 :Install process : 

1 .dmg installation 

Expected results : 
- an existing macosxrc.txt is really in <install_dir>/presets 

To verify : just right click -> show/display the contents, and see inside presets  to verify

Else : test fails

2) user install : Proceed a first Start of as simple user

Expected results : 
- a macosxrc.txt file must exist in ~/Library/Application Support/ 2.0/user
- UI colors must be Aqua (pretty blue and very light grey)
- UI font must be Lucida Grande (Apple recommandation)

Else : test fails

Point 3 : User's config file must have priority

Context : user install is already done, without any modification

Modify the font in <install_dir>/presets : e.g. add a  "#" , means comment the line in 
<install_dir>/presets/macosxrc.txt and restart for the user :

Note : you probably need to authentify and change rights ( setting +w the file, default is -w )

Expected result :  No change for  the UI font : Lucida Grande font must continue be used
Else => test fails

Point 4 : Default file must replace missing user's file

1) As simple User rename macosxrc.txt in macosxrc.txt.old in 
 ~/Library/Application Support/ 2.0/user and restart 

Expected result : must restart with a simple font, but not Lucida Grande

Else => test fails

2) As simple user, rename macosxrc.txt the file previously renamed, and restart

Expected result :  Lucida Grande must be used for UI

Else => test fails.

IMHO, if this already works ;-)
Comment 52 pavel 2006-03-05 17:50:32 UTC
Verified in my local builds.

Works exactly as described by Eric.
Comment 53 pavel 2006-03-05 18:18:50 UTC
Can we rename desktop/macosx/source/misc/macosxrc to macosxrc.txt so it is named
as the final final?
Comment 54 pavel 2006-03-05 18:24:40 UTC
This line is also not documented in the macosxrc.txt file:


Also please adjust the comment:

// if macosxrc is not found in user install dir, fallback to default file,
located in <install_dir>/presets

It should say macosxrc.txt.
Comment 55 eric.bachard 2006-03-05 20:36:55 UTC

- macosxrc.txt is now used everywhere
- cursorFlashTime option has been removed : more safe. this options is just there to modify cursor 
blinking => This changge is completely out of the scope of this cws

- change in macosxint.cxx comment done.

Fixed in aquacolors
Comment 56 pavel 2006-03-06 19:06:04 UTC
Verified in aquacolors.
Comment 57 eric.bachard 2006-07-19 18:11:25 UTC