Changing the exterior color of the main window

[Guest]

Pat said:

"I understand your logic about not upgrading, but I think you are assuming that Neo/J is a corporate product that is well tested before release. Instead, Neo/J is done entirely by volunteers which means that no code is really tested until it is released. In essence, the code is tested by people like you."

Nope, not at all. I realize it's just Ed and you and a handful of others that are involved on and off which is exactly what makes it interesting to follow. Classical David and Goliath stuff.

I've got 2 archives and installs on my iMac that I'm too paranoid to get rid of until I get my Mac back to the way I had it was before my fooling around messed things up, cause I just can't stop tinkering, it's an addiction, I guess.

So until I get my new iBook preloaded with Tiger, (Tiger ~ 4/15/05 so iBook-->Tiger May/June?) It's simply not worth it to me to upgrade NeoJ or Mac OS X since I tell every one to send me .rtf files at home and deal with .docs as I need to.

I'll be glad to upgrade then and maybe even download the behemouth and play with NeoC source on the iMac at that point.

Hope I didn't offend with the speed comments and I continue to wish all involved great progress. I and many others want you to be successful!!! Maybe not so much billyboy ; )

I came in here simply looking for a quick fix for the Windoze drab grey, and one could say Apple Platinum, window coloring and learned there is no such animal. Carry on and again, good luck!!!!!!!!!!!!!!!

[Guest]

Not to beat a dead horse or anything but in my daily reading/quest to tinker I came across this link and thought Pat and the gang might apppreciate it as it relates to how this thread has gone

http://www.openoffice.org/issues/show_bug.cgi?id=40800

[sardisson]

[Guest]

Thanks for that Smokey. It's good to see that others are noticing the GUI efforts involved.

Hmmm... Wash., DC, OK, just my paranoia acting up.

I realize now you are also a heavy hitter in all this work. Thanks.

Indeed this 'gray' seems to be deep in the bowels of OO.o itself in all its german language glory as I've scoured and tinkered all week to find no success. One thing I have noticed is how Sun spells things 'grey' in the code while the other grey ascII coding is spelled (spelt?) 'gray.

[ovvldc]

[JKT]

[jakeOSX]

you know i actually use both spellings of the word. wonder if that means anything.

[Guest]

Well, I was gonna let that beaten horse die, but since this is back on top, I have a few questions after poking around in soffice.bin over the weekend:

What is the sigifcance of and is it wasting time playing with the following code:

- Q53com3sun4star* (where * varies in value from say 3 thru 15, etc.)

- 6Window.

- 12SystemWindow* (where * varies from something like Ui. to other things)

On the Beige work box right now so this is from memory.

In other words, just where is that damn german grey window and toolbar color hex code in OOo?!!!!!

[fa]

What you actually want to look at are the following source files:

http://gsl.openoffice.org/source/browse/gsl/vcl/source/app/settings.cxx?rev=1.38.122.1&content-type=text/vnd.viewcvs-markup
http://util.openoffice.org/source/browse/util/tools/inc/color.hxx?rev=1.3&content-type=text/vnd.viewcvs-markup

You're looking for ImplStyleData::SetStandardStyles(), ignore the Unix/Mac styles as those are extremely old code that is no longer used in the 1.1.x series (and is removed in 2.0).

Specifically, what you probably want is to change this:

maDialogColor = Color( COL_LIGHTGRAY );

to something that doesn't suck. COL_LIGHTGRAY is actually just a 32-bit integer number composed of the RGB color value that you'd like, with the bits 24-31 unused, 16-23 = r, 8-15 = g, 0-7 = b.

You'd probably be able to find that in libvcl645mxp.dylib by using a search for 0x000c0c0c. Youd probably best find the address of ImpleStyleData::SetStandardStyles() first though, and search for the first 0x000c0c0c after the start of that function in the dylib.

A patch that Red Hat has used in the past (before Native Widget Framework made it obsolete):

http://people.redhat.com/jrb/files/openoffice-1.0.2-colorchange.patch

[Guest]

"... longer used in the 1.1.x series (and is removed in 2.0). "

Now see, that's why I know just enough to really know nothing at all.

If I'm poking around in NeoJ ver. 0.7 soffice.bin though, does your lead still apply re: 1.1.x series OOo?

I don't remember seeing anything that you mention but then again I didn't really know what I was looking for in the first place.

I'll still follow your suggested leads and play if possible.

Thanks!

I'm quite content with NOJ 0.7 for my needs. I'll just pretend I'm using Platinum again. : P

[fa]

My bad, make that 0x00c0c0c0, or on Intel 0xc0c0c000.

The problem you'll run into here is that the addresses that you get from "otool" are _offsets_ based on the load address of the library, and are quite useless for a hex editor. You have to find out the default load address for the library, then subtract from the address of the function that you got using "otool" that load address, then you can go there with a hex editor and search for the 3rd occurance of C0C0C0 and change it and be reasonably sure it will work.

Since I don't have Neo installed on a Mac I can get to right now, lets do this with QuickTime. Say I'm looking for the "QTMLGrabMutex" function so I can hex-edit something.

otool -Vvt /System/Library/Frameworks/QuickTime.framework/Versions/Current/QuickTime | less

I then hit "/QTMLGrabMutex" and return, to find that string in less. I get the following:

_QTMLGrabMutex:
91bb1858 mfspr r4,lr

So, the start of QTMLGrabMutex is at VM offset 0x91bb1858. I need to find the load address of the QuickTime dylib first, so I do this using:

otool -l /System/Library/Frameworks/QuickTime.framework/Versions/Current/QuickTime | less

This gives me a printout of the sections in the library, but only the section that has a "fileoff 0" is of interest since that gives me the load address of the library:

Load command 0
cmd LC_SEGMENT
cmdsize 940
segname __TEXT
vmaddr 0x91bb0000
vmsize 0x00196000
fileoff 0
filesize 1662976
maxprot 0x00000007
initprot 0x00000005
nsects 13
flags 0x0

Therefore, this library is loaded into memory starting at address "0x91bb0000" as seem from the "vmaddr 0x91bb0000". I next take a calculator and do the following:

function address - load address = offset within file
0x91bb1858 - 0x91bb0000 = 0x1858

Then, in the hex editor, I would jump to file offset 0x1858 and be reasonably sure that I was inside the QTMLGrabMutex() function. I dont' just want to search for "C0C0C0" because that could be valid code and if changed, would crash Neo.

Now, I'm actually just winging it here, so if anyone _knows_ that this is wrong, please correct me. If not, the procedure here should work for you to find the exact C0C0C0 string you want to change to affect the window color in NeoOffice.

dan

[Guest]

" libvcl645mxp.dylib"

Ha! I do remember seeing that one!

[fa]

I'll take a stab at it tonight and post the actual offset of the bits you need to change inside libvcl645mxp.dylib in this thread.

The other alternative is to convince Patrick to apply a patch with certain less-sucky colors

Note that I _did_ look at Tools->Options->Appearance->Application background, but I don't think that changes what we want it to change. Correct me if I'm wrong.

[Guest]

Although I'm an engineer, that last post just plain scared me dan. Let me ponder that discussion before attempting to tackle that.

[ovvldc]