Be sure to extract it into the directory C:\mozilla\mozilla-source-1.2.1 as there are some hardcoded absolute paths in the make files that build the embedded gecko :-( see footnote [1] if you have less than 2GB of free space on this drive that you will need.

Follow the instructions here http://www.mozilla.org/build/win32.html and do the "make -f client.mk build_all_depend" command as the last step. It takes a long while to build. If you get stuck building mozilla read the instructions here http://kmeleon.sourceforge.net/docs/build.php to get some ideas of things to tweak to get you a building mozilla. Run your working mozilla. You may want to make a copy resulting dist directory with all your hard work so that it does not get zapped later on.

Get the k-meleon 0.7 distribution and install it on your machine. This is not cheating (honest!) as there is lots of packaging that your newly built k-meleon.exe will require if you want to be able to run it once you have built it.

In the same projects settings dialog go to the Link tab and select input from the drop down. Add "MSVCRTD" to the Ignore Libraries field. Add "../mozilla/dist/lib" to the empty Additional Library Path field.

Ensure that you change the output directory in amongst all the junk hidden in the text area at the bottom of the Link tab. Change it to build into the location where you have installed kmeleon 7 so that your new executable will have all the files that it will need when you attempt to run it. Your build of k-meleon.exe should run with first time against the mozilla dlls that came out of your kmeleon 7 installer.

Now replaced the dlls your k-meleon directory with those that you built into mozilla/dist/bin directory. You also have to replace the dlls in the component subfolder with those that you built into mozilla/dist/bin/component or your exe will crash. Also delete the two .dat files in the components directory so that they are regenerated by your new binary. If it runs now with your dlls then you have succeeded! (see footnote [3] & see footnote [4])

To Dos:
=======

* Get mozilla to compile optimised.
* Get k-meleon to compile optimised (see footnote [5]).
* Do step 6 at http://kmeleon.sourceforge.net/docs/build.php
* Compile the other projects in the workspace.
* Find the cvs tags for v7sp1 and compile this.
* Figure out how to make it installable (mostly out of curiosity to see how it is done).
* Write a spell check plug-in ;-D

Footnotes:
==========

[1] If you really do not have space on that drive then you could try getting cygwin to mount your other drive and put in a symbolic link at /cygdrive/c called mozilla-source-1.2.1 pointing at your source directory with the "ln -s" command. Alternatively you could use a good editor like TextPad to find all occurrences of mozilla-source-1.2.1 in the code and change any paths that you find to point where you put the sources.

[2] I suspect that the mozilla build script might be ignoring these settings. I need to check the mozilla forums, notes and make files to figure this out.

[3] My copy crashes when you close the program.

[4] At this point the program needs the debug versions of the VC++ runtime libraries to run.

[5] If you run ( Project > Export Makefile...) in VC++ it will create .mak files which you can run on the cmd line with "nmake /f your_makefile". This allows you to see what flags and options are really being set and to tweak them yourself. Also note that VC++ allows you to import a project that is a make file and build and debug it. This makes for a project and workspace that you can put under source control rather than use the doggy Microsoft .dsw files and the like :-) and will allow you to make a project that builds like mozilla - on the command line with you in control.

// At this stage strDataPath will be of the form
// c:\tmp\junk_files - assuming we're saving to a file
// named junk.htm
// Any images etc in the doc will be saved to a dir
// with the name c:\tmp\junk_files

// Try to get the file name part from the URL
// To do that we first construct an obj which supports
// nsIRUI interface. Makes it easy to extract portions
// of a URL like the filename, scheme etc. + We'll also
// use it while saving this link to a file
nsresult rv = NS_OK;
nsCOMPtr<nsIURI> currentURI;
rv = mWebNav->GetCurrentURI(getter_AddRefs(currentURI));
if(NS_FAILED(rv) || !currentURI)
return;

URISaveAs(currentURI);
}

This patch is CONFIRMED to work--it presents the actual file name instead of the window title as the file to save, as expected.

2. In BrowserViewUtils.cpp, ln 66, 221:

The Moz 1.3b SaveURI method now takes 6 params, not 3, so change the two lines as follows:

I'm glad to hear my OnFileSaveAs replacement works, hopefully Andrew sees this and passes the info on to the developers. You should also verify that the file type matches the extension and not always html, and that the download directory is whatever pref kmeleon.general.saveDir is pointing to and not K-Meleon.

