builing v7 on moz 1.2.1
Posted by: m4ster
Date: February 24, 2003 12:36AM


Could you please put up a tarball for v7sp1 it is possible? Thanks.

Today I have my first ever build of kmeleon v7 running against my first ever build of mozilla1.2.1.

My notes on the getting things to build are at the bottom.

:-D

thx

m4ster



Building K-meleon 7 against mozilla1.2.1
=============================

Get the mozilla source from here http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2.1/src/mozilla-source-1.2.1.tar.gz

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.

Read the instructions at http://kmeleon.sourceforge.net/docs/build.php but do not follow them to the letter. Instead setup the following evn.sh within cygwin by running "source env.sh" in the bash shell (see footnote [2]).

#=======================================
# This is a port of evn.bat

export MOZ_CVS_FLAGS=-z3

export MOZ_BITS=32
export OS_TARGET=WINNT
export WINOS=$OS_TARGET
export _MSC_VER=1200

export DISABLE_TESTS=1
export MOZ_NO_ACTIVEX_SUPPORT=1
export CONFIG_SHELL=SH.EXE

#=======================================

N.B. I let VC++ register its own environment variables when I installed it.

N.B I used the cygwin perl rather than the active state one and the cygwin tools were on the path.

Now go into mozilla/embedding directory and run the command "make". This will cause the embeddable components of mozilla to be built.

Go into C:\mozilla\mozilla-source-1.2.1\mozilla\dist\lib\ and run the command "copy embed_base_s.lib baseembed_s.lib" which is the name that the kmeleon is expecting for this library file.

Get the k-meleon 0.7 source from here http://prdownloads.sourceforge.net/kmeleon/k-meleon07_src.zip and unpack it next to the mozilla code at C:\mozilla\mozilla-source-1.2.1.

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.

Follow step 5 at http://kmeleon.sourceforge.net/docs/build.php but use the following list of include files as there are a couple of new additions.

../mozilla/dist/include/docshell,../mozilla/dist/include/dom,../mozilla/dist/include/embed_base,../mozilla/dist/include/exthandler,../mozilla/dist/include/find,../mozilla/dist/include/gfx,../mozilla/dist/include/helperAppDlg,../mozilla/dist/include/intl,../mozilla/dist/include/layout,../mozilla/dist/include/necko,../mozilla/dist/include/nkcache,../mozilla/dist/include/pref,../mozilla/dist/include/profile,../mozilla/dist/include/shistory,../mozilla/dist/include/string,../mozilla/dist/include/uriloader,../mozilla/dist/include/wallet,../mozilla/dist/include/webbrwsr,../mozilla/dist/include/webbrowserpersist,../mozilla/dist/include/webshell,../mozilla/dist/include/widget,../mozilla/dist/include/windowwatcher,../mozilla/dist/include/xpcom,../mozilla/dist/include/nspr,../mozilla/dist/include/imglib2

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.

Re: builing v7 on moz 1.2.1
Posted by: m4ster
Date: February 24, 2003 12:39AM

ouch! sorry about the text not wrapping!

Re: builing v7 on moz 1.2.1
Posted by: Andrew
Date: February 24, 2003 03:20AM

m4ster,

I'll check on a tarball.

Thanks for the notes. I have revised build notes that haven't been posted yet. I'll make sure to incorporate your notes into it.

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 26, 2003 12:37AM

m4ster:

Thanks for posting this, I'm building as we speak. For a tarball, you don't really need one seeing as you have CVS from cygwin (or you can install it via the cygwin setup anyhow).

Just do this from a cygwin console:

export CVSROOT=':pserver:anonymous@cvs.kmeleon.sourceforge.net:/cvsroot/kmeleon'

cvs login

(just hit enter at the password prompt)

cvs -z3 checkout k-meleon


That will checkout the latest K-M source (from the module "k-meleon") to the directory "k-meleon" within the directory that you ran the cvs command from.


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: Andrew
Date: February 26, 2003 01:10AM

MonkeeSage,

Good point. That really is the cleanest way to do it. It's not like checking out Mozilla through CVS which takes forever!

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 26, 2003 03:45AM

I just built Moz 1.3b and K-M, a few minor technicalities:

1. In BrowserView.cpp, ln. 846:

Commented:

