No problem Pat, fa can take all the time he needs/wants. Us (this only) 0.7 user(s) can only enjoy running with all toolbars off anyway to eliminate our drab gray blues. : (
The bolder hackers will go do their thing in the interim.
I get the impression I annoy you but that's not my intent. I'm simply just tryin' to lighten up my days at my full time job on a beige box (except when I'm in OS X on PearPC) hehe.
These look wonderful, but I need a patch to integrate. Hex editing the binaries is not a patch. Instead, I need a real code patch for the vcl source code.
For those enterprising patching-hackers among us, I posted this earlier in the thread:
sardisson wrote:
Edit: oh, I missed the part where Dan explained it's still a bit of hackery, not a proper source-change....
Of course, if COL_LIGHTGRAY is not the color used in the Mac L&F, then someone needs to discover which color is referenced in it and LXR the places that color is referenced in the source and patch that instead/as well. There are distinct advantages to keeping the Mac L&F until we get to true NWF implementations in "1.5".
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Last edited by sardisson on Wed Apr 06, 2005 8:22 pm; edited 1 time in total
Joined: Feb 12, 2005 Posts: 607 Location: Australia
Posted: Wed Apr 06, 2005 7:33 pm Post subject:
Colour variations wrote:
I reckon E6 E6 EF is a nice subtle compromise, sort of a subdued blue grey. But I do agree that it would be better if this worked with Mac L&f.
Changed my mind. I now think E8 E8 E8 is a very close match to the surrounding borders. I lack the nous [tr: understanding, insight] to get a closer match. Although I've been experimenting in Gimp
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Thu Apr 07, 2005 5:05 am Post subject:
Edit: If you read the first version, I had misnamed the target file as libvcl645.mxp - it is now corrected to libvcl645mxp.dylib
Edit 2: Read Patrick's post below... if you choose to do the following, please, please revert back to the original file from your backup once you have seen what the interface changes are like, otherwise you will not be helping bug test NeoOffice in the future
OK, for the benefit of those who want to play:
Stock warning - do this at your own risk, blah, blah. If things go wrong its your own fault, etc, but if they do, simply reinstalling NOJ should cure them.
1. Quit NeoOffice/J and then "Show Package Contents" of the NeoOfficeJ.app - control click the NOJ icon in the /Applications folder and select the option from the contextual menu. A "NeoOfficeJ" window will open in the Finder with a "Contents" folder in the display.
2. Navigate to the Contents>MacOS folder and locate the file called "libvcl645mxp.dylib". Very, very importantly... drag it to e.g. your desktop to make a backup of the original file just in case something goes amiss. If things don't work out, you can drag and drop this backup back to the same Contents>MacOS folder to revert back to the original. N.B. you will need to have admin privileges to do this.
3. Download and launch HexEditor (click here to be taken to the VT page for it).
4. Highlight the libvcl645mxp.dylib file within the NeoOfficeJ>Contents>MacOS folder and get info on it. Change the permissions for the Owner and Group to "Read and Write" (from Read Only - if you don't do this you will not be able to edit the file). Drag and drop the now write-able file onto HexEditor to open it.
5. Check the "Allow Editing" box:
6. In the Selection>First box (round highlight below) type "0x6ca0" and you will be jumped to the right place in the code (rectangular highlight below - it should be row 00006ca0 as indicated in the left hand column of HexEditor - if it isn't you've mistyped something and need to start again):
7. Highlight the various c0 (in turn) as indicated by the arrows below and in the "View/Edit As...>char:" field (encircled below), replace the c0 with e6 (or ef or whatever) and press enter.
8. Once you have edited the three c0 (the changes are made automatically by default - there is no need to save the file), go back to the finder and change the Owner and Group permissions back to Read Only (don't know if that is necessary or not, but I did it to be on the safe side). Relaunch NeoOffice/J and, if you aren't already using it, switch to the Standard view to see the effects take place (Preferences>View>Standard).
For those wanting to experiment, you can use the application called "DigitalColour Meter" in your /Applications/Utilities folder to determine the "RGB as Hex value, 8 bit" of various interface elements:
You move your pointer over the interface and it will show the various colours of each pixel. To lock the values, press command-L (and repeat to unlock them).
Now, unless someone manages to find this in the actual source code so that we don't have to this hackery, does anyone know how we could Applescript this, or could we host an already hacked file for people to download and install for the time being? Your opinion Patrick? _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
Joined: Feb 12, 2005 Posts: 607 Location: Australia
Posted: Thu Apr 07, 2005 5:46 am Post subject: Explanation by JKT
Very lucid! As a really "basic" learner at this, I had worked some of this out by trial and error. If only I'd had your superb guide first '' I still learnt a few things I had done wrong, or done the long way. Thanks.
Now, unless someone manages to find this in the actual source code so that we don't have to this hackery, does anyone know how we could Applescript this, or could we host an already hacked file for people to download and install for the time being? Your opinion Patrick?
My opinion is that if you edit binary files don't even think of filing a bug if things go wrong. By editing the binary, you are now the author of code changes and, consequently, if crashing starts occurring, I won't look at it if you are using a edited binary.
In case JKT didn't already mention this. Be certain to NEVER change the file SIZE of any DATA file or you'll ruin the file basically, it won't work, and may (will) crash your app and more damaging possibly your sytem. In other words a byte for byte exchange unless of course you know where and how to change the size as demonstrated in the ResEx iTunes example further above in the thread.
And always work on a copy of the file and rename as needed to swap out (swap with different names so you don't replace one file for the other), so if you screw up, you can revert to your pristine original file.
I guess you don't happen to have a NOJ ver. 0.7 tutorial laying around do you? *not getting anyway myself* : (
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Fri Apr 08, 2005 4:32 am Post subject:
pluby wrote:
JKT wrote:
Now, unless someone manages to find this in the actual source code so that we don't have to this hackery, does anyone know how we could Applescript this, or could we host an already hacked file for people to download and install for the time being? Your opinion Patrick?
My opinion is that if you edit binary files don't even think of filing a bug if things go wrong. By editing the binary, you are now the author of code changes and, consequently, if crashing starts occurring, I won't look at it if you are using a edited binary.
Patrick
Point taken. I guess the upshot of that is you can try this out to see what e.g. %grey you would like to see in the final version once Patrick/Ed can do this directly to the source, but revert back to the original file once you've finished playing to continue helping bug test. _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
First off, I'd like to thank JKT for taking some load off of dan and providing the excellent easy-to-follow or should I say, Mac classic-like, NOJ 1.1 window /toolbar/menu coloring tutorial.
Would also like to thank him for keeping this Yank across the pond motivated this week : )
After staring at the ver. 0.7 comparable lib file (libvcl641mxp.dylib) and at his tutorial for ver. 1.1 seemingly forever, I realized that even though logic said that changing the 3 c0's listed in the ASCII side of the code of the lib should change ver. 0.7 window coloring, the light bulb went off in my head and the duh moment occurred, "It's the HEX stupid!"
So I went ahead and changed the 19 or 20 instances of CO in the HEX side to E6 and Viola, 'Minty Green' windows, Toolbars, Menus including drop down, open and and save dialog boxes and the best part, existing icon button backgounds in the toolbars w/o any additional editing! I didn't bother marking down hex locations in the data file as a search showed no other C0C0 nor E6E6 locations so it was clean swap.
Think original Crest toothpaste comin' out of the tube... Yuk, a Colgate man myself growin' up.
Apparently, those changes only affected the G and B values 'cause when I Digital Color Meter'd the minty green in the window, it show 8-bit hex values of CO E6 E6, for R G B respectively.. Not sure why the R CO value wasn't changed.
Any way, spurred on by this partial success I played with swapping out the E6's with some other G B values that combined with a CO R, which I haven't figured out how to change yet, would give sonmething alittle closer to Aqua grey or old or new NOJ ship colors.
I eventually corrupted that file (not the greatest typist, tired, bad substiituting or something more siniter?) and NOJ would quit after the splash screen. But never fear, I'm working on a copy, right? So I trash that duplicate file make another Duplicate of the lib and start again. Another point in Minty Green window mode, Whenever I clicked on a drop down menu in any of the toolbars, say to pick adifferent Font style or font size, NOJ crashed, but didn't affect the System.
Gonna try a fresh Dup tomight of the lib and try substituting other G B values to see if the Minty Green can be changed.
This post is about ver. 0.7 so please kindly refer to dan and JKT's work for your 1.1 ver. tweaking needs.
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.
I did not follow this thread closely but, out of curiosity, I checked out the two relevant files from the NeoJ CVS server. It turns out that the key lines are easy to find and modify:
Colors are defined in color.hxx...
If some of you have a full compiling source tree (I don't, bandwith, space...) it should be pretty easy to test color change. Then I can make a CVS diff for Patrick to include.
Any taker?
Joined: Feb 12, 2005 Posts: 607 Location: Australia
Posted: Fri Apr 08, 2005 7:52 am Post subject:
fa wrote:
We need to agree on some colors here. I'm assuming that #E8E8E8 is what the current consensus for the window background color is?
Dan
Hi Dan
Thanks for this. I must admit I suggested E8E8E8, and I liked it, but I found it a little hard on the eyes when I was using it for longer periods, so I went back to E6E6E6.
This is great, some of the finest minds from England France, Germany, Italy, Spain, Japan and the US. Talk about global collaboration! Not bad for a weeks worth of work. (of couse, dan and Ed and Pat and the rest of NEO/J part-time team excluded as they having been working hard for a long, long time.)
We really do appriciate your efforts although sometimes our own pettiness says/gives the impression otherwise.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
'
' I still learnt a few things I had done wrong, or done the long way. Thanks.