Did you build the plugins as well ? If so then you should have several new features and fixes beyond 0.7.1 including bookmark keywords, proper algebraic hierarchy in macro expression evaluation, some other macro fixes, the ability to specify separators between toolbar buttons, and the ability to remove toolbar tooltips.

I'll do what I can, but it won't be much, lol. There were a few other build problems that I forgot to mention above as well; nothing major, but I had to add a return 0; to about 3 or 4 lines in BrowserFrm.h (at ln. 72, 88, 138, if I recall). Next few days, I'll write up all the minor build / usage problems I've found in using it with 1.3, and (if I can fix them) the patches for them; then I'll file the bug reports for each of them. Or if you'd rather, I can send to you all at once in an email.

But it looked like it was just stuff like what I mentioned above though, where a method's syntax has changed slightly from the 1.2 branch to the 1.3 branch, and not coding errors, so I might be able to hack the bugs out. But then again, I'm not C++ coder, nor a Win32 coder, so if it is too complex I will just wait till the real devs fix it lol. ;)

You should also verify that the file type matches the extension and not always html, and that the download directory is whatever pref kmeleon.general.saveDir is pointing to and not K-Meleon.

Done.

.exe shows .exe (executable files), .zip shows .zip (compressed files), &c. I tried about 5 files types (.Z, .zip., .exe, .html, .txt, .php), and it is using the directory from the pref (the exact same dir that is used when right a link clicked and "saved as...").

MonkeeSage comment about building from cvs is of course totally valid. I was just being over cautious to get a build that is know to work straight way before "risking" the top of cvs.

I had tried to do a view history and log on the source but the official tarball was pulled by doozan and so it password prompted me for "doozan@cvs.kmeleon.sourceforge.net" when I try to do a cvs log (a.k.a History) or a revision graph. This confused me as it was late but now I have figured out that I should pull as anonymous and that allows me to do cvs log and history commands. Now I can see the tags and versions.

Should i just trust that it will build from the top almost all of the time? Are you guys finding mozilla embedded stable enought to just pull it from the top of moz every time? I have had bad experiences working with folks that brake the top of cvs all the time :-(

How do / Have you guys deside what version of moz the k0.8 release will be taken against or do you just build the latest milestone release from Moz.

Could someone drop me a quick note about how they set their compiler optimization flags for moz and build an optimized kmeleon?

Since I'm not a K-M dev, I'm not really sure, but Andrew should know. But as far as
I know, K-M has a pretty strict no-commit policy on CVS, at least that is the
impression I get from reading the bug reports...CVS commits are never mentioned
untill the bug status is bumped to "Fixed."

My Mozilla build crashed on exit, just like yours did (no clue why either, and I'm
certainly not going to try and build the mozilla debug lol), so I cheated and used
the moz idls and libs to build K-M, then I used moz release / nightly (one of the
two lol, but I dob't remember...I have a bad habit of naming directories things that I
forget what they stand for later) for the root dlls and components. No more crashy.
Then I rebased them with the binary from my moz build. I figure that's as
optimized as anything I compile. Most of the nightly builds of 1.3b are ICL 7
anyways. ;)

So I'm not sure what optimizations you should use, but you might give these a try;
these are what I use on everything I compile with GCC:

-fsave-memoized -fexpensive-optimizations -O3

Those should:

1. use huerstics for preprocessing, 2. & 3. use lots of memory and CPU time to
preprocess and arrange and tokenize the code (the result should be fewer and
smaller linkages, so a smaller footprint on your output binary and a smaller
filesize).

But I would recommend just using the 1.2.1 release for your backend and only
using your new K-M binary. Ideally, the release dlls have the exact same
entry points as those you build, and everything will play very happily together.

Oh...one other thing, your K-M binary is going to be like 2 megs including all the
dubugging symbols, so you should probably build the release instead (in VC++
Build -> Set Active Configuration... -> k-meleon - Win32 release), which results in
a binary of about 250k.

That was one of the first things I did yesterday lol. NULL or "" both return a null string and effectively get rid of the "URL:" label.

--------

Bug 381 -
Fix confirmed.

A slight change from your instructions--your forget a word and one more line is needed:

