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?
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.
> 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.
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.
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.
> On 24.09.09 07:27, Mike Beltzner wrote: >> 100% Cocoa is fine, I think, as this is the OSX-only installer.
> 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)
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.
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...
On Sep 24, 12:42 am, Christian <linde...@gmail.com> wrote:
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
On 2009-09-24, at 3:25 PM, Chris Latko <ch...@latko.org> wrote:
> 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...
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
On Sep 24, 2:24 pm, Chris Latko <ch...@latko.org> wrote:
> 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...
> 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...
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.
On Thu, Sep 24, 2009 at 12: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.
> -Christian
> On Sep 24, 2:24 pm, Chris Latko <ch...@latko.org> wrote: > > 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...
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 <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.
> > -Christian
> > On Sep 24, 2:24 pm, Chris Latko <ch...@latko.org> wrote: > > > 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...
|
