Dmitry Dartz wrote:
The whole "what is a profile and how do I deal with them as an embedder"
question has been blown way out of proportion. A profile is just a directory
to store settings in, and a couple of notifications that tells gecko 1) to
start using the profile and 2) to stop using the profile.
Sorry if I did not make myself clear enough.
Without proper profile handling, embedding application will definitely CRASH,
like mfcembed crahes or activex crashes etc.
Sure, I'm not saying that you don't need a profile. I'm saying that you just
have to do some additional work. That work can be summarized as:
1) use a directory service provider to return a profile path for "ProfD"
2) send profile-startup notifications
and, after you're done
3) send profile-shutdown notifications
You could use the profdirservice_s static library to do this, or write your
own code to do it.
It shouldn't need to unregister itself, the directory service will release
it during the shutdown process.
But it wasn't released. It's pretty simple to see by setting breakpoint in its
destructor to
make sure couter reached zero or not :) I my case it didn't until I
unregistered it manually.
Did you release *your* reference? The pointer from
NS_NewProfileDirServiceProvider is addreded, like any XPCOM getter function.
You either need to assign it to a nsCOMPtr using getter_AddRefs or manually
release it when you no longer need the reference.
What matters is why it's FireFox statially linked? Why not to get all
components tightly grouped in just one shared object (or dll
under Windowz)?
Effectively, startup time will be the same but xpcom/gre will be accessible and
useful.
Firefox is statically linked because that dramatically improves startup time
and other performance metrics, especially on Linux. As you may have seen
from various of my postings, we are trying to replicate those performance
numbers by linking all the components together into one DLL (xul.dll, or
libxul) and using hidden-visibility linkage on Linux.
With FireFox, I have to bundle approx 8-10MB and this extra weight bothers me.
8-10MB? When compressed using 7zip (as the Firefox distribution is),
XULRunner/win32 weighs 4.8MB.
The roadmaps and planning docs indicate that Firefox 3 will be based on
XULRunner and at that point embedders will be able to use the Firefox distro
as their embedding target. We're just not there yet.
--BDS
_______________________________________________
dev-embedding mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-embedding
