Installation - Mac OS X

[Christian]

I'm interested in building in the installation magic explained here <
http://limi.net/articles/firefox-mac-installation-experience-revisited/
> but, to be frank, I'm at a loss where to start and how to proceed.
For example, would it be best to work with the mozilla-central or
mozilla-1.9.2 trees mentioned here? < https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)
>

And when I have something useful, what's the best way to submit a
diff?

I'm an absolute novice with the Moz source, both technically and
politically. As such, would be be generally acceptable to be 100%
Cocoa for this action, or does the UI need to be presented in XUL?

-Christian

[Mike Beltzner]

On 2009-09-24, at 12:42 AM, Christian wrote:

> I'm interested in building in the installation magic explained here <
> http://limi.net/articles/firefox-mac-installation-experience-
> revisited/
>> but, to be frank, I'm at a loss where to start and how to proceed.
> For example, would it be best to work with the mozilla-central or
> mozilla-1.9.2 trees mentioned here? < https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)

Please start with the mozilla-central tree; all changes start there
and then move to the branches if they're considered safe and stable
and wanted for a release vehicle. If you want some help in getting
started, feel free to poke your head into #fx-team or #developers on irc.mozilla.org

> And when I have something useful, what's the best way to submit a
> diff?

Through Bugzilla; file a bug proposing the change you're describing
and attach the patch. Looks like you've found the documentation for
writing patches, but again, feel free to get in touch here or on IRC.
We love to help people who are helping! :)

> I'm an absolute novice with the Moz source, both technically and
> politically. As such, would be be generally acceptable to be 100%
> Cocoa for this action, or does the UI need to be presented in XUL?

100% Cocoa is fine, I think, as this is the OSX-only installer.

cheers,
mike

[Axel Hecht]

With a nit, the OS/X intl procedures are not supported. All localizable
strings should be in one of these file formats:

inc (set of #defines)
properties (utf-8 encoded, otherwise what java does)
dtd (as in xml)
ini (our variant, aka, as simple as it gets)

Whatever you do may require preprocessing at build time for each locale,
but shouldn't require recompiling any binaries.

Feel free to CC me on the bug once you filed one.

Axel

[Markus Stange]

Hi Christian,

I think nsAppRunner.cpp [1] is a good place to start. You probably need
to add the call to your code somewhere in that file.

Most of the Cocoa-specific code lives in widget/src/cocoa, so if you
need to add new files for your installer magic, placing them there is
probably a good idea.

100% Cocoa is the way to go.

Have fun,

Markus

[1]
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp

[Markus Stange]

In bug 456646 I'm using a property file to localize the Cocoa print
dialog. Christian, if you want to see how I'm doing it, look for
"printdialog.properties" in the patch.

Markus

[Chris Latko]

I'm going to take a crack at this as well. I have experience with the
codebase and have been doing OS X optimizations at http://www.latko.org/downloads/.
I'm currently on a nasty project, but should be able to get started
this weekend...

[belt...@mozilla.com]

I strongly encourage you to file bugs and share the numbers here so
you can collaborate. I'm really encouraged and impressed with your
zeal and enthusiasm!

cheers,
mike

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

[Christian]

You seem like you might be in a better position to get started that I
am. I'm still working through the Netscape/ns-vs-NextStep/NS naming.

That said, since this can (will) be Cocoa/Mac OS X-only it's mostly a
matter of finding the proper place to shim in. There seem to be a few
places that are likely culprits in nsAppRunner.cpp and
MacLaunchHelper.mm.

I've noticed that the first time Firefox gets launched from a new
location, it launches twice; spinning itself off. Subsequent launches
are "normal" in that the binary only gets run once. Can anyone
enlighten me on what's going on there/where to look at that
functionality? It seems an obvious opportunity to copy the
application if it's going to get re-launched anyway. I'm having no
luck finding that mechanism so far (is that the purpose of both
'firefox' and 'firefox-bin' in the app bundle?) but I'll keep digging.

-Christian

[Ted Mielczarek]

On Sep 24, 4:39 pm, Christian <linde...@gmail.com> wrote:
> You seem like you might be in a better position to get started that I
> am.  I'm still working through the Netscape/ns-vs-NextStep/NS naming.
>
> That said, since this can (will) be Cocoa/Mac OS X-only it's mostly a
> matter of finding the proper place to shim in.  There seem to be a few
> places that are likely culprits in nsAppRunner.cpp and
> MacLaunchHelper.mm.
>
> I've noticed that the first time Firefox gets launched from a new
> location, it launches twice; spinning itself off.  Subsequent launches
> are "normal" in that the binary only gets run once.  Can anyone
> enlighten me on what's going on there/where to look at that
> functionality?  It seems an obvious opportunity to copy the
> application if it's going to get re-launched anyway.  I'm having no
> luck finding that mechanism so far (is that the purpose of both
> 'firefox' and 'firefox-bin' in the app bundle?) but I'll keep digging.

Sometimes (related to various complicated things), the app will do
some setup and then restart itself. You don't really need to know the
technical details, but that's all basically handled in
nsAppRunner.cpp, and the actual restart logic is here:
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3469

Note that this can be after the app has run, since that same code path
is used if you click "restart firefox" from the add-ons manager, for
example.

You can probably get away with putting this logic pretty close to the
top of XRE_Main. It's a long and ugly function, but since a) you are
only using platform-native methods, likely, and b) you really would
like to do this as early as possible, it makes sense.

-Ted

[Alexander Limi]

Hi Christian & Chris,

We're in the process of ramping up for Firefox 3.7, and one of the things
we're considering landing is an improved Firefox 3.7 installer for the Mac.

Did any of you make any progress on this so far? :)

--
Alexander Limi · Firefox User Experience · http://limi.net

[Alexander Limi]

irc.mozilla.org, #fx-team. :)

--
Alexander Limi · Firefox User Experience · http://limi.net

On Tue, Nov 10, 2009 at 1:39 PM, Chris Latko <ch...@latko.org> wrote:

> I looked into it and it was a bit more complicated than shimming it in the
> right place. The installer is using three large frameworks so I would have
> to go in and handpick what I need to reduce the size of the whole thing. I
> can dedicate this entire weekend to getting it working. What is the proper
> IRC channel to ask related questions on?
>
> Thanks.
>
> Chris

>
>
> On Nov 10, 2009, at 4:23 PM, Alexander Limi wrote:
>
> > Hi Christian & Chris,
> >
> > We're in the process of ramping up for Firefox 3.7, and one of the things
> we're considering landing is an improved Firefox 3.7 installer for the Mac.
> >
> > Did any of you make any progress on this so far? :)
> >
> > --
> > Alexander Limi · Firefox User Experience · http://limi.net
> >
> >
> >
> > On Thu, Sep 24, 2009 at 12:39 PM, Christian <lind...@gmail.com> wrote:

> > _______________________________________________
> > dev-apps-firefox mailing list
> > dev-apps...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-apps-firefox
> >
>

> --
> Chris Latko
> www.latko.org
> @clatko
>
>
>
>