In resource.h add:
#define ID_NAV_RELOAD 32779

Must be:
#define ID_NAV_FORCE_RELOAD 32779

Then in BrowserView.h add:
afx_msg void OnNavForceReload();

Andrew:

Right on...I didn't previously think there was much point (because I couldn't get Mozilla compiled [I wasn't using cygwin then] and so I couldn't build K-M)...but If I'm going to be trying to play around with the source a little now, I might as well join the list so I'm not just re-inventing the wheel.

// Try to get the file name part from the URL
// To do that we first construct an obj which supports
// nsIRUI interface. Makes it easy to extract portions
// of a URL like the filename, scheme etc. + We'll also
// use it while saving this link to a file
nsresult rv = NS_OK;
nsCOMPtr<nsIURI> frameURI;
rv = NS_NewURI(getter_AddRefs(frameURI), mCtxMenuCurrentFrameUrl);
if (NS_FAILED(rv))
return;

URISaveAs(frameURI);
}

Also add:
ON_COMMAND(ID_FILE_SAVE_FRAME_AS, OnFileSaveFrameAs)
to the BEGIN_MESSAGE_MAP list above that.

In BrowserView.h add:
afx_msg void OnFileSaveFrameAs();

In defineMap.cpp add:
DEFINEMAP_ADD(ID_FILE_SAVE_FRAME_AS)

In resource.h add:
#define ID_FILE_SAVE_FRAME_AS 32811

If this builds correctly then add ID_FILE_SAVE_FRAME_AS to appropriate
frame context menus in menus.cfg

I can do a 1.2.1 build tomorrow, all I should have to do is DL & compile moz 1.2.1 and replace my 1.3b build directory with the 1.2.1 directory, then rebuild K-M using the 1.2.1 idls and libs. I'll make another package like I did with the 1.3b build including the plugins that build successfully. (I might have to email it if I don't have the webspace, the server quota cometh... ).

I scanned through the viewframesource function and I caught it by chance:

if(! mCtxMenuCurrentFrameURL.Length())

So the one part goes like this:

void CBrowserView:nFileSaveFrameAs()
{

if(! mCtxMenuCurrentFrameURL.Length())
return;

// Try to get the file name part from the URL
// To do that we first construct an obj which supports
// nsIRUI interface. Makes it easy to extract portions
// of a URL like the filename, scheme etc. + We'll also
// use it while saving this link to a file
nsresult rv = NS_OK;
nsCOMPtr<nsIURI> frameURI;
rv = NS_NewURI(getter_AddRefs(frameURI), mCtxMenuCurrentFrameURL);
if (NS_FAILED(rv))
return;

URISaveAs(frameURI);
}

Doh! Stupid case-sensative compiler lol! Built fine after that, I'll test it now and let you know the results.

Hmmm...I was just thinking, it might be nice to use your convhist.exe code in a command ID, that way it will get ride of the extra window and solve the crashing problems people had with it (I haven't changed it at all since that final build, BTW). What do you think?

My convhist program is temporary solution until a global_history.dll plugin is written.
Such a plugin would give you a nice window like the bookmarks and access the
history data directly via a Gecko call and get the current history without missing any
entries due to the file only being written every 10 updates.

My proposed RFE (bug 351) would address the extra window issue. I don't know
why it would crash for anyone considering it's a fairly simple ANSI C program
which runs as a win32 console app, it doesn't crash for me.

By the way I think there may be two differences in functionality introduced with the
updated OnFileSaveAs code: 1) a dialog box is opened which wasn't done with the
original code. 2) Save as web page complete functionality may be gone. I have
some new code which combines portions of the old OnFileSaveAs code with the
URISaveAs code in BrowserViewUtils.cpp and should fix both but I'm not sure it
will work or not since there's some C++ nastiness involved. Curse C++ and OOP,
it's too weird and abstract. I can post it if you want to try it.