/* void CBrowserView::OnFileSaveAs()
{

nsCString fileName;

GetBrowserWindowTitle(fileName); // Suggest the window title as the filename

char *lpszFilter =
"Web Page, HTML Only (*.htm;*.html)|*.htm;*.html|"
"Web Page, Complete (*.htm;*.html)|*.htm;*.html|"
"Text File (*.txt)|*.txt|"
"All Files (*.*)|*.*||";

CFileDialog cf(FALSE, "htm", fileName.get(), OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
lpszFilter, this);

if(cf.DoModal() == IDOK)
{
CString strFullPath = cf.GetPathName(); // Will be like: c:\tmp\junk.htm
char *pStrFullPath = strFullPath.GetBuffer(0); // Get char * for later use

BOOL bSaveAll = FALSE;
CString strDataPath;
char *pStrDataPath = NULL;
if(cf.m_ofn.nFilterIndex == 2)
{
// cf.m_ofn.nFilterIndex == 2 indicates
// user want to save the complete document including
// all frames, images, scripts, stylesheets etc.

bSaveAll = TRUE;

int idxPeriod = strFullPath.ReverseFind('.');
strDataPath = strFullPath.Mid(0, idxPeriod);
strDataPath += "_files";

// 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
}

// Save the file
nsCOMPtr<nsIWebBrowserPersist> persist(do_QueryInterface(mWebBrowser));
if(persist)
{
nsCOMPtr<nsILocalFile> file;
NS_NewNativeLocalFile(nsDependentCString(T2A(pStrFullPath)), TRUE, getter_AddRefs(file));

nsCOMPtr<nsILocalFile> dataPath;
if (pStrDataPath)
{
NS_NewNativeLocalFile(nsDependentCString(pStrDataPath), TRUE, getter_AddRefs(dataPath));
}

if(bSaveAll)
persist->SaveDocument(nsnull, file, dataPath, nsnull, 0, 0);
else
persist->SaveURI(nsnull, nsnull, file);
}
}

} */


Added asmpgmr's suggested patch:

void CBrowserView::OnFileSaveAs()
{

// 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:

66: persist->SaveURI(srcURI, nsnull, nsnull, nsnull, nsnull, file);
221: persist->SaveURI(aURI, nsnull, nsnull, nsnull, nsnull, file);

Other than that, everthing went smooth. Runs nice and fast.


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: Andrew
Date: February 26, 2003 04:32AM

MonkeeSage,

So are you going to help us clear up some of those bugs??
smiling smiley

Good work. At some point, we'll start checking in the Mozilla 1.3 code so that we keep on top of everything.

Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 26, 2003 04:35AM

MonkeeSage,

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.

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 26, 2003 05:21AM

Andrew:

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.


asmpgmr:

I could only build:

bmpmenu.dll
external.dll
favorites.dll
fullscreen.dll
history.dll
macros.dll
rebarmenu.dll
toolbars.dll
winamp.dll

But I ran into multiple build errors on:

bookmarks.dll
layers.dll

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. winking smiley


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 26, 2003 05:31AM

asmpgmr:

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...").

smiling smiley


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: m4ster
Date: February 26, 2003 09:13AM


:-) aha! now i feel like i am one of the gang!

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?

:-D

(ouch - i really wish that my first post had wrapped....)

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 26, 2003 09:45AM

m4ster:

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. winking smiley

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. smiling smiley

Anyways, that's the cheater's answer lol, mabye someone else can give you the
real answer. smiling smiley

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.

Thanks again for posting your build notes! Very helpful!! grinning smiley


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 26, 2003 08:33PM

MonkeeSage,

Here are a couple of other things you might want to try in your build:

---
Bug 306 (remove the evil "URL:" text)

In BrowserFrm.cpp find the following line:

m_wndReBar.AddBar(&m_wndUrlBar, "URL:");

Change to:

m_wndReBar.AddBar(&m_wndUrlBar, NULL);