URISaveAs now called with second parameter TRUE which is bDocument flag
within URISaveAs function. This is used so that these functions can use the
save as web page complete code (bSaveAll) while OnSaveLinkAs/OnSaveImageAs
do not, these two functions may need to be called with FALSE but I think that's
the default if no parameter is specified. The code from the old OnFileSaveAs from
BOOL bSaveAll = FALSE; to the end of the if block has been incorporated into
URISaveAs and bDocument added to the if condition so that OnSaveLinkAs and
OnSaveImageAs will never have save as web page complete as an option. After
that parts of the old OnFileSaveAs were incorporated into URISaveAs which
should display the progress dialog from OnSaveLinkAs/OnSaveImageAs
(bDocument = FALSE) and not display it for OnFileSaveAs/OnFileSaveFrameAs
(bDocument = TRUE) and call SaveDocument if web page complete was selected.
I'm not sure what the difference is in the calls to SaveURI with the first parameter,
in case it has a value aURI in the other it is nsnull so I preserved the original
usage in each case.

// Try to get the file name part from the URL
// To do that we first construct an obj which supports
// nsIRUI interface. Makes it easy to extract portions
// of a URL like the filename, scheme etc. + We'll also
// use it while saving this link to a file
nsresult rv = NS_OK;
nsCOMPtr<nsIURI> currentURI;
rv = mWebNav->GetCurrentURI(getter_AddRefs(currentURI));
if(NS_FAILED(rv) || !currentURI)
return;

URISaveAs(currentURI, TRUE);
}

void CBrowserView:nFileSaveFrameAs()
{

if(! mCtxMenuCurrentFrameURL.Length())
return;

// Try to get the file name part from the URL
// To do that we first construct an obj which supports
// nsIRUI interface. Makes it easy to extract portions
// of a URL like the filename, scheme etc. + We'll also
// use it while saving this link to a file
nsresult rv = NS_OK;
nsCOMPtr<nsIURI> frameURI;
rv = NS_NewURI(getter_AddRefs(linkURI), mCtxMenuCurrentFrameURL);
if(NS_FAILED(rv))
return;

URISaveAs(frameURI, TRUE);
}

BrowserViewUtils.cpp
--------------------

NS_IMETHODIMP CBrowserView::URISaveAs(nsIURI* aURI, bool bDocument)
{

NS_ENSURE_ARG_POINTER(aURI);

// Get the "path" portion (see nsIURI.h for more info
// on various parts of a URI)
nsCAutoString path;
aURI->GetPath(path);

// At this stage strDataPath will be of the form
// c:\tmp\junk_files - assuming we're saving to a file
// named junk.htm
// Any images etc in the doc will be saved to a dir
// with the name c:\tmp\junk_files

pStrDataPath = strDataPath.GetBuffer(0); // Get char * for later use
}

// Get the persist interface that we'll use for saving the file(s)
nsCOMPtr<nsIWebBrowserPersist> persist(do_QueryInterface(mWebBrowser));
if(!persist)
return NS_ERROR_FAILURE;

1.) Doesn't seem to be an issue for me, I haven't noticed anything extra show up.
2.) Is an issue, no more save web page complete option.

I have tried the update just now, but when I choose to save the web page complete, it only does the single page save...just the current file (but it gets that part right anyways). Evidently its not using the bSaveAll = TRUE; right or something.

I also had a few minor things with the code. Changes in bold:

BrowserView.cpp:
========

void CBrowserView:nFileSaveFrameAs()
{

if(! mCtxMenuCurrentFrameURL.Length())
return;

// Try to get the file name part from the URL
// To do that we first construct an obj which supports
// nsIRUI interface. Makes it easy to extract portions
// of a URL like the filename, scheme etc. + We'll also
// use it while saving this link to a file
nsresult rv = NS_OK;
nsCOMPtr<nsIURI> frameURI;
rv = NS_NewURI(getter_AddRefs(frameURI), mCtxMenuCurrentFrameURL);
if(NS_FAILED(rv))
return;

It is looking for index position 2 on the dropdown menu for file types, right? but we are changing it to the file name, nile the title--title don't have a type associated with them, files do--so we automatically have a type in the box now, moving us to index 3 that we want. ;)

Did you check all 4 save functions to make sure they all work properly without any
problems (Save As, Save Frame As, Save Link As, Save Image As) ? The first two
functions should allow save web page complete while the others should not. All four
should present consistent filenames and types based on the URL in the save dialog
and always use the download directory from pref kmeleon.general.saveDir.

Andrew,

I have a nicely indented text file with all of the changes for bugs 297, 306, 381, 387.
The new OnFileSaveAs code may resolve bug 202 as well. Would you be interested
in me sending a copy for the developers to look over ?