---
Bug 381 (add force reload command - Mozilla's Ctrl-Shift-R)

In BrowserView.cpp add the function:

void CBrowserView::OnNavForceReload()
{
if(mWebNav)
mWebNav->Reload(nsIWebNavigation::LOAD_FLAGS_BYPASS_CACHE);
}

Also add:
ON_COMMAND(ID_NAV_FORCE_RELOAD, OnNavForceReload)
to the BEGIN_MESSAGE_MAP list above that.

In defineMap.cpp add:
DEFINEMAP_ADD(ID_NAV_FORCE_RELOAD)

In resource.h add:
#define ID_NAV_RELOAD 32779

If this builds correctly then in accel.cfg add:
CTRL SHIFT R = ID_NAV_FORCE_RELOAD

Re: builing v7 on moz 1.2.1
Posted by: Andrew
Date: February 26, 2003 10:15PM

You guys might consider getting on the developers' list too. That's the most effective way to discuss code changes in a way that everyone is on the same page about what is being tested and considered.

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 01:50AM

asmpgmr:

Bug 306 -
Fix confirmed.

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();

smiling smiley


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. smiling smiley


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 08:50AM
Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 27, 2003 03:23PM

MonkeeSage,

Thanks, I added the updated info to bug 381.

Any chance of making a build for Mozilla 1.2.1 as well ? All of the plugins should build without any problems since to my knowledge there are no API differences between 1.2b and 1.2.1.

Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 27, 2003 03:50PM

MonkeeSage,

Here's another something to try:

Bug 387 - Add save frame as (ID_FILE_SAVE_FRAME_AS)

void CBrowserView::OnFileSaveFrameAs()
{

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);
}

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

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 04:40PM

asmpgmr:

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... ).

Re: Bug 387 -

Had compiler errors:

BrowserView.cpp
BrowserView.cpp(874) : error C2065: 'mCtxMenuCurrentFrameUrl' : undeclared identifier
BrowserView.cpp(874) : error C2228: left of '.Length' must have class/struct/union type

I have no clue what the correct method for grabbing the current frame URL is...


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 05:03PM

LOL...

Its the little things you love...

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

if(! mCtxMenuCurrentFrameURL.Length())

So the one part goes like this:

void CBrowserView::OnFileSaveFrameAs()
{

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.


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 05:15PM

Bug 387 -
Fix confirmed.

Tested on multiple pages at:

http://www.unh.edu/NIS/Courses/Frames/

All of them returned the correct file name in the save dialogue, as specified in the parent source.

Updated my .zip package with the new build.


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 05:58PM

asmpgmr:

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?


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 27, 2003 07:11PM

MonkeeSage,

I added the correction to bug 387.

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.

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 07:31PM

LOL...

Yeah please do post it, I'll try anything once or twice. smiling smiley


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 27, 2003 07:47PM

OnFileSaveAs/OnFileSaveFrameAs version 2

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.


BrowserView.cpp
---------------

BEGIN_MESSAGE_MAP(CBrowserView, CWnd)
...
ON_COMMAND(ID_FILE_SAVE_FRAME_AS, OnFileSaveFrameAs)


void CBrowserView::OnFileSaveAs()
{

// 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::OnFileSaveFrameAs()
{

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);

char sDefault[] = "default.htm";
char *pFileName = sDefault;
char *pBuf = NULL;

if (strlen(path.get()) > 1) {
// The path may have the "/" char in it - strip those
pBuf = new char[strlen(path.get()) + 5]; // +5 for ".htm" to be safely appended, if necessary
strcpy(pBuf, path.get());
char* slash = strrchr(pBuf, '/');

if (slash) {
if (strlen(slash) > 1)
pFileName = slash+1; // filename = file.ext
else {
while ((slash > pBuf) && (strlen(slash) <= 1)) { // strip off extra /es
*slash = 0;
slash--;
slash = strrchr(pBuf, '/');
}
if (slash && (strlen(slash) > 0)) {
pFileName=slash+1; // filename = directory.htm
strcat(pFileName, ".htm");
}
}
}
else {
// if there is no slash, then it's probably an invalid url (javascript: link, etc)
MessageBox((CString)("Cannot Save URL ") + path.get());
return NS_ERROR_FAILURE;
}
}
else {
aURI->GetHost(path);
if (strlen(path.get()) >= 1) {
pBuf = new char[strlen(path.get()) + 5]; // +5 for ".htm" to be safely appended, if necessary
strcpy(pBuf, path.get());
pFileName = pBuf;
for (int x=strlen(pBuf)-1; x>=0; x--)
if (pBuf[x] == '.') pBuf[x] = '_';
strcat(pBuf, ".htm"); // filename = www_host_com.htm
}
}

// This is so saving cgi-scripts doesn't produce invalid filenames
char *questionMark = strchr(pFileName, '?');
if (questionMark)
*questionMark = 0;

char *extension = strrchr(pFileName, '.');
if (!extension) {
extension = strrchr(sDefault, '.');
strcat(pFileName, extension);
}
extension++;

char lpszFilter[256];
strcpy(lpszFilter, extension);
strcat(lpszFilter, " Files (*.");
strcat(lpszFilter, extension);
strcat(lpszFilter, ")|*.");
strcat(lpszFilter, extension);
strcat(lpszFilter, "|");
strcat(lpszFilter, "Web Page, HTML Only (*.htm;*.html)|*.htm;*.html|");
if (bDocument)
strcat(lpszFilter, "Web Page, Complete (*.htm;*.html)|*.htm;*.html|");
strcat(lpszFilter,"Text File (*.txt)|*.txt|"
"All Files (*.*)|*.*||");

CFileDialog cf(FALSE, extension, pFileName, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
lpszFilter, this);

cf.m_ofn.lpstrInitialDir = theApp.preferences.saveDir;

if(cf.DoModal() == IDOK) {
CString strFullPath = cf.GetPathName(); // Will be like: c:\tmp\junk.htm
theApp.preferences.saveDir = cf.GetPathName();
int idxSlash;
idxSlash = theApp.preferences.saveDir.ReverseFind('\\');
theApp.preferences.saveDir = theApp.preferences.saveDir.Mid(0, idxSlash+1);


BOOL bSaveAll = FALSE;
CString strDataPath;
char *pStrDataPath = NULL;
if(bDocument && cf.m_ofn.nFilterIndex == 2)
{
// cf.m_ofn.nFilterIndex == 2 indicates
// user want to save the complete document including
// all frames, images, scripts, stylesheets etc.

bSaveAll = TRUE;

int idxPeriod = strFullPath.ReverseFind('.');
strDataPath = strFullPath.Mid(0, idxPeriod);
strDataPath += "_files";

// 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;

nsString filename;
filename.AssignWithConversion(strFullPath.GetBuffer(0));

nsCOMPtr<nsILocalFile> file;
NS_NewNativeLocalFile(nsDependentCString(T2A(strFullPath.GetBuffer(0))), TRUE, getter_AddRefs(file));

nsCOMPtr<nsILocalFile> dataPath;
if (pStrDataPath)
{
NS_NewNativeLocalFile(nsDependentCString(pStrDataPath), TRUE, getter_AddRefs(dataPath));
}

if(!bDocument) {
CProgressDialog *progress = new CProgressDialog(FALSE);
progress->InitPersist(aURI, file, persist, TRUE);
persist->SaveURI(aURI, nsnull, file);
}
else
if(bSaveAll)
persist->SaveDocument(nsnull, file, dataPath, nsnull, 0, 0);
else
persist->SaveURI(nsnull, nsnull, file);
}

if (pBuf)
delete pBuf;

return NS_OK;
}

Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 27, 2003 08:03PM

MonkeeSage,

Before testing that major change you should verify that the two issues I mentioned with the original updated code are indeed issues.

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 08:18PM

asmpgmr:

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::OnFileSaveFrameAs()
{

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, TRUE);
}

========

BrowserViewUtils.cpp:
========

Both of the persist->SaveURI... lines need 6 params:

persist->SaveURI(aURI, nsnull, nsnull, nsnull, nsnull, file);
persist->SaveURI(nsnull, nsnull, nsnull, nsnull, nsnull, file);


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 08:29PM

Ahh...I got it

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. winking smiley

I'm going to test this theory right now..

brb

Re: builing v7 on moz 1.2.1
Posted by: MonkeeSage
Date: February 27, 2003 08:36PM

Yup, that was it...

Here is the culprit line from BrowserViewUtils.cpp:

if(bDocument && cf.m_ofn.nFilterIndex == 2)

Changed to:

if(bDocument && cf.m_ofn.nFilterIndex == 3)

Works! I've saved 4 pages so far (start page, and 3 one three random from the forums)--all worked to save complete and single as expected. Sweet!! Nice job! grinning smiley

Updated my .zip package.


Shelumi`El
Jordan

S.D.G

Re: builing v7 on moz 1.2.1
Posted by: asmpgmr
Date: February 27, 2003 10:31PM

MonkeeSage,

Thanks for catching the typo and index issue.

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 ?

K-Meleon forum is powered by Phorum.