http://wiki.caminobrowser.org/api.php?action=feedcontributions&user=Clawson&feedformat=atomCamino Wiki - User contributions [en]2024-03-29T06:07:26ZUser contributionsMediaWiki 1.34.4http://wiki.caminobrowser.org/index.php?title=Development:Building:Mozilla_1.9.2_Branch&diff=12080Development:Building:Mozilla 1.9.2 Branch2012-02-11T19:52:10Z<p>Clawson: /* Installing Mercurial */ looks like MacPorts has fixed those checksums</p>
<hr />
<div><div class="toclimit-2"><br />
<div style="margin: 0; padding:0 .5em; border:1px solid pink; background:#FFE8E8;"><br />
If you have comments or suggestions, please add them to the [[Talk:Development:Building|Discussion]] page.<br />
<br />
</div><br />
<br />
<br />
<div class="note"><br />
<p><strong>The purpose of this page is to guide you through building and running Camino®. Camino is a stand-alone web browser powered by the Gecko rendering engine. It shouldn't be confused with <!--Cocoazilla (a separate project to implement the full Mozilla suite using Cocoa), or -->CHBrowserView, which is just one piece of Camino. If you are new to Camino development, please see our [http://www.caminobrowser.org/development/ developer introduction] for an overview of project conventions and the tools you'll need.</strong></p> <!-- change that link to wiki's contrib overview when that is suitably complete --><br />
</div><br />
<br />
<p>These instructions assume that you are familiar with basic UNIX command-line functionality, such as <code>cd</code> and <code>mkdir</code>. For an introduction to the UNIX command line, please see this [http://www.macobserver.com/tips/macosxcl101/index.html tutorial].</p><br />
<br />
==Preparing to Build: Tools== <br />
<p>Mac OS X 10.4.11 and Xcode 2.4.1 or later are now required for building Camino (Xcode 2.5 on Mac OS X 10.4.11 or Xcode 3 on Mac OS X 10.5.8 are recommended; on Mac OS X 10.5, the MacPorts package system that can be used to install certain build dependencies—see below—requires Xcode 3.1). Xcode is included on a separate disk with the purchase of a new Mac, and the latest version is always available as a free download from [http://developer.apple.com/ Apple Developer Connection].</p><br />
<br />
''Note that Gecko 1.9.2 (and thus Camino) does not yet build “out-of-the-box” on Mac OS X 10.6. At appropriate places in this guide, you will be referred to supplemental information in [[Development:Building:Mac OS X 10.6]], which describes local changes you must make in order to build successfully on Mac OS X 10.6. ({{bug|514495}} is tracking the ability to build out-of-the-box on Mac OS X 10.6.) <!--For more information about local changes required to build on Mac OS X 10.6, see {{bug|514495}}-->.''<br />
<br />
In addition to disk space required by developer tools and build prerequisites, you will need approximately 2 GB of free disk space for a single debug tree (a Universal build requires approximately 50% more free space).<br />
<br />
===Installing Mac OS X Cross Development SDKs===<br />
Camino requires a custom Xcode installation to build properly: during installation, turn on the “Mac OS X 10.4 SDK” option (in older versions of Xcode, you may have to click the “Customize” button and turn on the “UNIX Development” and “Mac OS X 10.4 SDK” options—the latter is part of the “Cross Development” section in even older Xcode versions). If you have previously installed Xcode without these options, run the installer again to add Cross Development before attempting to build Camino. Current versions of Camino require the 10.4u SDK for PPC, Intel, and Universal builds. If you are building older versions of Camino, other SDKs are required; see the [[#Appendix|Appendix]] for details.<br />
<br />
Regardless of which version of Mac OS X you are using, we recommend you always upgrade to the latest "point" release of the OS (e.g., Mac OS X 10.4.11, Mac OS X 10.5.8, and Mac OS X 10.6.4 as of June 2010) and the latest Xcode version available for that version of Mac OS X (Xcode 2.5 on 10.4.11, Xcode 3.1.4 on 10.5.8, Xcode 3.2 on 10.6.4; previous versions of Xcode are available from http://developer.apple.com/resources/, "Developer Downloads", "Developer Tools" and then search for "Xcode").<br />
<br />
=== Upgrading Xcode===<br />
When you upgrade to a newer version of Xcode, even a minor-point release, be sure to '''re-install the Cross Development SDKs''' from the new version. In addition, '''delete the Xcode header cache''' in <code>/Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders</code> (where <code>501</code> is your user ID) or <code>$TMPDIR/../-Caches-/com.apple.Xcode.501</code> before building Camino. Xcode 3.1 and higher have an “Empty Caches…” menu item in the Xcode menu that will perform this step.<br />
<br />
===Installing <code>libIDL</code> and <code>autoconf-2.13</code>===<br />
<br />
Mozilla requires <code>libIDL</code> and <code>autoconf-2.13</code> in order to build (the version of <code>autoconf</code> shipped with Xcode will not work; '''you must install <code>autoconf-2.13</code>'''). While you can build these packages (and their dependencies) from source yourself, most developers use [http://www.macports.org/ MacPorts]. MacPorts is easier to use and is recommended. When installing a new major version of Mac OS X, be sure to upgrade MacPorts to the version appropriate for that Mac OS X version.<br />
<br />
# Download the [http://www.macports.org/install.php#pkg latest MacPorts release] for your version of Mac OS X and install it.<br />
#: MacPorts installs in <code>/opt/local</code> by default. After running the MacPorts installer, the changes that it makes to the shell environment will be available in any new Terminal window.<br />
# Open a '''new Terminal window''' and install the ports ('''N.B.''' you will need to use an Administrator account or your account must be listed in the <code>sudoers</code> file)<br />
## <code>$ sudo port install libidl +universal</code><br />
##: This will take some time as the sources for <code>libIDL</code> and its dependencies are downloaded and installed. If you are on Mac OS X 10.6 and already have some ports installed, see [[#Installing libIDL in an existing MacPorts installation on Mac OS X 10.6|below]] for additional steps that are required. (The <code>+universal</code> flag is not necessary on Mac OS X 10.4 or 10.5.)<br />
## <code>$ sudo port install autoconf213 +universal</code><br />
##: The above command installs autoconf-2.13 to <code>/opt/local/bin/autoconf213</code> using MacPorts. You will need to type <code>autoconf213</code> to run it when other documentation might instruct you to run <code>autoconf</code>. '''Do not install the autoconf package without the 213 suffix.'''<br />
<br />
The <code>+universal</code> flag is not necessary on Mac OS X 10.4 or 10.5, but it is required on Mac OS X 10.6. If you try to build Gecko and Camino on 10.6 without installing <code>libIDL</code> using the <code>+universal</code> flag, you will need to <code>make -f client.mk distclean</code> before building again.<br />
<br />
====Installing <code>libIDL</code> in an existing MacPorts installation on Mac OS X 10.6====<br />
MacPorts on 10.6 is unable to install <code>libIDL</code> with the <code>+universal</code> flag if you have already installed any of <code>libIDL</code>’s dependencies without the <code>+universal</code> flag; this is reported to be a MacPorts bug.<br />
<br />
According to internet sources, you should be able to use <code>sudo port upgrade --enforce-variants libidl +universal</code> to force MacPorts to upgrade all of <code>libIDL</code>’s dependencies to the <code>+universal</code> variant; you should then be able to install a <code>+universal</code> MacPorts. (As a last resort, try the MacPorts [http://trac.macports.org/wiki/Migration migration steps], or remove MacPorts and reinstall from scratch.)<br />
<br />
===Installing Mercurial===<br />
<br />
Current Mozilla development uses Mercurial (“hg”) for version control. Unlike common version-control systems (CVS, svn), Mercurial is not included as part of the Mac OS X Developer Tools.<br />
<br />
Mercurial has binary packages available for [http://mercurial.selenic.com/downloads/ Mac OS X 10.5 and 10.6], or you can install it via MacPorts. <strike>''As of August 2010, Mercurial in MacPorts fails to install on Mac OS X 10.6 due to bad checksums for patches in python dependencies; use the Mercurial binary package instead.''</strike> [Looks like this is fixed as of Feb 2012 --cl]<br />
<br />
To install Mercurial from MacPorts:<br />
* <code>$ sudo port install mercurial</code><br />
*: This will take some time as the sources for <code>mercurial</code> and its dependencies are downloaded and installed.<br />
*: '''N.B.''' The version of Mercurial from MacPorts will install Python 2.6; by default that version of Python will attempt to build all of X.org X11 for the Python IDE. You can avoid this extra compile time by first installing Python 2.6 with the <code>no_tkinter</code> variant and then installing Mercurial: <code>$ sudo port install python26 +no_tkinter; sudo port install mercurial</code><br />
<br />
===Selecting the Required Python Version on Mac OS X 10.4===<br />
<br />
The Gecko build system requires at least Python 2.4, but Mac OS X 10.4 ships with Python 2.3. If you use MacPorts to install Mercurial, it will install Python 2.6. You can then install <code>python_select</code> to make the MacPorts version the default Python version.<br />
<br />
<code>$ sudo port install python_select<br><br />
$ sudo python_select -s python26</code> &nbsp;(some MacPorts versions instead require <code>sudo python_select python26</code> )<br />
<br />
Unfortunately, the Gecko <code>configure</code> script may fail to detect the MacPorts Python and will still fail, claiming Python 2.4 or greater is not installed. If this happens, <code>configure</code> can be tricked by making a symlink of the MacPorts Python that points to a “Python binary filename” that <code>configure</code> looks for:<br />
<br />
<code>$ sudo ln /opt/local/bin/python /opt/local/bin/python2.5</code><br />
<br />
==Setting up your Hg Environment==<br />
''If you are building from the [ftp://ftp.mozilla.org/pub/mozilla.org/camino/source source tarball] and never plan to update your Camino source code except by downloading a new source tarball, you can skip this section. Most users should perform these steps, however, and '''if you are doing development, you should ''not'' use the tarball.''' (In particular, unlike a tarball from CVS, a tarball from Hg does not contain the metadata necessary to provide an updatable source tree.)''<br />
<br />
Mercurial configures itself via a hidden <code>.hgrc</code> file in your home folder. Create a new plain-text <code>~/.hgrc</code> file in your favorite text editor and populate it with the following:<br />
<br />
<pre>[ui]<br />
username = Your Name <email@domain.tld><br />
merge = internal:merge<br />
<br />
[defaults]<br />
commit = -v<br />
diff = -U 8 -p<br />
qdiff = -U 8<br />
<br />
[diff]<br />
git = 1<br />
showfunc = 1<br />
unified = 8</pre><br />
<br />
Mozilla’s Mercurial instructions exhort you to choose a [http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram merge program] now and to learn how to use it, without providing much useful guidance. The configuration above defaults to the traditional “try to merge and leave conflict markers” merging; if you have a favorite visual merge tool, configure it now, but otherwise you may want try various tools later on to see if such a tool exists for Mac OS X that doesn’t suck and doesn’t make you want to gouge your eyes out.<br />
<!--<br />
<p>For more information on Mozilla CVS, see [http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_Mercurial Mozilla Source Code Via Mercurial].</p><br />
--><br />
<br />
==Pulling Source and Building Gecko and Camino==<br />
'''''N.B.''' These instructions will build the “trunk” by default. If you want to build a specific branch (or a release or milestone from cvs rather than from the source tarball), please see the [[Development:Building:FAQ|FAQ]] for changes you will need to make to some of these commands.''<br />
<br />
''If you are building from the [ftp://ftp.mozilla.org/pub/mozilla.org/camino/source source tarball], skip to step 5 of this section. Be sure to follow the link to learn about other .mozconfig settings, since the sample is for a development build. '' <br />
<br />
Before beginning to pull the source (or unpack the tarball), '''open a new Terminal window (or tab)'''; this is necessary because MacPorts updates your <code>PATH</code> and the new <code>PATH</code> (and newly-installed programs in directories in the new <code>PATH</code>) aren’t available to the existing Terminal windows (or tabs).<br />
<br />
<ol><br />
<li><code>cd</code> into the directory where you would like to keep your copy of the Camino source code (e.g., <code>cd ~/lizard</code>).</li><br />
<li>Pull the Gecko source:<br /><br />
<code>$ hg clone http://hg.mozilla.org/releases/mozilla-1.9.2/ mozilla</code><br /><br />
This will download hundreds of megabytes to your computer and will take anywhere from '''20 minutes to an hour''' to complete.<br>''(If you have a slow or flaky connection, you may want to use the [http://ftp.mozilla.org/pub/mozilla.org/firefox/bundles/ mozilla-1.9.2 Mercurial bundle] ([https://developer.mozilla.org/En/Developer_Guide/Source_Code/Mercurial#Bundles unpacking instructions]) to bootstrap your mozilla-1.9.2 clone.)''</li><br />
<li><code>cd</code> into the <code>mozilla</code> directory that was just created:<br /><br />
<code>$ cd mozilla</code></li><br />
<li>Pull the Camino source:<br /><br />
<code>$ hg clone http://hg.mozilla.org/camino/ camino</code><br /><br />
It is very important that you are in the <code>mozilla</code> directory when issuing this command. This will download the Camino source to the appropriate location and should take about 5-10 minutes.</li><br />
<li>In your <code>mozilla</code> directory, create a plain text file called <code>.mozconfig</code> (note the leading period). This file is where you will set up the options for your Camino build. For a development build add the following to your <code>.mozconfig</code> file (note the leading dot and space):<br /><br />
<br />
<pre>. $topsrcdir/camino/config/mozconfig<br />
ac_add_options --disable-optimize<br />
ac_add_options --enable-debug<br />
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../CaminoTrunk<br />
mk_add_options MOZ_MAKE_FLAGS=-j4</pre><br />
<br />
'''''N.B.''' If you are trying to build on Mac OS X 10.6, please refer to <!--{{bug|514495}}--> the [[Development:Building:Mac OS X 10.6#.mozconfig|.mozconfig]] section of the [[Development:Building:Mac OS X 10.6]] supplemental instructions for additional <code>.mozconfig</code> contents.<br />
<br />
(The MOZ_MAKE_FLAGS setting improves build speed, assuming you have a multi-processor or multi-core machine. For older machines, remove that line.)<br />
<br />
For examples of other builds types, or to learn more about the <code>.mozconfig</code> file, see the [[Development:Building:mozconfig|.mozconfig page]].<br />
</li><br />
<br />
<li>'''Mac OS X 10.6 only''' - Apply local patches:<br /><br />
On Mac OS X 10.6, you must apply several local patches to make your build succeed. The [[Development:Building:Mac OS X 10.6#Local Patches|Local Patches]] section of the [[Development:Building:Mac OS X 10.6]] supplemental instructions contains links to the required patches.</li><br />
<br />
<li>Build:<br /><br />
<code>$ make -f client.mk build</code><br /><br />
This will automatically Camino (including various components of Mozilla that Camino requires). The final Camino build ends up in <code>mozilla/dist</code> (or <code>$OBJDIR/dist</code>).</li><br />
<!--</ul>--><br />
</ol> <br />
<br />
<p>For more information on the build process, see [http://developer.mozilla.org/en/docs/Mac_OS_X_Build_Prerequisites Mac OS X Build Prerequisites] and [http://developer.mozilla.org/en/docs/Mac_OS_X_Universal_Binaries Mac OS X Universal Binaries] in the Mozilla Developer Center.</p><br />
<br />
<p>If your build fails, consult the [[Development:Building:FAQ|FAQ]] and [[Development:Building:Build Errors|Common Build Errors]] pages.</p><br />
<br />
==Development== <br />
<p>To work on Camino application code, open up the <code>Camino.xcodeproj</code> project (from the <code>camino</code> directory of your OBJDIR) in Xcode. You can edit code, build, and run from inside of Xcode. (You can, of course, use an editor of your choice and rebuild either from Xcode or from the command line.)</p><br />
<p>When building with Xcode, make sure your build settings match those in your <code>.mozconfig</code> file: from the &quot;Active Build Style&quot; item in the toolbar, choose &quot;Development&quot; for a debug build, or &quot;Deployment&quot; for an optimized build. If you do not match your settings to your <code>.mozconfig</code>, your build will fail.</p><br />
<br />
===Camino code===<br />
If you've changed code only within the <code>camino</code> directory, you can ''usually'' rebuild using Xcode. (Again, make sure your build settings match your <code>.mozconfig</code> file). <br />
<br />
====<code>.in</code> and generated files====<br />
However, if you’ve edited the source files for certain files that are generated during the build process (e.g., the <code>.in</code> files for <code>.strings</code> files, <code>all-camino.js</code>, or the <code>Makefile</code>) or any of the <code>embed.jar</code> overrides, you will need to rebuild using the command line: <code>cd $OBJDIR/camino; make</code><br />
<br />
===Mozilla code===<br />
Unlike Camino code, nearly all Mozilla code is build with Makefiles, so there are no project files to ease development integration, and as a consequence you must open files manually in Xcode or your favorite editor.<br />
<br />
====Setting up a Camino-specific <code>.hgignore</code> file for the Mozilla repository====<br />
If you plan to work on Mozilla code, you’ll want to add a repository-specific <code>.hgignore</code> file for the Mozilla repository, so that Camino files do not show up as unknown when running Mercurial commands in the Mozilla repository.<br />
<br />
To do this, edit the <code>mozilla/.hg/hgrc</code> file and add the following lines:<br />
<br />
<pre>[ui]<br />
ignore = ~/.hgignore-mozcamino</pre><br />
<br />
Then, in your favorite text editor, make a new plain-text file in your home directory named <code>.hgignore-mozcamino</code> with the following lines:<br />
<br />
<pre># Make mozilla-{central|1.9.2} ignore camino<br />
^camino</pre><br />
<br />
====Widget code====<br />
If you’ve edited the Cocoa widget code, you can <code>make</code> in <code>$OBJDIR/widget/src/cocoa</code> to rebuild the widget library with your changes and then copy the new version of the widget library into your build. <br />
<br />
The easiest way to get the new version of the library into Camino to test it is to use <code>cp</code> to copy it into the Camino application package (into <code>$OBJDIR/camino/build/Development/Camino.app/Contents/MacOS/components</code>). (This tactic does not work for static builds, which is why they are not recommended for development.) As an alternative, you can <code>make</code> in <code>$OBJDIR/camino</code> again.<br />
<br />
====Other changes====<br />
If you've changed anything outside the <code>camino</code> directory (aside from widget code &mdash; see above), you cannot build from inside Xcode, and will need to <code>make -f client.mk</code> from the <code>mozilla</code> directory (or <code>make</code> from the root of your OBJDIR, if you're using an OBJDIR as recommended by the sample development <code>.mozconfig</code> above).<br />
<br />
===Stopping or continuing on Xcode build errors===<br />
Depending on your preferences, you may want to set Xcode (and <code>xcodebuild</code>) to stop building when it hits a build error (rather than to spend time continuing to build the rest of Camino only to produce a broken executable) or to continue trying to build after errors (perhaps in order to maximize the number of errors you see in a given build attempt). In Xcode 3.1 and newer, this defaults to continuing to build past errors; in older versions of Xcode, the default was to stop on errors.<br />
<br />
To change this value, toggle the “Continue building after errors” checkbox in the “Build Options:” section of the “Building” pane of Xcode’s preferences (or, when Xcode is not running, use the command line <code>defaults write com.apple.Xcode PBXBuildsContinueAfterErrors -bool false</code>—or <code>true</code> to continue building—to set this preference).<br />
<br />
(Note that if you have a <code>-j</code> value set in your <code>.mozconfig</code>, <code>xcodebuild</code> may continue “building” for a short time after hitting an error as the additional tasks that were already running finish.)<br />
<br />
===Updating the source and rebuilding===<br />
Since the Mozilla core (Gecko) and Camino code are always under constant development, you will periodically want to update your source tree to stay current and to make sure your code will not conflict with any changes that have happened since you began working. (You will always want to make sure your tree is current before beginning work on the code and before submitting a patch for review.)<br />
<p>Before updating your tree, visit the [http://tinderbox.mozilla.org/showbuilds.cgi?tree=Camino Tinderbox] and make sure that the columns whose headings end in “Cm2.1-M1.9.2” <!--and “CmTrunk”--> are green <!--(these are the Camino trunk builds)-->. Then <code>cd</code> to your <code>mozilla</code> directory and run the following commands:<br /><br />
<code>$ hg pull -u</code><br /><br />
<code>$ cd camino</code><br /><br />
<code>$ hg pull -u</code><br /><br />
Then, to rebuild Gecko and Camino:<br /><br />
<code>$ cd ..</code><br /><br />
<code>$ make -f client.mk build</code><br /><br /><br />
<br />
It's possible in most cases to update only Camino code (unless Gecko changes have made changes to Camino code), but it is still recommended that you update your entire tree regularly. '''To update only the Camino code''', <code>cd</code> to your <code>mozilla/camino</code> directory and run the following commands:<br /><br />
<code>$ hg pull -u</code><br /><br />
<code>$ make</code><br /><br /><br />
For OBJDIR builds used by most developers, replace <code>make</code> with <code>cd ../../{OBJDIR}/camino; make</code> (the sample development <code>.mozconfig</code> above specifies an OBJDIR by default). Note that in OBJDIR builds, you '''must''' run <code>make</code> from the command line after a <code>hg pull -u</code> that pulls certain types of changes, including project changes and changes to any <code>.strings</code> file, since updated versions of these files are copied into the OBJDIR or regenerated by Makefile targets.</p><br />
<br />
===Packaging a build for testing===<br />
Sometimes you'll want to create a custom build to allow a large new feature to receive wider testing from the community before review or landing. In order to do this, you need to <strong>build with a [[Development:Building:mozconfig#Sample_.mozconfig|“distribution” <code>.mozconfig</code>]]</strong>. Then, when your build is complete, run <code>make</code> in <code>$OBJDIR/camino/installer</code> to produce a disk image for distribution. You can use your existing source tree but “swap in” a deployment <code>.mozconfig</code> that defines a new OBJDIR to provide a clean build.<br />
<!-- you do this just by "swapping" .mozconfigs and defining a new objdir --><br />
<br />
===Cleaning your tree===<br />
Sometimes your build will fail because there are stale build products somewhere in the tree and new ones that conflict, or for other reasons related to the state of your tree. This can be fixed by cleaning your tree. To clean your tree, <code>cd</code> to <code>mozilla</code> and try <code>make -f client.mk clean</code>. If that doesn't work, you need to <code>make -f client.mk distclean</code>.<br />
<br />
==Appendix==<br />
<br />
* [[Development:Building:FAQ|Build FAQ]]<br />
* [[Development:Building:Build Errors|Common Build Errors]]<br />
* [[Development:Building:mozconfig|.mozconfig Details]]<br />
* [[Development:Building:Common make Targets|Common <tt>make</tt> Targets]]<br />
* [[Development:Building:Mozilla 1.9.0 Branch|Building on the Mozilla 1.9.0 and Camino 2.0 branches]]<br />
* [[Development:Building:Mozilla 1.8.* Branches|Building on the Mozilla 1.8.* branches]] (Camino 1.6.x, Camino 1.5.x, Camino 1.0.x) ''(in progress)''<br />
* [[Development:Building:Building_Dependencies_from_Source|Building Dependencies from Source]] ''(in progress)''<br />
* [[Development:Providing Software Update for Third-Party Camino Builds|Providing Software Update for Third-Party Camino Builds]]<br />
<br />
</div><br />
<!-- closes the "toclimit-2" div that should wrap the entire page --></div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=User:Sardisson/User_Agent_User-Agent_Strings&diff=10719User:Sardisson/User Agent User-Agent Strings2010-01-07T05:39:38Z<p>Clawson: /* Strings to Delete */ keep NS 4.7.5 for now</p>
<hr />
<div>The list of user-agent strings in v1.0.1 of the User Agent preference pane is several years old. We need to spruce up this list for the end of the decade.<br />
<br />
==Current Strings==<br />
<br />
*Camino 1.0.3 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060911 Camino/1.0.3<br />
<br />
*Camino 1.0.3 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060911 Camino/1.0.3<br />
<br />
*Safari 2.0.4 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3<br />
<br />
*Safari 2.0.4 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3<br />
<br />
* Firefox 2.0 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0<br />
<br />
* Firefox 2.0 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0<br />
<br />
* Internet Explorer 5.23 PPC<br />
*: Mozilla/4.0 (compatible; MSIE 5.23; Mac_PowerPC)<br />
<br />
* Internet Explorer 6.0 WinXP<br />
*: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)<br />
<br />
* Internet Explorer 7.0 WinXP<br />
*: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)<br />
<br />
* Netscape 6.2 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4.1) Gecko/2002<br />
<br />
* Netscape 4.75 MacPPC<br />
*: Mozilla/4.75C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)<br />
<br />
* Opera 9.0.2 Intel<br />
*: Opera/9.02 (Macintosh; Intel Mac OS X; U; en)<br />
<br />
* Opera 9.0.2 WinXP<br />
*: Opera/9.02 (Windows NT 5.1; U; en)<br />
<br />
* OmniWeb 5.1.1 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/125.4 (KHTML, like Gecko, Safari) OmniWeb/v563.51<br />
<br />
* OmniWeb 5.5.1 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/420+ (KHTML, like Gecko, Safari/420) OmniWeb/v607.5<br />
<br />
==Strings to Delete==<br />
<br />
* Camino 1.0.3 (both)<br />
* Firefox 2.0 (both)<br />
* Safari 2.0.4 (both)<br />
* Opera 9.0.2 Intel<br />
* Opera 9.0.2 WinXP<br />
* Netscape 6.2 PPC<br />
* IE 5.23 PPC<br />
* IE 6 WinXP<br />
* OmniWeb 5.1.1<br />
* OmniWeb 5.5.1<br />
<br />
==Strings to Add==<br />
<br />
* Camino 1.6.10 (PPC + Intel)<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.23) Gecko/20090925 Camino/1.6.10 (like Firefox/2.0.0.23)<br />
* Camino 2.0.1 (PPC + Intel)<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.16) Gecko/2009120123 Camino/2.0.1 (like Firefox/3.0.16)<br />
* Firefox 2.0.0.20 (PPC + Intel)<br />
* Firefox 3.0.17 (PPC + Intel, plus XP/Vista)<br />
* Firefox 3.5.7 (PPC + Intel, plus XP/Vista)<br />
* Safari 4.0.2 (10.5 PPC, 10.6 Intel)<br />
* Opera 10.10 (Intel + XP)<br />
* IE 8<br />
* Google Chrome 4 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.30 Safari/532.5<br />
* OmniWeb 5.10.0 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/531.9+(KHTML, like Gecko, Safari/528.16) OmniWeb/v622.9.0<br />
* Netscape.last (whatever that is, Intel + XP is probably sufficient)</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=User:Sardisson/User_Agent_User-Agent_Strings&diff=10718User:Sardisson/User Agent User-Agent Strings2010-01-07T05:36:12Z<p>Clawson: /* Strings to Add */ add a few more</p>
<hr />
<div>The list of user-agent strings in v1.0.1 of the User Agent preference pane is several years old. We need to spruce up this list for the end of the decade.<br />
<br />
==Current Strings==<br />
<br />
*Camino 1.0.3 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060911 Camino/1.0.3<br />
<br />
*Camino 1.0.3 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060911 Camino/1.0.3<br />
<br />
*Safari 2.0.4 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3<br />
<br />
*Safari 2.0.4 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3<br />
<br />
* Firefox 2.0 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0<br />
<br />
* Firefox 2.0 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0<br />
<br />
* Internet Explorer 5.23 PPC<br />
*: Mozilla/4.0 (compatible; MSIE 5.23; Mac_PowerPC)<br />
<br />
* Internet Explorer 6.0 WinXP<br />
*: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)<br />
<br />
* Internet Explorer 7.0 WinXP<br />
*: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)<br />
<br />
* Netscape 6.2 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4.1) Gecko/2002<br />
<br />
* Netscape 4.75 MacPPC<br />
*: Mozilla/4.75C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)<br />
<br />
* Opera 9.0.2 Intel<br />
*: Opera/9.02 (Macintosh; Intel Mac OS X; U; en)<br />
<br />
* Opera 9.0.2 WinXP<br />
*: Opera/9.02 (Windows NT 5.1; U; en)<br />
<br />
* OmniWeb 5.1.1 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/125.4 (KHTML, like Gecko, Safari) OmniWeb/v563.51<br />
<br />
* OmniWeb 5.5.1 PPC<br />
*: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/420+ (KHTML, like Gecko, Safari/420) OmniWeb/v607.5<br />
<br />
==Strings to Delete==<br />
<br />
* Camino 1.0.3 (both)<br />
* Firefox 2.0 (both)<br />
* Safari 2.0.4 (both)<br />
* Opera 9.0.2 Intel<br />
* Opera 9.0.2 WinXP<br />
* Netscape 6.2 PPC<br />
* Netscape 4.7.5 MacPPC<br />
* IE 5.23 PPC<br />
* IE 6 WinXP<br />
* OmniWeb 5.1.1<br />
* OmniWeb 5.5.1<br />
<br />
==Strings to Add==<br />
<br />
* Camino 1.6.10 (PPC + Intel)<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.23) Gecko/20090925 Camino/1.6.10 (like Firefox/2.0.0.23)<br />
* Camino 2.0.1 (PPC + Intel)<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.16) Gecko/2009120123 Camino/2.0.1 (like Firefox/3.0.16)<br />
* Firefox 2.0.0.20 (PPC + Intel)<br />
* Firefox 3.0.17 (PPC + Intel, plus XP/Vista)<br />
* Firefox 3.5.7 (PPC + Intel, plus XP/Vista)<br />
* Safari 4.0.2 (10.5 PPC, 10.6 Intel)<br />
* Opera 10.10 (Intel + XP)<br />
* IE 8<br />
* Google Chrome 4 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.30 Safari/532.5<br />
* OmniWeb 5.10.0 Intel<br />
*: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/531.9+(KHTML, like Gecko, Safari/528.16) OmniWeb/v622.9.0<br />
* Netscape.last (whatever that is, Intel + XP is probably sufficient)</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2009-11-18:Agenda&diff=10650Status Meetings:2009-11-18:Agenda2009-11-18T17:16:08Z<p>Clawson: /* General Plans */ add Gecko 1.9.1? to 2.1 section</p>
<hr />
<div>Wed 18 November 9am PST (17:00 GMT/UTC) in #camino-mtg<br />
<br />
==General Plans==<br />
* Camino 2.0rc<br />
** Pushed to SWUpdate 3 weeks ago Tues afternoon<br />
** Currently targeting end-of-meeting release<br />
** [[Releases:2.0:l10n|l10n status]] - green is good, pink is bad<br />
*** looking for 13 + 1 for 2.0.1; 3 from 1.6.x missing entirely (pt, cs, ca)<br />
** Website<br />
*** Docs changes done; everything else done except privacy policy ({{bug|522978}}); Sam applying redesign and fixing redesign-related pages (Home, Features)<br />
** [http://crash-stats.mozilla.com/topcrasher/byversion/Camino/2.0 Breakpad] topcrash report for the last 2 weeks - 238 (a bit below average) - '''NEW''' [http://crash-stats.mozilla.com/topcrasher/byurl/Camino/2.0 topcrashers by URL]<br />
*** #1 <!--71--> is various Flash-related crashes (30%)<br />
*** #2 <!--44--> is {{BPsig|2.0|MacOSFontEntry::GetFontID}} - {{bug|514114}} (18%) - big jump with 10.6.2; jdaggett checked in a probable fix Tues<br />
*** #3 <!--5--> is {{BPsig|2.0|CFRelease}} / {{BPsig|2.0|objc_msgSend%20%7c%20TFSInfo::~TFSInfo}} (10.6.1 unfixed version of {{bug|514921}}?) (2%) - appears fixed by 10.6.2<br />
*** #4 <!--4--> is {{BPsig|2.0|objc_msgSend%20%7c%20nsNativeThemeCocoa::DrawPushButton}} (GoogleDesktop) (2%)<br />
*** #5 <!--4--> is {{BPsig|2.0|objc_msgSend%20%7c%20-%5bNSWindow%20sendEvent:%5d}} (unknown bug)<br />
<!--*** #4 <!- -4- -> is {{BPsig|2.0|JS_CallTracer}}<br />
*** #4 <!- -4- -> is {{BPsig|2.0|CFQSortArray}} (related to appshell/runloop)<br />
*** #5 <!- -7- -> is {{BPsig|2.0|objc_msgSend%20%7c%20-%5bNSApplication%20sendEvent:%5d}} (unknown bug)<br />
*** #5 <!- -7- -> is {{BPsig|2.0|-%5bNSWindow%20sendEvent:%5d}} with swizzling / {{BPsig|2.0|-%5bNSWindow(MethodSwizzling)%20nsCocoaWindow_NSWindow_sendEvent:%5d}} --><br />
*** Crashes we expected to be fixed have indeed vanished<br />
*** Mostly lots of misc signatures<br />
* Camino 1.6.10<br />
** Released seven weeks ago Tuesday<br />
** [http://talkback-public.mozilla.org/reports/camino/CM1610/index.html Talkback] needs ss to set up report ([http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=&vendor=MozillaOrg&product=Camino16&platform=MacOSX&buildid=2009092522&sdate=&stime=&edate=&etime=&sortby=stack&rlimit=0 all 1.6.10 crashes]) — '''1750''' so far, ~ +198 last week<!-- --> [still below average] <br />
*** #1 Flash is 25% of all 1.6.10 crashes so far (down from 1.6.9's 28% peak)<br />
*** #2 {{TBsig|16|2009092522|libobjc}} - mostly plug-ins<br />
*** #3 {{TBsig|16|2009092522|CoreFoundation}} <br />
*** #4 {{TBsig|16|2009092522|0xfffeff20}}<br />
*** #5 {{TBsig|16|2009092522|libSystem.B}} - Flip4Mac, Real, Silverlight, DivX, SiteIconCache<br />
<!--*** #5 {{TBsig|16|2009092522|0xfffeff18}}<br />
*** #5 {{TBsig|16|2009092522|nsPluginInstanceOwner::GetDocument}}<br />
*** #3 {{TBsig|16|2009092522|AppKit}} on 10.3.9--><br />
* [[Releases:1.6.11:Links|Camino 1.6.11]]<br />
** Cookie exceptions fix and exceptions when viewing cookie list fix landed, plus CNN ad-blocking<br />
** Several nominations; {{bug|520424}} (crash on form submit) and 10.6 Help search field would need patches<br />
* Camino 2.0.1<br />
** 9 nominations already<br />
** Widget drawing 1.9.0-patch landed last week<br />
** 10.6 Help search field<br />
** netError - one more crazy possibility, but not likely<br />
* [[Development:Planning:Camino 2.1|Camino 2.1]]<br />
** !seen dan<br />
** Start thinking about other features; added a few things that came to mind<br />
** CBSamplePane - awaiting reviews<br />
** Downloads prefPane icon and other icon tweaks<br />
** Fixing minor bugs here and there<br />
** Gecko 1.9.1?<br />
* Tinderboxen<br />
** cb-xserve04<br />
*** ~8min Depend builds, 29min Clobbers, currently running 2.0 and 2.1, Ts, uploading “hourlies”<br />
** boxset<br />
*** offline (again) due to power outage at Sam's<br />
*** missing from tinderbox yet again {{bug|479999}}<br />
*** were tracking Tp regression due to NSPR upgrade {{bug|465212}} - need ss did a backout for wtc, confirmed the cause, but the new code is correct, so regression will probably stay; new test to try for bz<br />
** cb-minibinus01 switched over to boxset-like config to be a temporary replacement; running Ts and Tdhtml<br />
*** would like to get Tp working before switching back to normal config (need more static/PPC coverage)<br />
** What should we do with cb-minimaya01? Needs HD repair<br />
** cb-miniosx01 has Ts disabled due to paging/low installed RAM<br />
* Weekly Bugs and Queues update<br />
** Very slow since 2.0 freeze; hendy's patch needs a reviewer<br />
<br />
==Specific bugs that need action==<br />
<br />
* None<br />
<br />
===Other (if there's time)===<br />
<br />
* 10.5 Visual UX<br />
** App icon lines - {{bug|402967}}<br />
* UNCOs<br />
** {{Bug|467851}} - Floating Tab Previews<br />
** {{Bug|468262}} - Use grabbed hand cursor during tab dragging<br />
** {{Bug|458427}} - Data detectors for dates/times for iCal integration<br />
** {{Bug|404515}} - Found items (as result of Find command) are hard to distinguish in the page<br />
** {{Bug|391684}} - AppleScript: Closing browser window w/ multiple tabs prompts user<br />
** {{Bug|386574}} - Close tab too close to favicon causing drag'n'drop problems<br />
** {{Bug|286280}} - provide mechanism for resizing <select> lists<br />
** {{Bug|386574}} - Close tab too close to favicon causing drag'n'drop problems (specifically, does Stuart have any further commentary on the first part of comment 4?)<br />
** {{Bug|381295}} - Change tab scroll-to-view behavior to provide context<br />
<br />
==Queries==<br />
<br />
===Camino 2.0===<br />
Zarro Boogs!<br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino2.0&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs targeted at 2.0] (0) {{greyText|[-1 since last week]}} <!-- --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino2.0%3F Blocking ?] (0) {{greyText|[unchanged]}} <!-- (subtract FIXED here, except when only FIXED on trunk --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino2.0%2B Blocking +] (0) {{greyText|[-1 since last week]}} <!-- subtract FIXED here--><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino2.0- Blocking -] (7) {{greyText|[unchanged<!---1 since last week-->]}} <br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=---&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs without target] (694) {{greyText|['''+1''' since last week]}}''' need <!--to keep on top-->another round of “CLOSEME”/UNCO'''<br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&resolution=FIXED&resolution=---&chfieldfrom=2009-11-11&chfieldto=2009-11-18&chfield=resolution&chfieldvalue=FIXED Bugs fixed since last meeting] ('''1''') {{greyText|[unchanged]}} ('''1''' were 2.0-targeted [cert]<!--; 4 were website-for-2.0 & meta, 3 were possible 2.0.1 changes, 1 other; 2 were ad-blocking, 2 were website-->)<br />
<br />
==Queues==<br />
<br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (6) {{greyText|[+1 since last week]}} '''1 untargeted'''<!-- --><br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] ('''2''') {{greyText|[unchanged]}}</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=User:Clawson&diff=10640User:Clawson2009-11-17T07:08:11Z<p>Clawson: fix bugmail addy</p>
<hr />
<div>* cl (usually) on #camino<br />
* cflawson on the fora<br />
* cl-bugs in [https://bugzilla.mozilla.org/ bugzilla] (the actual address changes from time to time, but putting "cl-bugs" in the CC field will find me)<br />
<br />
Need any other info? Tough.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2009-06-17:Agenda&diff=10008Status Meetings:2009-06-17:Agenda2009-06-08T04:42:44Z<p>Clawson: one more</p>
<hr />
<div>* {{Bug|467851}} - Floating Tab Previews<br />
* {{Bug|468262}} - Use grabbed hand cursor during tab dragging<br />
* {{Bug|458427}} - Data detectors for dates/times for iCal integration<br />
* {{Bug|430481}} - Remove spurious legal claim from 1.6 download page<br />
* {{Bug|404515}} - Found items (as result of Find command) are hard to distinguish in the page<br />
* {{Bug|405722}} - Consider supporting some subset of Firefox's Private Data prefs<br />
* {{Bug|391684}} - AppleScript: Closing browser window w/ multiple tabs prompts user<br />
* {{Bug|386574}} - Close tab too close to favicon causing drag'n'drop problems<br />
* {{Bug|286280}} - provide mechanism for resizing <select> lists<br />
* {{Bug|386574}} - Close tab too close to favicon causing drag'n'drop problems (specifically, does Stuart have any further commentary on the first part of comment 4?)<br />
* {{Bug|381295}} - Change tab scroll-to-view behavior to provide context</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2009-06-17:Agenda&diff=10007Status Meetings:2009-06-17:Agenda2009-06-08T04:40:38Z<p>Clawson: more bugs we need to discuss</p>
<hr />
<div>* {{Bug|467851}} - Floating Tab Previews<br />
* {{Bug|468262}} - Use grabbed hand cursor during tab dragging<br />
* {{Bug|458427}} - Data detectors for dates/times for iCal integration<br />
* {{Bug|430481}} - Remove spurious legal claim from 1.6 download page<br />
* {{Bug|404515}} - Found items (as result of Find command) are hard to distinguish in the page<br />
* {{Bug|405722}} - Consider supporting some subset of Firefox's Private Data prefs<br />
* {{Bug|391684}} - AppleScript: Closing browser window w/ multiple tabs prompts user<br />
* {{Bug|386574}} - Close tab too close to favicon causing drag'n'drop problems<br />
* {{Bug|286280}} - provide mechanism for resizing <select> lists<br />
* {{Bug|386574}} - Close tab too close to favicon causing drag'n'drop problems (specifically, does Stuart have any further commentary on the first part of comment 4?)</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2009-06-17:Agenda&diff=10006Status Meetings:2009-06-17:Agenda2009-06-08T04:32:00Z<p>Clawson: more bugs we need to discuss</p>
<hr />
<div>* {{Bug|467851}} - Floating Tab Previews<br />
* {{Bug|468262}} - Use grabbed hand cursor during tab dragging<br />
* {{Bug|458427}} - Data detectors for dates/times for iCal integration<br />
* {{Bug|430481}} - Remove spurious legal claim from 1.6 download page<br />
* {{Bug|404515}} - Found items (as result of Find command) are hard to distinguish in the page<br />
* {{Bug|405722}} - Consider supporting some subset of Firefox's Private Data prefs</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2009-06-17:Agenda&diff=10005Status Meetings:2009-06-17:Agenda2009-06-08T04:13:08Z<p>Clawson: add a couple bugs we need to discuss</p>
<hr />
<div>* {{Bug|467851}} - Floating Tab Previews<br />
* {{Bug|468262}} - Use grabbed hand cursor during tab dragging</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-10-29:Agenda&diff=9408Status Meetings:2008-10-29:Agenda2008-10-28T15:43:10Z<p>Clawson: add bug 409679</p>
<hr />
<div>{{bug|409679}} - Option-return in location bar doesn't work without scheme://</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=9368Development:Third-Party Preference Panes2008-10-03T01:54:56Z<p>Clawson: /* Working with Gecko preferences */ <code>-ify code examples</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
For more on avoiding naming conflicts and the potential consequences of such conflicts, see [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/Conflicts.html Apple's "Preventing Name Conflicts" documentation].<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Working with Gecko preferences==<br />
<br />
There are a number of points to keep in mind when dealing with the Gecko preferences (as opposed to Apple's NSUserDefaults) system. First and foremost, it's easy for preferences UI to get out of sync with reality, since there are a number of Gecko preferences that have UI in multiple locations within Camino.<br />
<br />
For example, there are at least three places to edit the <code>security.warn_viewing_mixed</code> preference in Camino:<br />
<br />
* the Security preference pane;<br />
* the warning sheet that comes up when entering a secure page containing insecure elements; and<br />
* <code>about:config</code>.<br />
<br />
If your preference pane will edit preferences that can be changed outside the Preferences window, you should read {{Bug|358318}}, {{Bug|373158}}, and {{Bug|411189}} (and possibly {{Bug|371266}} as well) and ensure you have a thorough understanding of the underlying issues behind them. The sample preference pane provided above has comments in the code that should help you to avoid the pref synchronization bugs we've encountered over the course of Camino development.<br />
<br />
Some preferences require further action to toggle on or off than <code>about:config</code> by itself is capable of performing. Again, as an example, both Flashblock and Camino's built-in ad-blocking need to (re)load a stylesheet in order to take effect. You should expect advanced users to know about and use <code>about:config</code>, so if your preference pane will deal with preferences like this, you should use the Camino PreferenceManager's <code>-addObserver:forPref:</code> method to trigger notifications when the preferences change in <code>about:config</code>. (Don't forget to <code>-removeObserver:forPref:</code> when you're done!) {{Bug|384689}} contains a real-world example of how to use this code.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=9367Development:Third-Party Preference Panes2008-10-03T01:52:57Z<p>Clawson: add notes on pref observer code</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
For more on avoiding naming conflicts and the potential consequences of such conflicts, see [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/Conflicts.html Apple's "Preventing Name Conflicts" documentation].<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Working with Gecko preferences==<br />
<br />
There are a number of points to keep in mind when dealing with the Gecko preferences (as opposed to Apple's NSUserDefaults) system. First and foremost, it's easy for preferences UI to get out of sync with reality, since there are a number of Gecko preferences that have UI in multiple locations within Camino.<br />
<br />
For example, there are at least three places to edit the <code>security.warn_viewing_mixed</code> preference in Camino:<br />
<br />
* the Security preference pane;<br />
* the warning sheet that comes up when entering a secure page containing insecure elements; and<br />
* <code>about:config</code>.<br />
<br />
If your preference pane will edit preferences that can be changed outside the Preferences window, you should read {{Bug|358318}}, {{Bug|373158}}, and {{Bug|411189}} (and possibly {{Bug|371266}} as well) and ensure you have a thorough understanding of the underlying issues behind them. The sample preference pane provided above has comments in the code that should help you to avoid the pref synchronization bugs we've encountered over the course of Camino development.<br />
<br />
Some preferences require further action to toggle on or off than <code>about:config</code> by itself is capable of performing. Again, as an example, both Flashblock and Camino's built-in ad-blocking need to (re)load a stylesheet in order to take effect. You should expect advanced users to know about and use <code>about:config</code>, so if your preference pane will deal with preferences like this, you should use the Camino PreferenceManager's -addObserver:forPref: method to trigger notifications when the preferences change in <code>about:config</code>. (Don't forget to -removeObserver:forPref: when you're done!) {{Bug|384689}} contains a real-world example of how to use this code.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Reviewing&diff=9361Development:Reviewing2008-09-29T01:56:45Z<p>Clawson: /* Adding new files in a patch */ make it clear that cvsdo needs to be installed, not part of Mac OS X (or cvs) by default</p>
<hr />
<div>Patch review in the Camino Project works a bit differently than in the rest of the Mozilla project. This document outlines the review process in Camino and whom to ask for reviews.<br />
<br />
== How Many Reviews? ==<br />
Typically, Camino requires three reviews on a patch before it is committed to the cvs repository: two normal reviews and one super-review. This rule can be overridden by any of the super-reviewers (and a second review is not typically required for trivial changes). The reason Camino requires two normal reviews is for greater visibility and to give reviewers a better understanding of more code.<br />
<br />
== Requesting Review ==<br />
When requesting review, always request an initial review from one of the reviewers listed [[#Reviewers and Owners|below]] and then, '''*after*''' (and only after) receiving <tt>review+</tt> from two of them, request super-review from one of the super-reviewers.<br />
<br />
It's a good idea to "target" a specific reviewer or super-reviewer; patches set to <tt>review?</tt> or <tt>superreview?</tt> with no email address entered in the corresponding '''Requestee:''' box tend to get lost. Check the list [[#Reviewers and Owners|below]] to see which reviewer(s) have expertise in the area(s) your patch touches; you will often get a review more quickly that way. You can also check [bonsai's cvs log] for the file(s) you're hacking and [bonsai's cvs blame] for the lines of code you're changing to see which reviewers have hacked or reviewed that code before.<br />
<br />
Also check the queue ([https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&requestee=&component=&group=type reviews], [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&requestee=&component=&group=type super-reviews]) to see which reviewers are "backed up" before requesting review or super-review; you might also ask on [irc://irc.mozilla.org#camino irc] if the reviewer can do a review/super-review first. If you are unsure of whom to ask or have other questions, please ask on [irc://irc.mozilla.org#camino #camino] on irc.<br />
<br />
Make sure your patch applies, builds, and works on the current trunk before requesting reviews (all development should be done on the trunk and backported to the branches if applicable). For patches which will land on one or more branches, verify that the Mac OS X and/or Gecko functions you use are available.<br />
:For instance, while the trunk supports only Mac OS X 10.4 and above (and requires the 10.4u SDK and gcc 4.0.1), the MOZILLA_1_8_BRANCH (Camino 1.6.x) must support Mac OS X 10.3.9 and above. '''Patches that are designed to land on the MOZILLA_1_8_BRANCH (for security releases) and must use Mac OS X functions that are available in the 10.3.9 SDK<!-- and must compile with gcc 3.3-->.''' Similarly, many Gecko functions available on the trunk are either greatly enhanced over their counterparts on the MOZILLA_1_8_BRANCH, and many Gecko functions on the trunk do not exist at all on the MOZILLA_1_8_BRANCH. <br />
In any case where a patch is intended for landing on the trunk and the branch(es), you should ensure that the trunk patch will both apply properly and work on the branch(es); if not, you need to supply branch version(s) of the patch.<br />
<br />
To request review, set the '''review''' drop-down menu for your patch to '''?''' and then fill in the reviewer's email address in the '''Requestee''' field (you can do this when attaching your patch, or afterwards by clicking on the '''Edit''' link next to your patch in the bug's attachment table).<br />
<br />
Review is typically a process rather than a single event; reviewers will often request changes to your patch before they will approve it (by setting the '''?''' flag to '''+'''). A patch that does not meet with the reviewer’s approval will have its flag set to '''-''', and the reviewer will provide a list of problems or changes in the bug’s comments. A patch receiving <tt>review-</tt> is common, especially when you are just getting started with Camino. Make the changes the reviewer has requested, post a new patch, and request review again. Soon your patch will be ready for super-review and check-in to the repository.<br />
<br />
On occasion the reviewer will set the the '''?''' flag to '''+''' but also leave a comment with changes that need to be made to the patch (usually these are minor changes). When this happens, the reviewer feels that it is not necessary for him to re-review the patch with the changes. Instead, make the changes and post a new patch (obsoleting the old patch via the checkbox on the add attachment page), and set the <tt>review</tt> flag on the new patch to '''+''' yourself, with a comment like “carrying over r+ from $reviewer”. Also set set any other flags (a second review) to their values from the previous version of the patch, or set the <tt>superreview?</tt> flag.<br />
<br />
=== Code style ===<br />
<br />
''Link to Mozilla coding style guidelines as well as create some for Camino, so we avoid {{bug|308942}} comment 8 and 14 and {{bug|228840}} comments 15, 16, 18, and 19.''<br />
<br />
*[http://www.mozilla.org/hacking/mozilla-style-guide.html Mozilla Coding Style Guide]<br />
*[http://www.mozilla.org/MPL/boilerplate-1.1/ License block for new files]<br />
<br />
''Also link to [http://www.mozilla.org/hacking/ Hacking Mozilla] general intro somewhere in our contributor introduction''<br />
<br />
All new code should conform to Camino's style guidelines, which is a descendent of the Mozilla style guidelines (per decree by our leader):<br />
<br />
<pre><br />
if (foo) {<br />
bar;<br />
blam;<br />
}<br />
else {<br />
baz;<br />
zap;<br />
}<br />
</pre><br />
<br />
Braces for single statements are optional (and discouraged, but some still include them).<br />
<br />
We explicitly have no style rule regarding the placement of <tt>*</tt>. Aim to be consistent within a file in as much as the files are consistent.<br />
<br />
=== Coding for latest-OS-version features or using private APIs ===<br />
<br />
Each situation is unique, but we have provided some existing examples of various strategies employed to correctly code for these situations.<br />
<br />
The spell-checker's <code>learnWord:</code> method is undocumented, but is the only way to achieve proper learned spelling for the OS X system dictionary. [http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#520 Example code here] and [http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#4472 here].<br />
<br />
Setting Spotlight metadata on files is also undocumented as of the 10.5 SDK. Our download listener code has [http://mxr.mozilla.org/mozilla/source/camino/src/download/nsDownloadListener.mm#652 a very well-documented and commented example] of how to use a method like this safely.<br />
<br />
Setting Mac OS X proxy preferences is available only in the 10.4u SDK and later, although the feature is available at least as far back as Mac OS X 10.3.2. PreferenceManager.mm implements this feature safely across all versions Camino supports; see [http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/camino/src/preferences/PreferenceManager.mm&rev=1.88&mark=81-94#78 here].<br />
<br />
''spellcheck learn/add word, wherefrom metadata, quarantine extended metadata, what else?''<br />
<br />
====Situation====<br />
Description and mxr link<br />
<br />
=== Proper patch format ===<br />
<br />
Use <tt>cvs diff -u8N</tt> for patches to Camino code. Diffs should be done from <tt>/mozilla/camino</tt> or <tt>/mozilla</tt> for consistency and ease of application by reviewers and committers. All changes—including new source code files and project file changes, if applicable—should be submitted as a single patch (''e.g.'', <tt>cvs diff -u8N src/foo/bar src/baz/bam</tt>, with the exception of changes to <tt>.strings</tt> files, nibs, and images; see below for more about requirements for those three file types.<br />
<br />
====Adding new files in a patch====<br />
Sometimes the code you are writing requires the creation of new source files. In order to allow these files to be included in your single patch file, you must perform the additional step of <tt>cvs add</tt>ing the file, or, if you do not have cvs write privileges, of imitating the <tt>cvs add</tt> process.<br />
<br />
To make a patch including a new file (which otherwise requires write access to the repository), use the third-party [http://developer.mozilla.org/en/docs/Creating_a_patch#Including_new_files_in_a_patch cvsdo] utility (which you'll need to install) to imitate the <tt>cvs add</tt> operation (alternatively add <code>/Foo.h/0/dummy timestamp//</code> to <tt>path/to/file/CVS/Entries</tt>), then diff as normal.<br />
<br />
To make a patch including files in new directories, first [''fill in the details''], then diff as normal.<br />
<br />
====Removing files in a patch====<br />
Sometimes your patch obsoletes existing files in the tree. <br />
<br />
''Instructions TBA''<br />
<br />
=== <tt>Localizable.strings</tt> ===<br />
<br />
Any UI string that appears in the code rather than in a nib needs to have an entry in <tt>Localizable.strings</tt> (or, in rare instances, a preference pane's <tt>Localizable.strings</tt> or one of the other <tt>.strings</tt> files). When writing new strings, always use “curly quotes” in the actual string text.<br />
<br />
Beginning with Camino 1.6a1 (23-Oct-2007 nightlies), we have converted all <tt>.strings</tt> files to UTF-8 <tt>.strings.in</tt> files which can be <tt>diff</tt>ed and which are then turned into UTF-16 <tt>.strings</tt> files in the build process. Any changes to <tt>.strings.in</tt> files should be included in your diff. Any new <tt>.strings</tt> files should be added to the tree as <tt>.strings.in</tt> files, converted to UTF-16 <tt>.strings</tt> files via the <code>STRINGS_FILES</code> mechanism in <tt>Makefile.in</tt>, and then add the resulting .strings files in <tt>generated/</tt> to the project in the appropriate places.<br />
<br />
To see string changes, you must rebuild Camino from the command line.<br />
<br />
====MOZILLA_1_8_BRANCH====<br />
''Baring any critical security bugs requiring <tt>.strings</tt> changes, the '''MOZILLA_1_8_BRANCH''' is string frozen, and no string changes should occur there.''<br />
<br />
=== Project (<tt>Camino.xcodeproj</tt>) changes ===<br />
Making project changes has to be done using Xcode (when adding, deleting, or moving files, as well as changing most build/compiler options), specifically when adding files. After making any project changes, simply diff the project file as well and include it in your patch (if you made any changes to build configuration or settings, be sure to diff <tt>camino/config/</tt> as well to pick up xcconfig changes). Please check to ensure that your project patches do not change the state of the Camino.app entries in the Camino and CaminoStatic targets (this is usually a problem with srcdir configurations).<br />
<br />
(Removing files can be done by hand if you don't have the proper version of Xcode, but this isn't recommended because removing the obvious entries for files will still leave non-obvious entries in the project file and cause crashes/build failures.)<br />
<br />
====Adding Gecko build products to Camino and the project file====<br />
* If the item is "optional" module (e.g., extension) and is not built by default, fix up <tt>confvars.sh</tt> (on the branch, instead fix up the Camino section of <tt>configure.in</tt> and regenerate <tt>configure</tt>) to make Camino pull and build the item.<br />
** In some cases you can use an <tt>ac_add_options</tt> flag in your <tt>.mozconfig</tt> rather than patching <tt>confvars.sh</tt>/<tt>configure.in</tt>, but anything that's required to make Camino not burn when all is done needs to be declared in <tt>confvars.sh</tt>/<tt>configure.in</tt>.<br />
* If the item required <tt>confvars.sh</tt>/<tt>configure.in</tt> or <tt>.mozconfig</tt> changes, do a full rebuild of your tree.<br />
** You'll typically have to build both non-static and static unless you're intimately familiar with the location of build products and naming conventions<br />
* If the library or <tt>.xpt</tt> is something that seems relevant to all embeddors, <tt>embedding/config/basebrowser-mac-macho</tt> should probably be modified to deliver the build products to <tt>dist/Embed/*</tt> rather than <tt>dist/*</tt><br />
* Add the libraries to appropriate build target(s), and using "Relative to Project" paths when adding<br />
** In most cases you'll want to add to the non-static (default) and static target separately<br />
** There are separate folders in the Xcode "sources" tree for static and non-static libs, and for components and "regular" libs <!-- check this wrt the new project files--><br />
* Adding is best done from a <code>srcdir</code> build, but can be done with an <code>objdir</code> build if you carefully fix paths manually; note that in some cases Xcode will resolve symlinks when adding, so you'll have to fix the paths to point back to <tt>dist/Embed/*</tt> (or <tt>dist/*</tt>, if appropriate)<br />
* Move the products from Bundle Resources Copy Phase to the correct copy phase for that sort of Gecko product (for static builds, the static libs belong in the Libraries and Frameworks phase). Different versions of Xcode mis-guess the Copy Phase destinations in different ways.<br />
* Repeat the previous two steps for any <tt>.xpt</tt> files that the libraries might require<br />
* Check for, and remove if necessary, any bizarre changes to the header or library search paths that Xcode may have “helpfully” added for you.<br />
* Fix <code>nsStaticComponents.cpp</code> for static builds<br />
<br />
=== Nib changes ===<br />
<br />
Attach any changed nibs in a .zip archive (separate from the actual patch). Also upload a screenshot of the nib as it appears in the compiled app, using Cmd-shift-4 then space (to get a window-only screenshot). Some committers will want to re-create your changed nib before checkin, so make sure you indicate changes if they aren't obvious. Nibs only need a single review, but any significant changes should be discussed thoroughly on the bug and on IRC if possible. Bugs that contain only nib changes (cosmetic bugs) should request a super review; otherwise, they are unnecessary.<br />
<br />
When editing nibs, be sure to follow the guidelines in [[Development:Editing Nibs]]. Until further notice, '''all nib work should be done only in Interface Builder 2.5.x''' (preferably IB 2.5.4 under Mac OS X 10.4, as a number of features do not work properly in IB 2.5.6 under Mac OS X 10.5 and its nibs can load more slowly, but it can be run under in a pinch).<br />
<br />
== Reviewers and Owners ==<br />
Camino doesn't have traditional “module owners” like the rest of the Mozilla project does. However, below is a list of areas of code or functionality in Camino and reviewers/super-reviewers who are comfortable in those areas (items in '''bold''' are not formal Bugzilla components).<br />
<br />
* Annoyance Blocking:<br />
** '''Ad-blocking''': ardissone, smfr<br />
** '''Pop-up blocking''': murph, smorgan<br />
* Bookmarks: smorgan, cl<br />
* '''Build Config''': mento, ardissone<br />
* '''Cocoa UI''': <!--BruceD, -->Wevah, murph<br />
* Downloading: kreeger, smorgan<br />
* '''Gecko-related changes/CH-embedding''': hwaara, kreeger, smorgan<br />
* History: smfr, smorgan<br />
* HTML Form Controls:<br />
*: ''(these bugs are likely Core bugs that should be kicked to Widget:Cocoa in most cases)''<br />
* '''Input Methods (IME)''': smfr<br />
*: ''(Camino chrome only; content belongs in Widget:Cocoa)'' <br />
* Location Bar & Autocomplete: smorgan<br />
* '''Nib changes''': ardissone (''primarily layout/style and access conformance''), froodian<br />
* OS Integration:<br />
** '''AppleScript''': smfr, peeja<br />
** '''Feed handling''': kreeger<br />
** '''Spell-checking''': murph, smorgan <br />
* Page Layout:<br />
*: ''(these bugs are likely Core bugs that should be kicked elsewhere, or bugs in Camino arising from ad-blocking or build-config issues)''<br />
* Plugins: smfr, josh<br />
*: ''(though these bugs are most likely Core bugs that should be kicked elsewhere)''<br />
* Product Site: ss, Wevah, ardissone<br />
* Security: smfr, smorgan<br />
* Tabbed Browsing: smorgan, jeff, froodian<br />
* Toolbars & Menus: froodian, cl<br />
* Translations: marcello<br />
<br />
Do not let the list above limit your choice of reviewers; '''all regular Camino contributors can review any patch''' (with the exceptions listed below; also, a reviewer may decline to review certain patches due to schedule issues or if the patch is fairly complex and touches code the reviewer is very unfamiliar with). <br />
<br />
<!--'''In addition to the reviewers listed above, initial reviews can be requested from''' jpellico, aschulm or delliott.<br />
--><br />
'''Exceptions:'''<br />
<br />
* Smokey Ardisson [ardissone] does not review code changes outside of project patches and the areas mentioned above, but will test patches.<br />
* Samuel Sidler [ss] also does not review code changes. He should sign-off on all Product Site changes.<br />
* Asaf Romano [Mano]'s review is also accepted in Camino, but he is not currently reviewing Camino patches. <br />
<!--* Check with Josh Aas [josh] before requesting review or super-review from him.--><br />
* Simon Fraser [smfr] is not currently reviewing or super-reviewing Camino patches, unless you are notified otherwise.<br />
* Mike Pinkerton [pinkerton] is currently only super-reviewing patches.<br />
<br />
== “Super” Reviews ==<br />
A super-reviewer can super-review a patch in any part of Camino. There are four people who can give super-reviews in Camino, the three project leads, Mike Pinkerton, Simon Fraser, and Mark Mentovai, and, additionally, Stuart Morgan can be targeted for super-review on any simple or moderate-sized patch with little Gecko impact. (Simon Fraser is not currently reviewing or super-reviewing Camino patches.)<br />
<br />
Nib changes associated with code changes do not typically require super-review; reviewers should test the nib thoroughly to make sure it satisfies all the conditions in the [[#Nib changes|Nib changes]] section above (or request a separate review on the nib from one of our nib specialists). Nib changes taking place without an associated code change should get approval from a super-reviewer, however.<br />
<br />
== Checking In ==<br />
After a patch has <tt>review+</tt> from two reviewers and <tt>superreview+</tt> from one of the Camino leads, it needs to be checked in. <br />
<br />
Check-ins for Camino can be made by any of the super-reviewers listed above as well as ardissone, froodian, hwaara and kreeger (note that froodian, hwaara, and smfr are not currently checking in Camino patches, nor, with some exceptions, will pinkerton or mento check in patches they have not written). <br />
<br />
If no one is around to check in your patch after it has received the requisite approvals, add <tt>checkin-needed</tt> to the bug's Keyword field and one of the committers should notice and land your patch within a day or so.<br />
<br />
Also note that the <tt>mozilla/camino</tt> directory hierarchy is open for approved Camino check-ins regardless of the state of various trees and branches, with a few exceptions (tagging of major branches, red Camino tinderboxen, missing Camino perf or nightly tinderboxen, etc.).<br />
<br />
===A tip for checking in nibs===<br />
Sometimes a person who doesn't have CVS access will post a new or updated nib on a bug that needs to be checked in. The problem with this is that since a nib is technically a directory, there is a CVS folder inside the nib. If you attempt to check in a nib that has been changed by someone who has the <tt>CVSROOT</tt> set as "<tt>:pserver:anonymous@cvs-mirror.mozilla.org:/cvsrooot</tt>" (''e.g.'', everyone without cvs write access), you will receive an authorization error from cvs. The problem is that the <tt>CVS/Root</tt> file is set as the anonymous <tt>CVSROOT</tt>, not your "<tt>user%email.com@cvs.mozilla.org:/cvsroot</tt>" <tt>CVSROOT</tt>. The easiest way to fix this problem is to copy a Root file from one of the directories you have pulled to and paste it inside the <tt>Something.nib/CVS</tt> folder.<br />
<br />
===Trunk/branch mismatches===<br />
Sometimes (due mostly to Gecko changes on the trunk) the trunk and branch versions of a patch will diverge and you can't use cross-commit to land both places. '''If you're confident the branch patch has been well-tested''' and don't have a branch tree, you can pull just the files you need to commit (rather than pull an entire tree).<br />
<br />
# Set up your cvs environment as normal (i.e., <code>export cvsroot</code>)<br />
# <code>cvs co -r MOZILLA_1_8_BRANCH -d myfolder mozilla/camino/src/browser/foo mozilla/camino/PreferencePanes/Naviagtion/bar</code><br />
#: where <code>MOZILLA_1_8_BRANCH</code> is the branch tag, <code>myfolder</code> is the folder in which you want the stub tree to live, and <code>foo</code> and <code>bar</code> are the files contained in the patch<br />
# Apply the patch and commit the files "as normal"<br />
<br />
===Backing out a patch===<br />
Sometimes you accidentally commit something that shouldn't have landed yet, or sometimes (hopefully rarely) you commit something that breaks the tree and needs to be backed out. To back out a patch, follow these steps:<br />
<br />
# If you need to back out something only on the branch and have no branch tree (i.e., you check in using cross-commit), follow the steps above to grab a "stub" branch tree of the files the patch touched.<br />
# Consult bonsai for the correct backout command(s) to pull files (one per file) to run<br />
#: The "Show commands which could be used to back out these changes" link at the top of the appropriate bonsai page will give you the appropriate command, in the form of<br> <code>cvs update -j1.17.2.4 -j1.17.2.3 mozilla/camino/src/embedding/CHClickListener.mm</code><br>There will be one command per file (this particular example is a branch file, as you can see from the multiple sub-versions; the current [bad] version of the file is listed first and the previous [good] version is second)<br />
# <code>touch</code> each file <br />
# <code>cvs diff -u</code> the file(s) to sanity-check that the bad changes have been reverted in your local copy of the files<br />
# <code>cvs commit</code> "as normal"; this will commit a new copy of the file(s) with the incorrect change backed out</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-09-10:Log&diff=9311Status Meetings:2008-09-10:Log2008-09-10T16:51:39Z<p>Clawson: fix pre tag</p>
<hr />
<div><pre><br />
[12:11pm] <cl> oh, heh.<br />
[12:11pm] smorgan was promoted to operator by you.<br />
[12:11pm] pinkerton was promoted to operator by you.<br />
[12:11pm] <cl> ready to get started?<br />
[12:12pm] <cl> ardissone isn't going to be here, so I'm running the meeting with smorgan's help<br />
[12:12pm] <cl> everyone open your Camino 2.0pre to http://wiki.caminobrowser.org/Status_Meetings:2008-09-10:Agenda<br />
[12:13pm] <cl> I don't think we're really sure what the spike in 1.6.3 crashes is about<br />
[12:14pm] <cl> 1Password released a new beta version last week that "fixed several problems in the Camino extension"<br />
[12:15pm] <pinkerton> heh, so now we get all new and different crashes<br />
[12:15pm] <cl> right.<br />
[12:15pm] <cl> (maybe that's what the spike was about...)<br />
[12:16pm] <cl> Other than that, I don't think there's much news on the 1.6.3 front<br />
[12:16pm] <cl> which means we can move on to 1.6.4<br />
[12:16pm] <smorgan> Hopefully that was the "prefix category methods" release<br />
[12:16pm] <cl> mento: I was told to be sure to ping you about making sure to pull the relnotes and bug 454087 for a minibranch<br />
[12:17pm] <cl> Marcello needs it for l10n before the weekend if at all possible, so whenever you can spin, go for it<br />
[12:17pm] <cl> and 1.8.1.17 goes live next Tuesday.<br />
[12:18pm] <cl> I think that pretty much covers everything on branch.<br />
[12:18pm] <cl> Any questions/comments/etc. on the 1.6.x stuff so far?<br />
[12:19pm] <cl> No? OK, moving on.<br />
[12:19pm] <cl> 2.0 is progressing nicely<br />
[12:20pm] <cl> smorgan's certificate UI stuff landed this week, IIRC<br />
[12:20pm] <cl> so that's a big step in the right direction<br />
[12:20pm] <cl> there's still a pretty big list in Bugzilla of bugs targeted at 2.0<br />
[12:20pm] <cl> we're planning to re-triage once we get an alpha shipped<br />
[12:21pm] <cl> I took a quick look through it last night and don't think there's a whole lot on there that I can personally tackle, or else I would.<br />
[12:21pm] <cl> but there is a fair bit still assigned to "nobody", so if anyone is looking for a project<br />
[12:21pm] <sand.mozilla.org><br />
cl invited murph into the channel.<br />
[12:22pm] <cl> (sorry, murph, thought you were already here)<br />
[12:22pm] <cl> Haven't heard from Jeff on the tab-dragging<br />
[12:23pm] <cl> Ideally murph will show up in a minute or two here and we can talk about what he's working on...<br />
[12:24pm] <cl> In the absence of murph, though, moving on to Tabsposé<br />
[12:24pm] <cl> smorgan has a patch that helps a lot<br />
[12:24pm] <cl> we're not sure what else might be done there to help more, but the patch is definitely a good start<br />
[12:25pm] <cl> (bug 390406 in case anyone's wondering)<br />
[12:26pm] <cl> I have no idea about the tinderboxen<br />
[12:26pm] <cl> so we're going to skip that unless isaac has any updates for us<br />
[12:26pm] <cl> I've started working on CBSamplePane yet again (I got distracted by that, which is why I started the meeting so late)<br />
[12:27pm] <cl> smorgan: I think your dummy ivar idea will probably work, just need to test it<br />
[12:27pm] <cl> weekly bugs and queues update...<br />
[12:28pm] <cl> we've been very busy in the last week <br />
[12:28pm] <cl> I cancelled a bunch of review requests on obsolete patches and untargeted review requests this morning, so the r queue is looking rather more manageable<br />
[12:28pm] <cl> a lot of what's in there now is mento<br />
[12:29pm] <cl> peeja has one from that AppleScript dragging bug Smokey fixed yesterday<br />
[12:29pm] <cl> and isaac has a couple site bugs<br />
[12:29pm] <cl> the sr queue is all pinkerton<br />
[12:29pm] <cl> including a major one, the tab-chain patch from murph<br />
[12:31pm] <cl> Anyone have any questions/comments on any of the 2.0 stuff?<br />
[12:33pm] <cl> Moving on to specific bugs<br />
[12:34pm] <cl> I don't really have much to say about anything on that list<br />
[12:34pm] <cl> although hendy put a patch in my queue recently that I think does need a bit of discussion<br />
[12:34pm] <cl> bug 370331<br />
[12:35pm] <smorgan> seems reasonable<br />
[12:36pm] <cl> do we worry about data: URIs there too, or not bother?<br />
[12:36pm] <cl> since data: URIs can operate both in page context and their own context<br />
[12:37pm] <smorgan> I'm not concerned about data:<br />
[12:37pm] <cl> k<br />
[12:40pm] <cl> Other than that, I got nothin.<br />
[12:41pm] <cl> mento: i'll be around in channel most of the afternoon if you have any questions about what to minibranch, and I think smokey will be back later<br />
[12:41pm] <cl> pinkerton: I'll leave you alone so you can work on that sr queue <br />
[12:41pm] <cl> isaac: if you get around to the site bugs soon-ish, great <br />
[12:42pm] <cl> everyone else: great job this week with all the bug-fixing, and keep it going!<br />
[12:44pm] smorgan left the chat room.<br />
[12:45pm] <pinkerton> heh<br />
[12:45pm] <pinkerton> ok<br />
[12:45pm] pinkerton left the chat room.<br />
</pre></div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-09-10:Log&diff=9310Status Meetings:2008-09-10:Log2008-09-10T16:51:03Z<p>Clawson: log</p>
<hr />
<div>[pre]<br />
[12:11pm] <cl> oh, heh.<br />
[12:11pm] smorgan was promoted to operator by you.<br />
[12:11pm] pinkerton was promoted to operator by you.<br />
[12:11pm] <cl> ready to get started?<br />
[12:12pm] <cl> ardissone isn't going to be here, so I'm running the meeting with smorgan's help<br />
[12:12pm] <cl> everyone open your Camino 2.0pre to http://wiki.caminobrowser.org/Status_Meetings:2008-09-10:Agenda<br />
[12:13pm] <cl> I don't think we're really sure what the spike in 1.6.3 crashes is about<br />
[12:14pm] <cl> 1Password released a new beta version last week that "fixed several problems in the Camino extension"<br />
[12:15pm] <pinkerton> heh, so now we get all new and different crashes<br />
[12:15pm] <cl> right.<br />
[12:15pm] <cl> (maybe that's what the spike was about...)<br />
[12:16pm] <cl> Other than that, I don't think there's much news on the 1.6.3 front<br />
[12:16pm] <cl> which means we can move on to 1.6.4<br />
[12:16pm] <smorgan> Hopefully that was the "prefix category methods" release<br />
[12:16pm] <cl> mento: I was told to be sure to ping you about making sure to pull the relnotes and bug 454087 for a minibranch<br />
[12:17pm] <cl> Marcello needs it for l10n before the weekend if at all possible, so whenever you can spin, go for it<br />
[12:17pm] <cl> and 1.8.1.17 goes live next Tuesday.<br />
[12:18pm] <cl> I think that pretty much covers everything on branch.<br />
[12:18pm] <cl> Any questions/comments/etc. on the 1.6.x stuff so far?<br />
[12:19pm] <cl> No? OK, moving on.<br />
[12:19pm] <cl> 2.0 is progressing nicely<br />
[12:20pm] <cl> smorgan's certificate UI stuff landed this week, IIRC<br />
[12:20pm] <cl> so that's a big step in the right direction<br />
[12:20pm] <cl> there's still a pretty big list in Bugzilla of bugs targeted at 2.0<br />
[12:20pm] <cl> we're planning to re-triage once we get an alpha shipped<br />
[12:21pm] <cl> I took a quick look through it last night and don't think there's a whole lot on there that I can personally tackle, or else I would.<br />
[12:21pm] <cl> but there is a fair bit still assigned to "nobody", so if anyone is looking for a project<br />
[12:21pm] <sand.mozilla.org><br />
cl invited murph into the channel.<br />
[12:22pm] <cl> (sorry, murph, thought you were already here)<br />
[12:22pm] <cl> Haven't heard from Jeff on the tab-dragging<br />
[12:23pm] <cl> Ideally murph will show up in a minute or two here and we can talk about what he's working on...<br />
[12:24pm] <cl> In the absence of murph, though, moving on to Tabsposé<br />
[12:24pm] <cl> smorgan has a patch that helps a lot<br />
[12:24pm] <cl> we're not sure what else might be done there to help more, but the patch is definitely a good start<br />
[12:25pm] <cl> (bug 390406 in case anyone's wondering)<br />
[12:26pm] <cl> I have no idea about the tinderboxen<br />
[12:26pm] <cl> so we're going to skip that unless isaac has any updates for us<br />
[12:26pm] <cl> I've started working on CBSamplePane yet again (I got distracted by that, which is why I started the meeting so late)<br />
[12:27pm] <cl> smorgan: I think your dummy ivar idea will probably work, just need to test it<br />
[12:27pm] <cl> weekly bugs and queues update...<br />
[12:28pm] <cl> we've been very busy in the last week <br />
[12:28pm] <cl> I cancelled a bunch of review requests on obsolete patches and untargeted review requests this morning, so the r queue is looking rather more manageable<br />
[12:28pm] <cl> a lot of what's in there now is mento<br />
[12:29pm] <cl> peeja has one from that AppleScript dragging bug Smokey fixed yesterday<br />
[12:29pm] <cl> and isaac has a couple site bugs<br />
[12:29pm] <cl> the sr queue is all pinkerton<br />
[12:29pm] <cl> including a major one, the tab-chain patch from murph<br />
[12:31pm] <cl> Anyone have any questions/comments on any of the 2.0 stuff?<br />
[12:33pm] <cl> Moving on to specific bugs<br />
[12:34pm] <cl> I don't really have much to say about anything on that list<br />
[12:34pm] <cl> although hendy put a patch in my queue recently that I think does need a bit of discussion<br />
[12:34pm] <cl> bug 370331<br />
[12:35pm] <smorgan> seems reasonable<br />
[12:36pm] <cl> do we worry about data: URIs there too, or not bother?<br />
[12:36pm] <cl> since data: URIs can operate both in page context and their own context<br />
[12:37pm] <smorgan> I'm not concerned about data:<br />
[12:37pm] <cl> k<br />
[12:40pm] <cl> Other than that, I got nothin.<br />
[12:41pm] <cl> mento: i'll be around in channel most of the afternoon if you have any questions about what to minibranch, and I think smokey will be back later<br />
[12:41pm] <cl> pinkerton: I'll leave you alone so you can work on that sr queue <br />
[12:41pm] <cl> isaac: if you get around to the site bugs soon-ish, great <br />
[12:42pm] <cl> everyone else: great job this week with all the bug-fixing, and keep it going!<br />
[12:44pm] smorgan left the chat room.<br />
[12:45pm] <pinkerton> heh<br />
[12:45pm] <pinkerton> ok<br />
[12:45pm] pinkerton left the chat room.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-08-20:Agenda&diff=9252Status Meetings:2008-08-20:Agenda2008-08-14T03:14:04Z<p>Clawson: listify</p>
<hr />
<div>*{{bug|436012}} -- needs discussion<br />
*{{bug|441733}} -- also needs discussion</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-08-20:Agenda&diff=9251Status Meetings:2008-08-20:Agenda2008-08-14T03:02:33Z<p>Clawson: add bug 441733</p>
<hr />
<div>{{bug|436012}} -- needs discussion<br />
{{bug|441733}} -- also needs discussion</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-08-20:Agenda&diff=9250Status Meetings:2008-08-20:Agenda2008-08-14T02:49:10Z<p>Clawson: add bug 436012</p>
<hr />
<div>{{bug|436012}} -- needs discussion</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-06-25:Agenda&diff=9207Status Meetings:2008-06-25:Agenda2008-06-19T13:59:52Z<p>Clawson: bugs that need discussion for next week</p>
<hr />
<div>Bugs on cl's bug list that need to be discussed (cl will not be here for the meeting, however):<br />
*{{bug|175748}} - Need mechanism for creating new blank bookmarks<br />
*{{bug|313079}} - Control characters in bookmark titles cause strange visual effects<br />
*{{bug|318931}} - History/Bookmarks title changes but URL doesn't (maybe fixed by patch on {{bug|438256}}?)<br />
*{{bug|363664}} - When right clicking on folder "Bookmark Info" should read "Folder Info"</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=9179Development:Third-Party Preference Panes2008-06-05T04:56:36Z<p>Clawson: /* Other potential gotchas and caveats */ more minor tweaks</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
For more on avoiding naming conflicts and the potential consequences of such conflicts, see [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/Conflicts.html Apple's "Preventing Name Conflicts" documentation].<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.<br />
<br />
* Be very careful about doing things with preferences that can be edited from outside the Preferences window, as it's easy for the preferences UI to get out of sync with reality. For example, there are at least three places to edit the <code>security.warn_viewing_mixed</code> preference: the Security preference pane, the warning sheet that comes up when entering a secure page containing insecure elements, and <code>about:config</code>. If your preference pane will edit preferences that can be changed outside the Preferences window, you should read {{Bug|358318}}, {{Bug|373158}}, and {{Bug|411189}} (and possibly {{Bug|371266}} as well) and ensure you have a thorough understanding of the underlying issues behind them. The sample preference pane provided above has comments in the code that should help you to avoid the pref synchronization bugs we've encountered over the course of Camino development.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=9178Development:Third-Party Preference Panes2008-06-05T04:37:24Z<p>Clawson: /* Other potential gotchas and caveats */ more commentary on pref UI sync bugs</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
For more on avoiding naming conflicts and the potential consequences of such conflicts, see [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/Conflicts.html Apple's "Preventing Name Conflicts" documentation].<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.<br />
<br />
* Be very careful about doing things with preferences that can be edited from multiple locations within Camino, as it's easy for the various UI elements to get out of sync with reality. For example, there are at least three places to edit the security.warn_viewing_mixed preference: the Security preference pane, the warning sheet that comes up when entering a secure page containing insecure elements, and about:config. If your preference pane edits preferences that are available from multiple UI points, you should read {{Bug|358318}}, {{Bug|373158}}, and {{Bug|411189}} (and possibly {{Bug|371266}} as well) and ensure you have a thorough understanding of the underlying issues behind them. The sample preference pane provided above has comments in the code that should help you to avoid the pref synchronization bugs we've encountered over the course of Camino development.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=9165Development:Third-Party Preference Panes2008-06-02T15:04:21Z<p>Clawson: /* Other potential gotchas and caveats */ add specific example</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
For more on avoiding naming conflicts and the potential consequences of such conflicts, see [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/Conflicts.html Apple's "Preventing Name Conflicts" documentation].<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.<br />
<br />
* ''[This needs to be updated once a decision is reached on willSelect/didSelect/didActivate. See bug 411189. -cl]'' If you plan to add UI for any Gecko preferences (anything that shows up in about:config or normally requires the editing of a user.js file, like the aforementioned UserAgent preference pane does), you should read {{Bug|358318}}, {{Bug|373158}}, and {{Bug|411189}} (and possibly {{Bug|371266}} as well) and ensure you have a thorough understanding of the underlying issues behind them. The sample preference pane provided above has comments in the code that should help you to avoid the pref synchronization bugs we've encountered over the course of Camino development.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=9164Development:Third-Party Preference Panes2008-06-02T15:03:28Z<p>Clawson: revisions from more pref pane exploration</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
For more on avoiding naming conflicts and the potential consequences of such conflicts, see [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/Conflicts.html Apple's "Preventing Name Conflicts" documentation].<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.<br />
<br />
* ''[This needs to be updated once a decision is reached on willSelect/didSelect/didActivate. See bug 411189. -cl]'' If you plan to add UI for any Gecko preferences (anything that shows up in about:config or normally requires the editing of a user.js file), you should read {{Bug|358318}}, {{Bug|373158}}, and {{Bug|411189}} (and possibly {{Bug|371266}} as well) and ensure you have a thorough understanding of the underlying issues behind them. The sample preference pane provided above has comments in the code that should help you to avoid the pref synchronization bugs we've encountered over the course of Camino development.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Camino_Meet-up:2008&diff=9157Camino Meet-up:20082008-05-28T18:00:34Z<p>Clawson: /* Who */ probably not going to be there, though that *might* change</p>
<hr />
<div>After the success of our last meet-up in 2007, we'd like to hold another meeting of Camino contributors.<br />
<br />
== What ==<br />
A 2008 Camino meet-up proposed to allow the developers and contributors meet and talk about the future of Camino.<br />
<br />
== When ==<br />
'''June 14, 2008''' (the Saturday after WWDC) starting at 10am PDT.<br />
<br />
== Where ==<br />
San Francisco, specific location TBD.<br />
<br />
== Who ==<br />
All current and past contributors to Camino would be invited. We'd also invite relevant people from the Gecko team (those working on Mac development).<br />
<br />
=== Confirmed Attendees ===<br />
pinkerton, ss, jeff<br />
<br />
=== Pending Attendees ===<br />
smorgan, kreeger, froodian, ludo, peeja, hwaara, josh, marcello, hicks, delliott, murph, Wevah, smichaud, cbarrett<br />
<br />
=== Can't Make It ===<br />
ardissone, cl, mento, smfr<br />
<br />
== How Much ==<br />
We, individually, are responsible for transportation to the bay area, lodging, and other related expenses. Lunch and dinner on the 14th will be covered.<br />
<br />
Where possible, those who live in the area could house a couple (or more!) out-of-towners to help defray the costs to them. If needed, we would try to support those who can't afford to come on their own dime.<br />
<br />
ss is able to house two or three people and transport them to the meet-up (if transportation is needed).<br />
<br />
== Questions ==<br />
If you have any questions or concerns, feel free to leave them below.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-04-30:Agenda&diff=9079Status Meetings:2008-04-30:Agenda2008-04-25T17:02:36Z<p>Clawson: add triage note</p>
<hr />
<div>Note to triage team: Josh says plugin bugs should be kicked to Core:Plug-ins to ensure a means of communication between Mozilla devs and plugin vendors, even if the bug is obviously the fault of the plugin. This also helps assure that such bugs don't get lost or forgotten.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8819Development:Third-Party Preference Panes2008-02-03T04:22:09Z<p>Clawson: Development:Third-Party prefPanes moved to Development:Third-Party Preference Panes: proper name, etc.</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). <br />
Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_prefPanes&diff=8820Development:Third-Party prefPanes2008-02-03T04:22:09Z<p>Clawson: Development:Third-Party prefPanes moved to Development:Third-Party Preference Panes: proper name, etc.</p>
<hr />
<div>#REDIRECT [[Development:Third-Party Preference Panes]]</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8818Development:Third-Party Preference Panes2008-02-03T04:15:04Z<p>Clawson: /* Using Gecko functions and methods */ stress that Bugzilla is the proper way to get devs' attention for stuff like this</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). <br />
Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention by [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html filing a bug report] (with severity of "Enhancement"). We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8817Development:Third-Party Preference Panes2008-02-03T04:08:29Z<p>Clawson: /* Creating the Xcode project */ make it more checklist-like</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own as follows.<br />
<br />
===Making the new PreferencePane project===<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
===Changing the creator code===<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
===Changing the bundle ID===<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example. You should make a reasonable effort to ensure that this bundle ID is unique across all Camino preference panes.<br />
<br />
===Changing the class names===<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class might be <code>ComJohnDoeAwesomePrefs</code>. As with the bundle ID, you should make a reasonable effort to ensure class names are unique not only within your project, but across all Camino preference panes.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). <br />
Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8816Development:Third-Party Preference Panes2008-02-03T03:54:37Z<p>Clawson: /* Who should read this document? */ first try at pink's suggestions</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
This documentation is intended for third-party developers interested in writing preference panes for Camino using Apple's Cocoa APIs, and assumes a basic working knowledge of Xcode, Cocoa, and Objective-C programming.<br />
<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. There are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default.<br />
<br />
For example, while Camino does not provide any UI (other than about:config) for changing the user-agent string passed by the browser to a Web server, the basic hooks are present for a third-party developer to write a preference pane that puts UI on this ability, and the [http://pimpmycamino.com/parts/user-agent UserAgent preference pane] does exactly that.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class would be <code>ComJohndoeAwesomeprefs</code>.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). <br />
Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Reviewing&diff=8813Development:Reviewing2008-01-30T18:02:25Z<p>Clawson: /* Coding for latest-OS-version features or using private APIs */ add other learnWord: reference</p>
<hr />
<div>Patch review in the Camino Project works a bit differently than in the rest of the Mozilla project. This document outlines the review process in Camino and whom to ask for reviews.<br />
<br />
== How Many Reviews? ==<br />
Typically, Camino requires three reviews on a patch before it is committed to the cvs repository: two normal reviews and one super-review. This rule can be overridden by any of the super-reviewers. The reason Camino requires two normal reviews is for greater visibility and to give reviewers a better understanding of more code.<br />
<br />
== Requesting Review ==<br />
When requesting review, always request an initial review from one of the reviewers listed [[#Reviewers and Owners|below]] and then, '''*after*''' (and only after) receiving <tt>review+</tt> from two of them, request super-review from one of the super-reviewers.<br />
<br />
It's a good idea to "target" a specific reviewer or super-reviewer; patches set to <tt>review?</tt> or <tt>superreview?</tt> with no email address entered in the corresponding '''Requestee:''' box tend to get lost. Check the list [[#Reviewers and Owners|below]] to see which reviewer(s) have expertise in the area(s) your patch touches; you will often get a review more quickly that way. You can also check [bonsai's cvs log] for the file(s) you're hacking and [bonsai's cvs blame] for the lines of code you're changing to see which reviewers have hacked or reviewed that code before.<br />
<br />
Also check the queue ([https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&requestee=&component=&group=type reviews], [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&requestee=&component=&group=type super-reviews]) to see which reviewers are "backed up" before requesting review or super-review; you might also ask on [irc://irc.mozilla.org#camino irc] if the reviewer can do a review/super-review first. If you are unsure of whom to ask or have other questions, please ask on [irc://irc.mozilla.org#camino #camino] on irc.<br />
<br />
Make sure your patch applies, builds, and works on the current trunk before requesting reviews (all development should be done on the trunk and backported to the branches if applicable). For patches which will land on one or more branches, verify that the Mac OS X and/or Gecko functions you use are available.<br />
:For instance, while the trunk supports only Mac OS X 10.4 and above (and requires the 10.4u SDK and gcc 4.0.1), the MOZILLA_1_8_BRANCH (Camino 1.6pre and Camino 1.5.x) must support Mac OS X 10.3.0 and above<!--, and Camino 1.0.x must support Mac OS X 10.2.8 as well-->. '''Patches that are designed to land on the MOZILLA_1_8_BRANCH or CAMINO_1_5_BRANCH (for security releases) and must use Mac OS X functions that are available in the 10.3.9 SDK and must compile with gcc 3.3.''' Similarly, many Gecko functions available on the trunk are either greatly enhanced over their counterparts on the MOZILLA_1_8_BRANCH, and many Gecko functions on the trunk do not exist at all on the MOZILLA_1_8_BRANCH. <br />
In any case where a patch is intended for landing on the trunk and the branch(es), you should ensure that the trunk patch will both apply properly and work on the branch(es); if not, you need to supply branch version(s) of the patch.<br />
<br />
To request review, set the '''review''' drop-down menu for your patch to '''?''' and then fill in the reviewer's email address in the '''Requestee''' field (you can do this when attaching your patch, or afterwards by clicking on the '''Edit''' link next to your patch in the bug's attachment table).<br />
<br />
Review is typically a process rather than a single event; reviewers will often request changes to your patch before they will approve it (by setting the '''?''' flag to '''+'''). A patch that does not meet with the reviewer’s approval will have its flag set to '''-''', and the reviewer will provide a list of problems or changes in the bug’s comments. A patch receiving <tt>review-</tt> is common, especially when you are just getting started with Camino. Make the changes the reviewer has requested, post a new patch, and request review again. Soon your patch will be ready for super-review and check-in to the repository.<br />
<br />
On occasion the reviewer will set the the '''?''' flag to '''+''' but also leave a comment with changes that need to be made to the patch (usually these are minor changes). When this happens, the reviewer feels that it is not necessary for him to re-review the patch with the changes. Instead, make the changes and post a new patch (obsoleting the old patch via the checkbox on the add attachment page), and set the <tt>review</tt> flag on the new patch to '''+''' yourself, with a comment like “carrying over r+ from $reviewer”. Also set set any other flags (a second review) to their values from the previous version of the patch, or set the <tt>superreview?</tt> flag.<br />
<br />
=== Code style ===<br />
<br />
''Link to Mozilla coding style guidelines as well as create some for Camino, so we avoid {{bug|308942}} comment 8 and 14 and {{bug|228840}} comments 15, 16, 18, and 19.''<br />
<br />
*[http://www.mozilla.org/hacking/mozilla-style-guide.html Mozilla Coding Style Guide]<br />
*[http://www.mozilla.org/MPL/boilerplate-1.1/ License block for new files]<br />
<br />
''Also link to [http://www.mozilla.org/hacking/ Hacking Mozilla] general intro somewhere in our contributor introduction''<br />
<br />
All new code should conform to Camino's style guidelines, which is a descendent of the Mozilla style guidelines (per decree by our leader):<br />
<br />
<pre><br />
if (foo) {<br />
bar;<br />
blam;<br />
}<br />
else {<br />
baz;<br />
zap;<br />
}<br />
</pre><br />
<br />
Braces for single statements are optional (and discouraged, but some still include them).<br />
<br />
We explicitly have no style rule regarding the placement of <tt>*</tt>. Aim to be consistent within a file in as much as the files are consistent.<br />
<br />
=== Coding for latest-OS-version features or using private APIs ===<br />
<br />
Each situation is unique, but we have provided some existing examples of various strategies employed to correctly code for these situations.<br />
<br />
The spell-checker's <code>learnWord:</code> method is undocumented, but is the only way to achieve proper learned spelling for the OS X system dictionary. [http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#520 Example code here] and [http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#4472 here].<br />
<br />
Setting Spotlight metadata on files is also undocumented as of the 10.5 SDK. Our download listener code has [http://mxr.mozilla.org/mozilla/source/camino/src/download/nsDownloadListener.mm#652 a very well-documented and commented example] of how to use a method like this safely.<br />
<br />
''spellcheck learn/add word, wherefrom metadata, quarantine extended metadata, what else?''<br />
<br />
====Situation====<br />
Description and mxr link<br />
<br />
=== Proper patch format ===<br />
<br />
Use <tt>cvs diff -u8N</tt> for patches to Camino code. Diffs should be done from <tt>/mozilla/camino</tt> or <tt>/mozilla</tt> for consistency and ease of application by reviewers and committers. All changes—including new source code files and project file changes, if applicable—should be submitted as a single patch (''e.g.'', <tt>cvs diff -u8N src/foo/bar src/baz/bam</tt>, with the exception of changes to <tt>.strings</tt> files, nibs, and images; see below for more about requirements for those three file types.<br />
<br />
====Adding new files in a patch====<br />
Sometimes the code you are writing requires the creation of new source files. In order to allow these files to be included in your single patch file, you must perform the additional step of <tt>cvs add</tt>ing the file, or, if you do not have cvs write privileges, of imitating the <tt>cvs add</tt> process.<br />
<br />
To make a patch including a new file (which otherwise requires write access to the repository), use [http://developer.mozilla.org/en/docs/Creating_a_patch#Including_new_files_in_a_patch cvsdo] to imitate the <tt>cvs add</tt> operation (alternatively add <code>/Foo.h/0/dummy timestamp//</code> to <tt>path/to/file/CVS/Entries</tt>), then diff as normal.<br />
<br />
To make a patch including files in new directories, first [''fill in the details''], then diff as normal.<br />
<br />
====Removing files in a patch====<br />
Sometimes your patch obsoletes existing files in the tree. <br />
<br />
''Instructions TBA''<br />
<br />
=== <tt>Localizable.strings</tt> ===<br />
<br />
Any UI string that appears in the code rather than in a nib needs to have an entry in <tt>Localizable.strings</tt> (or, in rare instances, a preference pane's <tt>Localizable.strings</tt> or one of the other <tt>.strings</tt> files). When writing new strings, always use “curly quotes” in the actual string text.<br />
<br />
Beginning with Camino 1.6a1 (23-Oct-2007 nightlies), we have converted all <tt>.strings</tt> files to UTF-8 <tt>.strings.in</tt> files which can be <tt>diff</tt>ed and which are then turned into UTF-16 <tt>.strings</tt> files in the build process. Any changes to <tt>.strings.in</tt> files should be included in your diff. Any new <tt>.strings</tt> files should be added to the tree as <tt>.strings.in</tt> files, converted to UTF-16 <tt>.strings</tt> files via the <code>STRINGS_FILES</code> mechanism in <tt>Makefile.in</tt>, and then add the resulting .strings files in <tt>generated/</tt> to the project in the appropriate places.<br />
<br />
====CAMINO_1_5_BRANCH====<br />
''Baring any critical security bugs requiring <tt>.strings</tt> changes, the '''CAMINO_1_5_BRANCH''' is string frozen, and no string changes should occur there. However, the following section describes the procedure to follow in the event such changes should be required.''<br />
<br />
If you make additions or changes to the <tt>Localizable.strings</tt> file, make a '''clear note''' in your comment when attaching your patch, indicating which strings should be added or changed. '''Do not attempt to <tt>diff</tt> the file''' (<tt>.strings</tt> files are UTF-16, which <tt>diff</tt> does not understand properly), and '''do not attach changed <tt>Localizable.strings</tt> files''' (which tend to become stale and cause regressions). <br />
<br />
It is also helpful to add a note to the bug's Status Whiteboard field pointing to the comment with the latest strings changes, e.g. <tt>[new strings in comment 23]</tt>.<br />
<br />
=== Project (<tt>Camino.xcodeproj</tt>) changes ===<br />
Making project changes has to be done using Xcode (when adding, deleting, or moving files, as well as changing most build/compiler options), specifically when adding files. After making any project changes, simply diff the project file as well and include it in your patch (if you made any changes to build configuration or settings, be sure to diff <tt>camino/config/</tt> as well to pick up xcconfig changes). Please check to ensure that your project patches do not change the state of the Camino.app entries in the Camino and CaminoStatic targets (this is usually a problem with srcdir configurations).<br />
<br />
(Removing files can be done by hand if you don't have the proper version of Xcode, but this isn't recommended because removing the obvious entries for files will still leave non-obvious entries in the project file and cause crashes/build failures.)<br />
<br />
====Adding Gecko build products to Camino and the project file====<br />
* If the item is "optional" module (e.g., extension) and is not built by default, fix up <tt>confvars.sh</tt> (on the branch, instead fix up the Camino section of <tt>configure.in</tt> and regenerate <tt>configure</tt>) to make Camino pull and build the item.<br />
** In some cases you can use an <tt>ac_add_options</tt> flag in your <tt>.mozconfig</tt> rather than patching <tt>confvars.sh</tt>/<tt>configure.in</tt>, but anything that's required to make Camino not burn when all is done needs to be declared in <tt>confvars.sh</tt>/<tt>configure.in</tt>.<br />
* If the item required <tt>confvars.sh</tt>/<tt>configure.in</tt> or <tt>.mozconfig</tt> changes, do a full rebuild of your tree.<br />
** You'll typically have to build both non-static and static unless you're intimately familiar with the location of build products and naming conventions<br />
* If the library or <tt>.xpt</tt> is something that seems relevant to all embeddors, <tt>embedding/config/basebrowser-mac-macho</tt> should probably be modified to deliver the build products to <tt>dist/Embed/*</tt> rather than <tt>dist/*</tt><br />
* Add the libraries to appropriate build target(s), and using "Relative to Project" paths when adding<br />
** In most cases you'll want to add to the non-static (default) and static target separately<br />
** There are separate folders in the Xcode "sources" tree for static and non-static libs, and for components and "regular" libs <!-- check this wrt the new project files--><br />
* Adding is best done from a <code>srcdir</code> build, but can be done with an <code>objdir</code> build if you carefully fix paths manually; note that in some cases Xcode will resolve symlinks when adding, so you'll have to fix the paths to point back to <tt>dist/Embed/*</tt> (or <tt>dist/*</tt>, if appropriate)<br />
* Move the products from Bundle Resources Copy Phase to the correct copy phase for that sort of Gecko product (for static builds, the static libs belong in the Libraries and Frameworks phase). Different versions of Xcode mis-guess the Copy Phase destinations in different ways.<br />
* Repeat the previous two steps for any <tt>.xpt</tt> files that the libraries might require<br />
* Check for, and remove if necessary, any bizarre changes to the header or library search paths that Xcode may have “helpfully” added for you.<br />
* Fix <code>nsStaticComponents.cpp</code> for static builds<br />
<br />
=== Nib changes ===<br />
<br />
Attach any changed nibs in a .zip archive (separate from the actual patch). Also upload a screenshot of the nib as it appears in the compiled app, using Cmd-shift-4 then space (to get a window-only screenshot). Some committers will want to re-create your changed nib before checkin, so make sure you indicate changes if they aren't obvious. Nibs only need a single review, but any significant changes should be discussed thoroughly on the bug and on IRC if possible. Bugs that contain only nib changes (cosmetic bugs) should request a super review; otherwise, they are unnecessary.<br />
<br />
When editing nibs, be sure to follow the guidelines in [[Development:Editing Nibs]]. Until further notice, '''all nib work should be done only in Interface Builder 2.5.x''' (preferably IB 2.5.4 under Mac OS X 10.4, as a number of features do not work properly in IB 2.5.6 under Mac OS X 10.5 and its nibs can load more slowly, but it can be run under in a pinch).<br />
<br />
== Reviewers and Owners ==<br />
Camino doesn't have traditional “module owners” like the rest of the Mozilla project does. However, below is a list of areas of code or functionality in Camino and reviewers/super-reviewers who are comfortable in those areas (items in '''bold''' are not formal Bugzilla components).<br />
<br />
* Annoyance Blocking:<br />
** '''Ad-blocking''': ardissone, smfr<br />
** '''Pop-up blocking''': murph, smorgan<br />
* Bookmarks: smorgan, cl<br />
* '''Build Config''': mento, ardissone<br />
* '''Cocoa UI''': <!--BruceD, -->Wevah, murph<br />
* Downloading: kreeger, smorgan<br />
* '''Gecko-related changes/CH-embedding''': hwaara, kreeger, smorgan<br />
* History: smfr, smorgan<br />
* HTML Form Controls:<br />
*: ''(these bugs are likely Core bugs that should be kicked to Widget:Cocoa in most cases)''<br />
* '''Input Methods (IME)''': smfr<br />
*: ''(Camino chrome only; content belongs in Widget:Cocoa)'' <br />
* Location Bar & Autocomplete: smorgan<br />
* '''Nib changes''': ardissone (''primarily layout/style and access conformance''), froodian<br />
* OS Integration:<br />
** '''AppleScript''': smfr, peeja<br />
** '''Feed handling''': kreeger<br />
** '''Spell-checking''': murph, smorgan <br />
* Page Layout:<br />
*: ''(these bugs are likely Core bugs that should be kicked elsewhere, or bugs in Camino arising from ad-blocking or build-config issues)''<br />
* Plugins: smfr, josh<br />
*: ''(though these bugs are most likely Core bugs that should be kicked elsewhere)''<br />
* Product Site: ss, Wevah, ardissone<br />
* Security: smfr, smorgan<br />
* Tabbed Browsing: smorgan, jeff, froodian<br />
* Toolbars & Menus: froodian, cl<br />
* Translations: marcello<br />
<br />
Do not let the list above limit your choice of reviewers; '''all regular Camino contributors can review any patch''' (with the exceptions listed below; also, a reviewer may decline to review certain patches due to schedule issues or if the patch is fairly complex and touches code the reviewer is very unfamiliar with). <br />
<br />
<!--'''In addition to the reviewers listed above, initial reviews can be requested from''' jpellico, aschulm or delliott.<br />
--><br />
'''Exceptions:'''<br />
<br />
* Smokey Ardisson [ardissone] does not review code changes outside of project patches, but will test patches.<br />
* Samuel Sidler [ss] also does not review code changes. He should sign-off on all Product Site changes.<br />
* Asaf Romano [Mano]'s review is also accepted in Camino, but he is not currently reviewing Camino patches. <br />
* Check with Josh Aas [josh] before requesting review or super-review from him.<br />
* Simon Fraser [smfr] is not currently reviewing or super-reviewing Camino patches, unless you are notified otherwise.<br />
* Mike Pinkerton [pinkerton] is currently only super-reviewing patches.<br />
<br />
== “Super” Reviews ==<br />
There are four people who can give super-reviews in Camino, the four project leads: Mike Pinkerton, Simon Fraser, Mark Mentovai, and Josh Aas (Simon Fraser is not currently reviewing or super-reviewing Camino patches). A super-reviewer can review a patch in any part of Camino. Additionally, Stuart Morgan can be targeted for super-review on any simple or moderate-sized patch with little Gecko impact.<br />
<br />
Nib changes associated with code changes do not typically require super-review; reviewers should test the nib thoroughly to make sure it satisfies all the conditions in the [[#Nib changes|Nib changes]] section above (or request a separate review on the nib from one of our nib specialists). Nib changes taking place without an associated code change should get approval from a super-reviewer, however.<br />
<br />
== Checking In ==<br />
After a patch has <tt>review+</tt> from two reviewers and <tt>superreview+</tt> from one of the Camino leads, it needs to be checked in. <br />
<br />
Check-ins for Camino can be made by any of the super-reviewers listed above as well as ardissone, froodian, hwaara and kreeger (note that josh and smfr are not currently checking in Camino patches, nor, with some exceptions, will pinkerton or mento check in patches they have not written). <br />
<br />
If no one is around to check in your patch after it has received the requisite approvals, add <tt>checkin-needed</tt> to the bug's Keyword field and one of the committers should notice and land your patch within a day or so.<br />
<br />
Also note that the <tt>mozilla/camino</tt> directory hierarchy is open for approved Camino check-ins regardless of the state of various trees and branches, with a few exceptions (tagging of major branches, red Camino tinderboxen, etc.).<br />
<br />
===A tip for checking in nibs===<br />
Sometimes a person who doesn't have CVS access will post a new or updated nib on a bug that needs to be checked in. The problem with this is that since a nib is technically a directory, there is a CVS folder inside the nib. If you attempt to check in a nib that has been changed by someone who has the <tt>CVSROOT</tt> set as "<tt>:pserver:anonymous@cvs-mirror.mozilla.org:/cvsrooot</tt>" (''e.g.'', everyone without cvs write access), you will receive an authorization error from cvs. The problem is that the <tt>CVS/Root</tt> file is set as the anonymous <tt>CVSROOT</tt>, not your "<tt>user%email.com@cvs.mozilla.org:/cvsroot</tt>" <tt>CVSROOT</tt>. The easiest way to fix this problem is to copy a Root file from one of the directories you have pulled to and paste it inside the <tt>Something.nib/CVS</tt> folder.<br />
<br />
===Trunk/branch mismatches===<br />
Sometimes (due mostly to Gecko changes on the trunk) the trunk and branch versions of a patch will diverge and you can't use cross-commit to land both places. '''If you're confident the branch patch has been well-tested''' and don't have a branch tree, you can pull just the files you need to commit (rather than pull an entire tree).<br />
<br />
# Set up your cvs environment as normal (i.e., <code>export cvsroot</code>)<br />
# <code>cvs co -r MOZILLA_1_8_BRANCH -d myfolder mozilla/camino/src/browser/foo mozilla/camino/PreferencePanes/Naviagtion/bar</code><br />
#: where <code>MOZILLA_1_8_BRANCH</code> is the branch tag, <code>myfolder</code> is the folder in which you want the stub tree to live, and <code>foo</code> and <code>bar</code> are the files contained in the patch<br />
# Apply the patch and commit the files "as normal"<br />
<br />
===Backing out a patch===<br />
Sometimes you accidentally commit something that shouldn't have landed yet, or sometimes (hopefully rarely) you commit something that breaks the tree and needs to be backed out. To back out a patch, follow these steps:<br />
<br />
# If you need to back out something only on the branch and have no branch tree (i.e., you check in using cross-commit), follow the steps above to grab a "stub" branch tree of the files the patch touched.<br />
# Consult bonsai for the correct backout command(s) to pull files (one per file) to run<br />
#: The "Show commands which could be used to back out these changes" link at the top of the appropriate bonsai page will give you the appropriate command, in the form of<br> <code>cvs update -j1.17.2.4 -j1.17.2.3 mozilla/camino/src/embedding/CHClickListener.mm</code><br>There will be one command per file (this particular example is a branch file, as you can see from the multiple sub-versions; the current [bad] version of the file is listed first and the previous [good] version is second)<br />
# <code>touch</code> each file <br />
# <code>cvs diff -u</code> the file(s) to sanity-check that the bad changes have been reverted in your local copy of the files<br />
# <code>cvs commit</code> "as normal"; this will commit a new copy of the file(s) with the incorrect change backed out</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Reviewing&diff=8811Development:Reviewing2008-01-30T17:54:35Z<p>Clawson: /* Coding for latest-OS-version features or using private APIs */ add metadata thing</p>
<hr />
<div>Patch review in the Camino Project works a bit differently than in the rest of the Mozilla project. This document outlines the review process in Camino and whom to ask for reviews.<br />
<br />
== How Many Reviews? ==<br />
Typically, Camino requires three reviews on a patch before it is committed to the cvs repository: two normal reviews and one super-review. This rule can be overridden by any of the super-reviewers. The reason Camino requires two normal reviews is for greater visibility and to give reviewers a better understanding of more code.<br />
<br />
== Requesting Review ==<br />
When requesting review, always request an initial review from one of the reviewers listed [[#Reviewers and Owners|below]] and then, '''*after*''' (and only after) receiving <tt>review+</tt> from two of them, request super-review from one of the super-reviewers.<br />
<br />
It's a good idea to "target" a specific reviewer or super-reviewer; patches set to <tt>review?</tt> or <tt>superreview?</tt> with no email address entered in the corresponding '''Requestee:''' box tend to get lost. Check the list [[#Reviewers and Owners|below]] to see which reviewer(s) have expertise in the area(s) your patch touches; you will often get a review more quickly that way. You can also check [bonsai's cvs log] for the file(s) you're hacking and [bonsai's cvs blame] for the lines of code you're changing to see which reviewers have hacked or reviewed that code before.<br />
<br />
Also check the queue ([https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&requestee=&component=&group=type reviews], [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&requestee=&component=&group=type super-reviews]) to see which reviewers are "backed up" before requesting review or super-review; you might also ask on [irc://irc.mozilla.org#camino irc] if the reviewer can do a review/super-review first. If you are unsure of whom to ask or have other questions, please ask on [irc://irc.mozilla.org#camino #camino] on irc.<br />
<br />
Make sure your patch applies, builds, and works on the current trunk before requesting reviews (all development should be done on the trunk and backported to the branches if applicable). For patches which will land on one or more branches, verify that the Mac OS X and/or Gecko functions you use are available.<br />
:For instance, while the trunk supports only Mac OS X 10.4 and above (and requires the 10.4u SDK and gcc 4.0.1), the MOZILLA_1_8_BRANCH (Camino 1.6pre and Camino 1.5.x) must support Mac OS X 10.3.0 and above<!--, and Camino 1.0.x must support Mac OS X 10.2.8 as well-->. '''Patches that are designed to land on the MOZILLA_1_8_BRANCH or CAMINO_1_5_BRANCH (for security releases) and must use Mac OS X functions that are available in the 10.3.9 SDK and must compile with gcc 3.3.''' Similarly, many Gecko functions available on the trunk are either greatly enhanced over their counterparts on the MOZILLA_1_8_BRANCH, and many Gecko functions on the trunk do not exist at all on the MOZILLA_1_8_BRANCH. <br />
In any case where a patch is intended for landing on the trunk and the branch(es), you should ensure that the trunk patch will both apply properly and work on the branch(es); if not, you need to supply branch version(s) of the patch.<br />
<br />
To request review, set the '''review''' drop-down menu for your patch to '''?''' and then fill in the reviewer's email address in the '''Requestee''' field (you can do this when attaching your patch, or afterwards by clicking on the '''Edit''' link next to your patch in the bug's attachment table).<br />
<br />
Review is typically a process rather than a single event; reviewers will often request changes to your patch before they will approve it (by setting the '''?''' flag to '''+'''). A patch that does not meet with the reviewer’s approval will have its flag set to '''-''', and the reviewer will provide a list of problems or changes in the bug’s comments. A patch receiving <tt>review-</tt> is common, especially when you are just getting started with Camino. Make the changes the reviewer has requested, post a new patch, and request review again. Soon your patch will be ready for super-review and check-in to the repository.<br />
<br />
On occasion the reviewer will set the the '''?''' flag to '''+''' but also leave a comment with changes that need to be made to the patch (usually these are minor changes). When this happens, the reviewer feels that it is not necessary for him to re-review the patch with the changes. Instead, make the changes and post a new patch (obsoleting the old patch via the checkbox on the add attachment page), and set the <tt>review</tt> flag on the new patch to '''+''' yourself, with a comment like “carrying over r+ from $reviewer”. Also set set any other flags (a second review) to their values from the previous version of the patch, or set the <tt>superreview?</tt> flag.<br />
<br />
=== Code style ===<br />
<br />
''Link to Mozilla coding style guidelines as well as create some for Camino, so we avoid {{bug|308942}} comment 8 and 14 and {{bug|228840}} comments 15, 16, 18, and 19.''<br />
<br />
*[http://www.mozilla.org/hacking/mozilla-style-guide.html Mozilla Coding Style Guide]<br />
*[http://www.mozilla.org/MPL/boilerplate-1.1/ License block for new files]<br />
<br />
''Also link to [http://www.mozilla.org/hacking/ Hacking Mozilla] general intro somewhere in our contributor introduction''<br />
<br />
All new code should conform to Camino's style guidelines, which is a descendent of the Mozilla style guidelines (per decree by our leader):<br />
<br />
<pre><br />
if (foo) {<br />
bar;<br />
blam;<br />
}<br />
else {<br />
baz;<br />
zap;<br />
}<br />
</pre><br />
<br />
Braces for single statements are optional (and discouraged, but some still include them).<br />
<br />
We explicitly have no style rule regarding the placement of <tt>*</tt>. Aim to be consistent within a file in as much as the files are consistent.<br />
<br />
=== Coding for latest-OS-version features or using private APIs ===<br />
<br />
Each situation is unique, but we have provided some existing examples of various strategies employed to correctly code for these situations.<br />
<br />
The spell-checker's <code>learnWord:</code> method is undocumented, but is the only way to achieve proper learned spelling for the OS X system dictionary. [http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#4472 Example code here].<br />
<br />
Setting Spotlight metadata on files is also undocumented as of the 10.5 SDK. Our download listener code has [http://mxr.mozilla.org/mozilla/source/camino/src/download/nsDownloadListener.mm#652 a very well-documented and commented example] of how to use a method like this safely.<br />
<br />
''spellcheck learn/add word, wherefrom metadata, quarantine extended metadata, what else?''<br />
<br />
====Situation====<br />
Description and mxr link<br />
<br />
=== Proper patch format ===<br />
<br />
Use <tt>cvs diff -u8N</tt> for patches to Camino code. Diffs should be done from <tt>/mozilla/camino</tt> or <tt>/mozilla</tt> for consistency and ease of application by reviewers and committers. All changes—including new source code files and project file changes, if applicable—should be submitted as a single patch (''e.g.'', <tt>cvs diff -u8N src/foo/bar src/baz/bam</tt>, with the exception of changes to <tt>.strings</tt> files, nibs, and images; see below for more about requirements for those three file types.<br />
<br />
====Adding new files in a patch====<br />
Sometimes the code you are writing requires the creation of new source files. In order to allow these files to be included in your single patch file, you must perform the additional step of <tt>cvs add</tt>ing the file, or, if you do not have cvs write privileges, of imitating the <tt>cvs add</tt> process.<br />
<br />
To make a patch including a new file (which otherwise requires write access to the repository), use [http://developer.mozilla.org/en/docs/Creating_a_patch#Including_new_files_in_a_patch cvsdo] to imitate the <tt>cvs add</tt> operation (alternatively add <code>/Foo.h/0/dummy timestamp//</code> to <tt>path/to/file/CVS/Entries</tt>), then diff as normal.<br />
<br />
To make a patch including files in new directories, first [''fill in the details''], then diff as normal.<br />
<br />
====Removing files in a patch====<br />
Sometimes your patch obsoletes existing files in the tree. <br />
<br />
''Instructions TBA''<br />
<br />
=== <tt>Localizable.strings</tt> ===<br />
<br />
Any UI string that appears in the code rather than in a nib needs to have an entry in <tt>Localizable.strings</tt> (or, in rare instances, a preference pane's <tt>Localizable.strings</tt> or one of the other <tt>.strings</tt> files). When writing new strings, always use “curly quotes” in the actual string text.<br />
<br />
Beginning with Camino 1.6a1 (23-Oct-2007 nightlies), we have converted all <tt>.strings</tt> files to UTF-8 <tt>.strings.in</tt> files which can be <tt>diff</tt>ed and which are then turned into UTF-16 <tt>.strings</tt> files in the build process. Any changes to <tt>.strings.in</tt> files should be included in your diff. Any new <tt>.strings</tt> files should be added to the tree as <tt>.strings.in</tt> files, converted to UTF-16 <tt>.strings</tt> files via the <code>STRINGS_FILES</code> mechanism in <tt>Makefile.in</tt>, and then add the resulting .strings files in <tt>generated/</tt> to the project in the appropriate places.<br />
<br />
====CAMINO_1_5_BRANCH====<br />
''Baring any critical security bugs requiring <tt>.strings</tt> changes, the '''CAMINO_1_5_BRANCH''' is string frozen, and no string changes should occur there. However, the following section describes the procedure to follow in the event such changes should be required.''<br />
<br />
If you make additions or changes to the <tt>Localizable.strings</tt> file, make a '''clear note''' in your comment when attaching your patch, indicating which strings should be added or changed. '''Do not attempt to <tt>diff</tt> the file''' (<tt>.strings</tt> files are UTF-16, which <tt>diff</tt> does not understand properly), and '''do not attach changed <tt>Localizable.strings</tt> files''' (which tend to become stale and cause regressions). <br />
<br />
It is also helpful to add a note to the bug's Status Whiteboard field pointing to the comment with the latest strings changes, e.g. <tt>[new strings in comment 23]</tt>.<br />
<br />
=== Project (<tt>Camino.xcodeproj</tt>) changes ===<br />
Making project changes has to be done using Xcode (when adding, deleting, or moving files, as well as changing most build/compiler options), specifically when adding files. After making any project changes, simply diff the project file as well and include it in your patch (if you made any changes to build configuration or settings, be sure to diff <tt>camino/config/</tt> as well to pick up xcconfig changes). Please check to ensure that your project patches do not change the state of the Camino.app entries in the Camino and CaminoStatic targets (this is usually a problem with srcdir configurations).<br />
<br />
(Removing files can be done by hand if you don't have the proper version of Xcode, but this isn't recommended because removing the obvious entries for files will still leave non-obvious entries in the project file and cause crashes/build failures.)<br />
<br />
====Adding Gecko build products to Camino and the project file====<br />
* If the item is "optional" module (e.g., extension) and is not built by default, fix up <tt>confvars.sh</tt> (on the branch, instead fix up the Camino section of <tt>configure.in</tt> and regenerate <tt>configure</tt>) to make Camino pull and build the item.<br />
** In some cases you can use an <tt>ac_add_options</tt> flag in your <tt>.mozconfig</tt> rather than patching <tt>confvars.sh</tt>/<tt>configure.in</tt>, but anything that's required to make Camino not burn when all is done needs to be declared in <tt>confvars.sh</tt>/<tt>configure.in</tt>.<br />
* If the item required <tt>confvars.sh</tt>/<tt>configure.in</tt> or <tt>.mozconfig</tt> changes, do a full rebuild of your tree.<br />
** You'll typically have to build both non-static and static unless you're intimately familiar with the location of build products and naming conventions<br />
* If the library or <tt>.xpt</tt> is something that seems relevant to all embeddors, <tt>embedding/config/basebrowser-mac-macho</tt> should probably be modified to deliver the build products to <tt>dist/Embed/*</tt> rather than <tt>dist/*</tt><br />
* Add the libraries to appropriate build target(s), and using "Relative to Project" paths when adding<br />
** In most cases you'll want to add to the non-static (default) and static target separately<br />
** There are separate folders in the Xcode "sources" tree for static and non-static libs, and for components and "regular" libs <!-- check this wrt the new project files--><br />
* Adding is best done from a <code>srcdir</code> build, but can be done with an <code>objdir</code> build if you carefully fix paths manually; note that in some cases Xcode will resolve symlinks when adding, so you'll have to fix the paths to point back to <tt>dist/Embed/*</tt> (or <tt>dist/*</tt>, if appropriate)<br />
* Move the products from Bundle Resources Copy Phase to the correct copy phase for that sort of Gecko product (for static builds, the static libs belong in the Libraries and Frameworks phase). Different versions of Xcode mis-guess the Copy Phase destinations in different ways.<br />
* Repeat the previous two steps for any <tt>.xpt</tt> files that the libraries might require<br />
* Check for, and remove if necessary, any bizarre changes to the header or library search paths that Xcode may have “helpfully” added for you.<br />
* Fix <code>nsStaticComponents.cpp</code> for static builds<br />
<br />
=== Nib changes ===<br />
<br />
Attach any changed nibs in a .zip archive (separate from the actual patch). Also upload a screenshot of the nib as it appears in the compiled app, using Cmd-shift-4 then space (to get a window-only screenshot). Some committers will want to re-create your changed nib before checkin, so make sure you indicate changes if they aren't obvious. Nibs only need a single review, but any significant changes should be discussed thoroughly on the bug and on IRC if possible. Bugs that contain only nib changes (cosmetic bugs) should request a super review; otherwise, they are unnecessary.<br />
<br />
When editing nibs, be sure to follow the guidelines in [[Development:Editing Nibs]]. Until further notice, '''all nib work should be done only in Interface Builder 2.5.x''' (preferably IB 2.5.4 under Mac OS X 10.4, as a number of features do not work properly in IB 2.5.6 under Mac OS X 10.5 and its nibs can load more slowly, but it can be run under in a pinch).<br />
<br />
== Reviewers and Owners ==<br />
Camino doesn't have traditional “module owners” like the rest of the Mozilla project does. However, below is a list of areas of code or functionality in Camino and reviewers/super-reviewers who are comfortable in those areas (items in '''bold''' are not formal Bugzilla components).<br />
<br />
* Annoyance Blocking:<br />
** '''Ad-blocking''': ardissone, smfr<br />
** '''Pop-up blocking''': murph, smorgan<br />
* Bookmarks: smorgan, cl<br />
* '''Build Config''': mento, ardissone<br />
* '''Cocoa UI''': <!--BruceD, -->Wevah, murph<br />
* Downloading: kreeger, smorgan<br />
* '''Gecko-related changes/CH-embedding''': hwaara, kreeger, smorgan<br />
* History: smfr, smorgan<br />
* HTML Form Controls:<br />
*: ''(these bugs are likely Core bugs that should be kicked to Widget:Cocoa in most cases)''<br />
* '''Input Methods (IME)''': smfr<br />
*: ''(Camino chrome only; content belongs in Widget:Cocoa)'' <br />
* Location Bar & Autocomplete: smorgan<br />
* '''Nib changes''': ardissone (''primarily layout/style and access conformance''), froodian<br />
* OS Integration:<br />
** '''AppleScript''': smfr, peeja<br />
** '''Feed handling''': kreeger<br />
** '''Spell-checking''': murph, smorgan <br />
* Page Layout:<br />
*: ''(these bugs are likely Core bugs that should be kicked elsewhere, or bugs in Camino arising from ad-blocking or build-config issues)''<br />
* Plugins: smfr, josh<br />
*: ''(though these bugs are most likely Core bugs that should be kicked elsewhere)''<br />
* Product Site: ss, Wevah, ardissone<br />
* Security: smfr, smorgan<br />
* Tabbed Browsing: smorgan, jeff, froodian<br />
* Toolbars & Menus: froodian, cl<br />
* Translations: marcello<br />
<br />
Do not let the list above limit your choice of reviewers; '''all regular Camino contributors can review any patch''' (with the exceptions listed below; also, a reviewer may decline to review certain patches due to schedule issues or if the patch is fairly complex and touches code the reviewer is very unfamiliar with). <br />
<br />
<!--'''In addition to the reviewers listed above, initial reviews can be requested from''' jpellico, aschulm or delliott.<br />
--><br />
'''Exceptions:'''<br />
<br />
* Smokey Ardisson [ardissone] does not review code changes outside of project patches, but will test patches.<br />
* Samuel Sidler [ss] also does not review code changes. He should sign-off on all Product Site changes.<br />
* Asaf Romano [Mano]'s review is also accepted in Camino, but he is not currently reviewing Camino patches. <br />
* Check with Josh Aas [josh] before requesting review or super-review from him.<br />
* Simon Fraser [smfr] is not currently reviewing or super-reviewing Camino patches, unless you are notified otherwise.<br />
* Mike Pinkerton [pinkerton] is currently only super-reviewing patches.<br />
<br />
== “Super” Reviews ==<br />
There are four people who can give super-reviews in Camino, the four project leads: Mike Pinkerton, Simon Fraser, Mark Mentovai, and Josh Aas (Simon Fraser is not currently reviewing or super-reviewing Camino patches). A super-reviewer can review a patch in any part of Camino. Additionally, Stuart Morgan can be targeted for super-review on any simple or moderate-sized patch with little Gecko impact.<br />
<br />
Nib changes associated with code changes do not typically require super-review; reviewers should test the nib thoroughly to make sure it satisfies all the conditions in the [[#Nib changes|Nib changes]] section above (or request a separate review on the nib from one of our nib specialists). Nib changes taking place without an associated code change should get approval from a super-reviewer, however.<br />
<br />
== Checking In ==<br />
After a patch has <tt>review+</tt> from two reviewers and <tt>superreview+</tt> from one of the Camino leads, it needs to be checked in. <br />
<br />
Check-ins for Camino can be made by any of the super-reviewers listed above as well as ardissone, froodian, hwaara and kreeger (note that josh and smfr are not currently checking in Camino patches, nor, with some exceptions, will pinkerton or mento check in patches they have not written). <br />
<br />
If no one is around to check in your patch after it has received the requisite approvals, add <tt>checkin-needed</tt> to the bug's Keyword field and one of the committers should notice and land your patch within a day or so.<br />
<br />
Also note that the <tt>mozilla/camino</tt> directory hierarchy is open for approved Camino check-ins regardless of the state of various trees and branches, with a few exceptions (tagging of major branches, red Camino tinderboxen, etc.).<br />
<br />
===A tip for checking in nibs===<br />
Sometimes a person who doesn't have CVS access will post a new or updated nib on a bug that needs to be checked in. The problem with this is that since a nib is technically a directory, there is a CVS folder inside the nib. If you attempt to check in a nib that has been changed by someone who has the <tt>CVSROOT</tt> set as "<tt>:pserver:anonymous@cvs-mirror.mozilla.org:/cvsrooot</tt>" (''e.g.'', everyone without cvs write access), you will receive an authorization error from cvs. The problem is that the <tt>CVS/Root</tt> file is set as the anonymous <tt>CVSROOT</tt>, not your "<tt>user%email.com@cvs.mozilla.org:/cvsroot</tt>" <tt>CVSROOT</tt>. The easiest way to fix this problem is to copy a Root file from one of the directories you have pulled to and paste it inside the <tt>Something.nib/CVS</tt> folder.<br />
<br />
===Trunk/branch mismatches===<br />
Sometimes (due mostly to Gecko changes on the trunk) the trunk and branch versions of a patch will diverge and you can't use cross-commit to land both places. '''If you're confident the branch patch has been well-tested''' and don't have a branch tree, you can pull just the files you need to commit (rather than pull an entire tree).<br />
<br />
# Set up your cvs environment as normal (i.e., <code>export cvsroot</code>)<br />
# <code>cvs co -r MOZILLA_1_8_BRANCH -d myfolder mozilla/camino/src/browser/foo mozilla/camino/PreferencePanes/Naviagtion/bar</code><br />
#: where <code>MOZILLA_1_8_BRANCH</code> is the branch tag, <code>myfolder</code> is the folder in which you want the stub tree to live, and <code>foo</code> and <code>bar</code> are the files contained in the patch<br />
# Apply the patch and commit the files "as normal"<br />
<br />
===Backing out a patch===<br />
Sometimes you accidentally commit something that shouldn't have landed yet, or sometimes (hopefully rarely) you commit something that breaks the tree and needs to be backed out. To back out a patch, follow these steps:<br />
<br />
# If you need to back out something only on the branch and have no branch tree (i.e., you check in using cross-commit), follow the steps above to grab a "stub" branch tree of the files the patch touched.<br />
# Consult bonsai for the correct backout command(s) to pull files (one per file) to run<br />
#: The "Show commands which could be used to back out these changes" link at the top of the appropriate bonsai page will give you the appropriate command, in the form of<br> <code>cvs update -j1.17.2.4 -j1.17.2.3 mozilla/camino/src/embedding/CHClickListener.mm</code><br>There will be one command per file (this particular example is a branch file, as you can see from the multiple sub-versions; the current [bad] version of the file is listed first and the previous [good] version is second)<br />
# <code>touch</code> each file <br />
# <code>cvs diff -u</code> the file(s) to sanity-check that the bad changes have been reverted in your local copy of the files<br />
# <code>cvs commit</code> "as normal"; this will commit a new copy of the file(s) with the incorrect change backed out</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Reviewing&diff=8810Development:Reviewing2008-01-30T17:39:33Z<p>Clawson: /* Coding for latest-OS-version features or using private APIs */ add spelling link</p>
<hr />
<div>Patch review in the Camino Project works a bit differently than in the rest of the Mozilla project. This document outlines the review process in Camino and whom to ask for reviews.<br />
<br />
== How Many Reviews? ==<br />
Typically, Camino requires three reviews on a patch before it is committed to the cvs repository: two normal reviews and one super-review. This rule can be overridden by any of the super-reviewers. The reason Camino requires two normal reviews is for greater visibility and to give reviewers a better understanding of more code.<br />
<br />
== Requesting Review ==<br />
When requesting review, always request an initial review from one of the reviewers listed [[#Reviewers and Owners|below]] and then, '''*after*''' (and only after) receiving <tt>review+</tt> from two of them, request super-review from one of the super-reviewers.<br />
<br />
It's a good idea to "target" a specific reviewer or super-reviewer; patches set to <tt>review?</tt> or <tt>superreview?</tt> with no email address entered in the corresponding '''Requestee:''' box tend to get lost. Check the list [[#Reviewers and Owners|below]] to see which reviewer(s) have expertise in the area(s) your patch touches; you will often get a review more quickly that way. You can also check [bonsai's cvs log] for the file(s) you're hacking and [bonsai's cvs blame] for the lines of code you're changing to see which reviewers have hacked or reviewed that code before.<br />
<br />
Also check the queue ([https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&requestee=&component=&group=type reviews], [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&requestee=&component=&group=type super-reviews]) to see which reviewers are "backed up" before requesting review or super-review; you might also ask on [irc://irc.mozilla.org#camino irc] if the reviewer can do a review/super-review first. If you are unsure of whom to ask or have other questions, please ask on [irc://irc.mozilla.org#camino #camino] on irc.<br />
<br />
Make sure your patch applies, builds, and works on the current trunk before requesting reviews (all development should be done on the trunk and backported to the branches if applicable). For patches which will land on one or more branches, verify that the Mac OS X and/or Gecko functions you use are available.<br />
:For instance, while the trunk supports only Mac OS X 10.4 and above (and requires the 10.4u SDK and gcc 4.0.1), the MOZILLA_1_8_BRANCH (Camino 1.6pre and Camino 1.5.x) must support Mac OS X 10.3.0 and above<!--, and Camino 1.0.x must support Mac OS X 10.2.8 as well-->. '''Patches that are designed to land on the MOZILLA_1_8_BRANCH or CAMINO_1_5_BRANCH (for security releases) and must use Mac OS X functions that are available in the 10.3.9 SDK and must compile with gcc 3.3.''' Similarly, many Gecko functions available on the trunk are either greatly enhanced over their counterparts on the MOZILLA_1_8_BRANCH, and many Gecko functions on the trunk do not exist at all on the MOZILLA_1_8_BRANCH. <br />
In any case where a patch is intended for landing on the trunk and the branch(es), you should ensure that the trunk patch will both apply properly and work on the branch(es); if not, you need to supply branch version(s) of the patch.<br />
<br />
To request review, set the '''review''' drop-down menu for your patch to '''?''' and then fill in the reviewer's email address in the '''Requestee''' field (you can do this when attaching your patch, or afterwards by clicking on the '''Edit''' link next to your patch in the bug's attachment table).<br />
<br />
Review is typically a process rather than a single event; reviewers will often request changes to your patch before they will approve it (by setting the '''?''' flag to '''+'''). A patch that does not meet with the reviewer’s approval will have its flag set to '''-''', and the reviewer will provide a list of problems or changes in the bug’s comments. A patch receiving <tt>review-</tt> is common, especially when you are just getting started with Camino. Make the changes the reviewer has requested, post a new patch, and request review again. Soon your patch will be ready for super-review and check-in to the repository.<br />
<br />
On occasion the reviewer will set the the '''?''' flag to '''+''' but also leave a comment with changes that need to be made to the patch (usually these are minor changes). When this happens, the reviewer feels that it is not necessary for him to re-review the patch with the changes. Instead, make the changes and post a new patch (obsoleting the old patch via the checkbox on the add attachment page), and set the <tt>review</tt> flag on the new patch to '''+''' yourself, with a comment like “carrying over r+ from $reviewer”. Also set set any other flags (a second review) to their values from the previous version of the patch, or set the <tt>superreview?</tt> flag.<br />
<br />
=== Code style ===<br />
<br />
''Link to Mozilla coding style guidelines as well as create some for Camino, so we avoid {{bug|308942}} comment 8 and 14 and {{bug|228840}} comments 15, 16, 18, and 19.''<br />
<br />
*[http://www.mozilla.org/hacking/mozilla-style-guide.html Mozilla Coding Style Guide]<br />
*[http://www.mozilla.org/MPL/boilerplate-1.1/ License block for new files]<br />
<br />
''Also link to [http://www.mozilla.org/hacking/ Hacking Mozilla] general intro somewhere in our contributor introduction''<br />
<br />
All new code should conform to Camino's style guidelines, which is a descendent of the Mozilla style guidelines (per decree by our leader):<br />
<br />
<pre><br />
if (foo) {<br />
bar;<br />
blam;<br />
}<br />
else {<br />
baz;<br />
zap;<br />
}<br />
</pre><br />
<br />
Braces for single statements are optional (and discouraged, but some still include them).<br />
<br />
We explicitly have no style rule regarding the placement of <tt>*</tt>. Aim to be consistent within a file in as much as the files are consistent.<br />
<br />
=== Coding for latest-OS-version features or using private APIs ===<br />
<br />
Each situation is unique, but we have provided some existing examples of various strategies employed to correctly code for these situations.<br />
<br />
The spell-checker's <code>learnWord:</code> method is undocumented, but is the only way to achieve proper learned spelling for the OS X system dictionary. [http://mxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#4472 Example code here].<br />
<br />
''spellcheck learn/add word, wherefrom metadata, quarantine extended metadata, what else?''<br />
<br />
====Situation====<br />
Description and mxr link<br />
<br />
=== Proper patch format ===<br />
<br />
Use <tt>cvs diff -u8N</tt> for patches to Camino code. Diffs should be done from <tt>/mozilla/camino</tt> or <tt>/mozilla</tt> for consistency and ease of application by reviewers and committers. All changes—including new source code files and project file changes, if applicable—should be submitted as a single patch (''e.g.'', <tt>cvs diff -u8N src/foo/bar src/baz/bam</tt>, with the exception of changes to <tt>.strings</tt> files, nibs, and images; see below for more about requirements for those three file types.<br />
<br />
====Adding new files in a patch====<br />
Sometimes the code you are writing requires the creation of new source files. In order to allow these files to be included in your single patch file, you must perform the additional step of <tt>cvs add</tt>ing the file, or, if you do not have cvs write privileges, of imitating the <tt>cvs add</tt> process.<br />
<br />
To make a patch including a new file (which otherwise requires write access to the repository), use [http://developer.mozilla.org/en/docs/Creating_a_patch#Including_new_files_in_a_patch cvsdo] to imitate the <tt>cvs add</tt> operation (alternatively add <code>/Foo.h/0/dummy timestamp//</code> to <tt>path/to/file/CVS/Entries</tt>), then diff as normal.<br />
<br />
To make a patch including files in new directories, first [''fill in the details''], then diff as normal.<br />
<br />
====Removing files in a patch====<br />
Sometimes your patch obsoletes existing files in the tree. <br />
<br />
''Instructions TBA''<br />
<br />
=== <tt>Localizable.strings</tt> ===<br />
<br />
Any UI string that appears in the code rather than in a nib needs to have an entry in <tt>Localizable.strings</tt> (or, in rare instances, a preference pane's <tt>Localizable.strings</tt> or one of the other <tt>.strings</tt> files). When writing new strings, always use “curly quotes” in the actual string text.<br />
<br />
Beginning with Camino 1.6a1 (23-Oct-2007 nightlies), we have converted all <tt>.strings</tt> files to UTF-8 <tt>.strings.in</tt> files which can be <tt>diff</tt>ed and which are then turned into UTF-16 <tt>.strings</tt> files in the build process. Any changes to <tt>.strings.in</tt> files should be included in your diff. Any new <tt>.strings</tt> files should be added to the tree as <tt>.strings.in</tt> files, converted to UTF-16 <tt>.strings</tt> files via the <code>STRINGS_FILES</code> mechanism in <tt>Makefile.in</tt>, and then add the resulting .strings files in <tt>generated/</tt> to the project in the appropriate places.<br />
<br />
====CAMINO_1_5_BRANCH====<br />
''Baring any critical security bugs requiring <tt>.strings</tt> changes, the '''CAMINO_1_5_BRANCH''' is string frozen, and no string changes should occur there. However, the following section describes the procedure to follow in the event such changes should be required.''<br />
<br />
If you make additions or changes to the <tt>Localizable.strings</tt> file, make a '''clear note''' in your comment when attaching your patch, indicating which strings should be added or changed. '''Do not attempt to <tt>diff</tt> the file''' (<tt>.strings</tt> files are UTF-16, which <tt>diff</tt> does not understand properly), and '''do not attach changed <tt>Localizable.strings</tt> files''' (which tend to become stale and cause regressions). <br />
<br />
It is also helpful to add a note to the bug's Status Whiteboard field pointing to the comment with the latest strings changes, e.g. <tt>[new strings in comment 23]</tt>.<br />
<br />
=== Project (<tt>Camino.xcodeproj</tt>) changes ===<br />
Making project changes has to be done using Xcode (when adding, deleting, or moving files, as well as changing most build/compiler options), specifically when adding files. After making any project changes, simply diff the project file as well and include it in your patch (if you made any changes to build configuration or settings, be sure to diff <tt>camino/config/</tt> as well to pick up xcconfig changes). Please check to ensure that your project patches do not change the state of the Camino.app entries in the Camino and CaminoStatic targets (this is usually a problem with srcdir configurations).<br />
<br />
(Removing files can be done by hand if you don't have the proper version of Xcode, but this isn't recommended because removing the obvious entries for files will still leave non-obvious entries in the project file and cause crashes/build failures.)<br />
<br />
====Adding Gecko build products to Camino and the project file====<br />
* If the item is "optional" module (e.g., extension) and is not built by default, fix up <tt>confvars.sh</tt> (on the branch, instead fix up the Camino section of <tt>configure.in</tt> and regenerate <tt>configure</tt>) to make Camino pull and build the item.<br />
** In some cases you can use an <tt>ac_add_options</tt> flag in your <tt>.mozconfig</tt> rather than patching <tt>confvars.sh</tt>/<tt>configure.in</tt>, but anything that's required to make Camino not burn when all is done needs to be declared in <tt>confvars.sh</tt>/<tt>configure.in</tt>.<br />
* If the item required <tt>confvars.sh</tt>/<tt>configure.in</tt> or <tt>.mozconfig</tt> changes, do a full rebuild of your tree.<br />
** You'll typically have to build both non-static and static unless you're intimately familiar with the location of build products and naming conventions<br />
* If the library or <tt>.xpt</tt> is something that seems relevant to all embeddors, <tt>embedding/config/basebrowser-mac-macho</tt> should probably be modified to deliver the build products to <tt>dist/Embed/*</tt> rather than <tt>dist/*</tt><br />
* Add the libraries to appropriate build target(s), and using "Relative to Project" paths when adding<br />
** In most cases you'll want to add to the non-static (default) and static target separately<br />
** There are separate folders in the Xcode "sources" tree for static and non-static libs, and for components and "regular" libs <!-- check this wrt the new project files--><br />
* Adding is best done from a <code>srcdir</code> build, but can be done with an <code>objdir</code> build if you carefully fix paths manually; note that in some cases Xcode will resolve symlinks when adding, so you'll have to fix the paths to point back to <tt>dist/Embed/*</tt> (or <tt>dist/*</tt>, if appropriate)<br />
* Move the products from Bundle Resources Copy Phase to the correct copy phase for that sort of Gecko product (for static builds, the static libs belong in the Libraries and Frameworks phase). Different versions of Xcode mis-guess the Copy Phase destinations in different ways.<br />
* Repeat the previous two steps for any <tt>.xpt</tt> files that the libraries might require<br />
* Check for, and remove if necessary, any bizarre changes to the header or library search paths that Xcode may have “helpfully” added for you.<br />
* Fix <code>nsStaticComponents.cpp</code> for static builds<br />
<br />
=== Nib changes ===<br />
<br />
Attach any changed nibs in a .zip archive (separate from the actual patch). Also upload a screenshot of the nib as it appears in the compiled app, using Cmd-shift-4 then space (to get a window-only screenshot). Some committers will want to re-create your changed nib before checkin, so make sure you indicate changes if they aren't obvious. Nibs only need a single review, but any significant changes should be discussed thoroughly on the bug and on IRC if possible. Bugs that contain only nib changes (cosmetic bugs) should request a super review; otherwise, they are unnecessary.<br />
<br />
When editing nibs, be sure to follow the guidelines in [[Development:Editing Nibs]]. Until further notice, '''all nib work should be done only in Interface Builder 2.5.x''' (preferably IB 2.5.4 under Mac OS X 10.4, as a number of features do not work properly in IB 2.5.6 under Mac OS X 10.5 and its nibs can load more slowly, but it can be run under in a pinch).<br />
<br />
== Reviewers and Owners ==<br />
Camino doesn't have traditional “module owners” like the rest of the Mozilla project does. However, below is a list of areas of code or functionality in Camino and reviewers/super-reviewers who are comfortable in those areas (items in '''bold''' are not formal Bugzilla components).<br />
<br />
* Annoyance Blocking:<br />
** '''Ad-blocking''': ardissone, smfr<br />
** '''Pop-up blocking''': murph, smorgan<br />
* Bookmarks: smorgan, cl<br />
* '''Build Config''': mento, ardissone<br />
* '''Cocoa UI''': <!--BruceD, -->Wevah, murph<br />
* Downloading: kreeger, smorgan<br />
* '''Gecko-related changes/CH-embedding''': hwaara, kreeger, smorgan<br />
* History: smfr, smorgan<br />
* HTML Form Controls:<br />
*: ''(these bugs are likely Core bugs that should be kicked to Widget:Cocoa in most cases)''<br />
* '''Input Methods (IME)''': smfr<br />
*: ''(Camino chrome only; content belongs in Widget:Cocoa)'' <br />
* Location Bar & Autocomplete: smorgan<br />
* '''Nib changes''': ardissone (''primarily layout/style and access conformance''), froodian<br />
* OS Integration:<br />
** '''AppleScript''': smfr, peeja<br />
** '''Feed handling''': kreeger<br />
** '''Spell-checking''': murph, smorgan <br />
* Page Layout:<br />
*: ''(these bugs are likely Core bugs that should be kicked elsewhere, or bugs in Camino arising from ad-blocking or build-config issues)''<br />
* Plugins: smfr, josh<br />
*: ''(though these bugs are most likely Core bugs that should be kicked elsewhere)''<br />
* Product Site: ss, Wevah, ardissone<br />
* Security: smfr, smorgan<br />
* Tabbed Browsing: smorgan, jeff, froodian<br />
* Toolbars & Menus: froodian, cl<br />
* Translations: marcello<br />
<br />
Do not let the list above limit your choice of reviewers; '''all regular Camino contributors can review any patch''' (with the exceptions listed below; also, a reviewer may decline to review certain patches due to schedule issues or if the patch is fairly complex and touches code the reviewer is very unfamiliar with). <br />
<br />
<!--'''In addition to the reviewers listed above, initial reviews can be requested from''' jpellico, aschulm or delliott.<br />
--><br />
'''Exceptions:'''<br />
<br />
* Smokey Ardisson [ardissone] does not review code changes outside of project patches, but will test patches.<br />
* Samuel Sidler [ss] also does not review code changes. He should sign-off on all Product Site changes.<br />
* Asaf Romano [Mano]'s review is also accepted in Camino, but he is not currently reviewing Camino patches. <br />
* Check with Josh Aas [josh] before requesting review or super-review from him.<br />
* Simon Fraser [smfr] is not currently reviewing or super-reviewing Camino patches, unless you are notified otherwise.<br />
* Mike Pinkerton [pinkerton] is currently only super-reviewing patches.<br />
<br />
== “Super” Reviews ==<br />
There are four people who can give super-reviews in Camino, the four project leads: Mike Pinkerton, Simon Fraser, Mark Mentovai, and Josh Aas (Simon Fraser is not currently reviewing or super-reviewing Camino patches). A super-reviewer can review a patch in any part of Camino. Additionally, Stuart Morgan can be targeted for super-review on any simple or moderate-sized patch with little Gecko impact.<br />
<br />
Nib changes associated with code changes do not typically require super-review; reviewers should test the nib thoroughly to make sure it satisfies all the conditions in the [[#Nib changes|Nib changes]] section above (or request a separate review on the nib from one of our nib specialists). Nib changes taking place without an associated code change should get approval from a super-reviewer, however.<br />
<br />
== Checking In ==<br />
After a patch has <tt>review+</tt> from two reviewers and <tt>superreview+</tt> from one of the Camino leads, it needs to be checked in. <br />
<br />
Check-ins for Camino can be made by any of the super-reviewers listed above as well as ardissone, froodian, hwaara and kreeger (note that josh and smfr are not currently checking in Camino patches, nor, with some exceptions, will pinkerton or mento check in patches they have not written). <br />
<br />
If no one is around to check in your patch after it has received the requisite approvals, add <tt>checkin-needed</tt> to the bug's Keyword field and one of the committers should notice and land your patch within a day or so.<br />
<br />
Also note that the <tt>mozilla/camino</tt> directory hierarchy is open for approved Camino check-ins regardless of the state of various trees and branches, with a few exceptions (tagging of major branches, red Camino tinderboxen, etc.).<br />
<br />
===A tip for checking in nibs===<br />
Sometimes a person who doesn't have CVS access will post a new or updated nib on a bug that needs to be checked in. The problem with this is that since a nib is technically a directory, there is a CVS folder inside the nib. If you attempt to check in a nib that has been changed by someone who has the <tt>CVSROOT</tt> set as "<tt>:pserver:anonymous@cvs-mirror.mozilla.org:/cvsrooot</tt>" (''e.g.'', everyone without cvs write access), you will receive an authorization error from cvs. The problem is that the <tt>CVS/Root</tt> file is set as the anonymous <tt>CVSROOT</tt>, not your "<tt>user%email.com@cvs.mozilla.org:/cvsroot</tt>" <tt>CVSROOT</tt>. The easiest way to fix this problem is to copy a Root file from one of the directories you have pulled to and paste it inside the <tt>Something.nib/CVS</tt> folder.<br />
<br />
===Trunk/branch mismatches===<br />
Sometimes (due mostly to Gecko changes on the trunk) the trunk and branch versions of a patch will diverge and you can't use cross-commit to land both places. '''If you're confident the branch patch has been well-tested''' and don't have a branch tree, you can pull just the files you need to commit (rather than pull an entire tree).<br />
<br />
# Set up your cvs environment as normal (i.e., <code>export cvsroot</code>)<br />
# <code>cvs co -r MOZILLA_1_8_BRANCH -d myfolder mozilla/camino/src/browser/foo mozilla/camino/PreferencePanes/Naviagtion/bar</code><br />
#: where <code>MOZILLA_1_8_BRANCH</code> is the branch tag, <code>myfolder</code> is the folder in which you want the stub tree to live, and <code>foo</code> and <code>bar</code> are the files contained in the patch<br />
# Apply the patch and commit the files "as normal"<br />
<br />
===Backing out a patch===<br />
Sometimes you accidentally commit something that shouldn't have landed yet, or sometimes (hopefully rarely) you commit something that breaks the tree and needs to be backed out. To back out a patch, follow these steps:<br />
<br />
# If you need to back out something only on the branch and have no branch tree (i.e., you check in using cross-commit), follow the steps above to grab a "stub" branch tree of the files the patch touched.<br />
# Consult bonsai for the correct backout command(s) to pull files (one per file) to run<br />
#: The "Show commands which could be used to back out these changes" link at the top of the appropriate bonsai page will give you the appropriate command, in the form of<br> <code>cvs update -j1.17.2.4 -j1.17.2.3 mozilla/camino/src/embedding/CHClickListener.mm</code><br>There will be one command per file (this particular example is a branch file, as you can see from the multiple sub-versions; the current [bad] version of the file is listed first and the previous [good] version is second)<br />
# <code>touch</code> each file <br />
# <code>cvs diff -u</code> the file(s) to sanity-check that the bad changes have been reverted in your local copy of the files<br />
# <code>cvs commit</code> "as normal"; this will commit a new copy of the file(s) with the incorrect change backed out</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8799Development:Third-Party Preference Panes2008-01-29T01:30:59Z<p>Clawson: remove Copy Headers bit, since we don't want to encourage use of anything outside PPB, and that ships in the sample</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class would be <code>ComJohndoeAwesomeprefs</code>.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). <br />
Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8798Development:Third-Party Preference Panes2008-01-29T01:29:59Z<p>Clawson: more revisions per smorgan</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
We do make every effort to ensure the compatibility and stability of methods in PreferencePaneBase.<br />
<br />
==Creating the Xcode project==<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class would be <code>ComJohndoeAwesomeprefs</code>.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). <br />
Using Camino methods other than those defined in PreferencePaneBase is explicitly discouraged; other classes can and do change without notice and should ''not'' be relied on to be stable across Camino versions.<br />
<br />
Logically, it follows that <code>PreferencePaneBase.h</code> is a required header if you decide to use any of its methods. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-01-23:Agenda&diff=8778Status Meetings:2008-01-23:Agenda2008-01-23T15:47:58Z<p>Clawson: /* 1.6b3pre */ add bug 371895</p>
<hr />
<div>Wed 23 Jan 9am PST (17:00 GMT/UTC) in #camino-mtg<br />
<br />
==General Plans==<br />
* Camino 1.6b2<br />
** Released Friday to software update, Tuesday to the world<br />
*** See [http://www.ardisson.org/afkar/2008/01/22/camino-2008-week-3/ this] for the story behind the release; great work by all involved<br />
** [http://talkback-public.mozilla.org/reports/camino/CM16b2/index.html Talkback] ([http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=&vendor=MozillaOrg&product=Camino16&platform=MacOSX&buildid=2008011814&sdate=&stime=&edate=&etime=&sortby=stack&rlimit=500 all 1.6b2 crashes]—only 7 so far)<br />
** Need to make sure we're getting more user coverage<br />
* Camino 1.6b3<br />
** Start working on follow-ups from recent big landings<br />
** Need to land remaining two big features ASAP<br />
** Feature/l10n freeze is b3<br />
** What P1/P2 features won't make it?<br />
** What 10.5 [[#Other (if there's time)|UI integration]] fixes do we want?<br />
*** Need call for designers to get mockups for 10.5 tab/bookmark bar refresh<br />
** please help out with any nib/strings bugs<br />
** Watch changes to perf when landing nibs<br />
* Camino 1.6<br />
** [[Development:Planning:Camino 1.6|Scoping]]<br />
*** Most of Tab Scrolling is done, as is AppleScript (P3)<br />
***: Patch up for one of two remaining AS follow-ups we really want (peeja)<br />
*** swupdate: only minor stuff left, but starting to find new bugs with a1/b1->b2 updates<br />
***: Ts regression {{bug|405542}}), appcast script ({{bug|401474}}), '''testing via b2'''<br />
*** jeff has been poking the tab dragging code<br />
***: new patch posted Tues<br />
*** batwood's multiple accounts patch (finally!) landed<br />
***: starting to file follow-ups; batwood's time is limited near-term<br />
*** murph should have a solution to fully establish a working key-view loop throughout the browser window<br />
***: following-up on search bugs<br />
*** ardissone made progress on AppleScript feed handlers thanks to mento and peeja<br />
***: in sr queue (smorgan); will need to file exec stuff for later<br />
*** symbol-stripping bug<br />
***: landed Tuesday; today's nightlies should be good. switching to gcc4/10.3.9 for ppc?<br />
*** breakpad: mento was going to talk to ted about server-side stuff (and write our handlers); smorgan was going to write the reporter<br />
***: updates?<br />
* [[Releases:1.5.5:Links|Camino 1.5.5]]/[[Releases:1.5.4:Links|Camino 1.5.4]]<br />
** Next Gecko release scheduled for [http://wiki.mozilla.org/Releases 5 Feb]. We need to push some crash fixes with it (close tabs, quit; Trash button crashes); ardissone will try to start triage/testing/landing this week<br />
** [http://talkback-public.mozilla.org/reports/camino/CM154/index.html Talkback] for 1.5.4<br />
*** topcrasher (#1, #2, and #8) already fixed; it's on quit, but it's pretty heavy<br />
**** The change that caused it landed on the MOZILLA_1_8_BRANCH one month before we spun 1.5.4 RC build. Are we not getting enough testing of the branch?<br />
*** Flash is #3<br />
*** Crash on quit ("pass-the-buck" Core {{bug|349463}}) is #4 (bsmedberg has a trunk patch!)<br />
*** #5 is assorted libobjc crashes<br />
<!--*** #6 is asstd libSystemB crashes, mostly related to plug-ins (Flash, QT, Divx, F4M)<br />
*** #7 is a 10.5.1 Flash-related crash, possibly all 1 user<br />
*** #8 is a random hex, AppKit/JEP/metadata<br />
*** #9 is libobjc, all pretty random except for one 1passwd<br />
*** #10 is FillFontInfoFromCMAP, possibly related to Asian fonts--><br />
<!--<br />
*** 5 of 20 [http://tinyurl.com/2e3b3o libobjc] (#3) crashes are 1passwd<br />
*** libSystemB (#4) {{Bug|401835}} is plugin-related (where there are constant stacks; we have some emails, if there's anything we might ask them)<br />
*** CoreFoundation (#5)<br />
*** DesktopServicesPriv (#6) - {{bug|402169}}, random hex + DesktopServicesPriv + Spotlight (#7)<br />
*** Cocoa (#9) - random crashes on 10.5<br />
*** [http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsDocumentObserverList::RemoveElement&vendor=MozillaOrg&product=Camino15&platform=All&buildid=2007080914&sdate=&stime=&edate=&etime=&sortby=bbid nsDocumentObserverList::RemoveElement] (#10) - {{bug|395916}} (Smokey emailed the two we have an email for, asking for Camino Diagnostics and more info); there's also a live user in the [http://forums.mozillazine.org/viewtopic.php?t=600994 forum]<br />
--><br />
** Still cleaning up stuff from the website switch; file bugs against Product Site if you see anything.<br />
* Tinderboxen<br />
** no new news on binus or maya?<br />
** ss has replacement minis for binus (to run 10.3) and mayaTrunk; mini-binus is in the colo but not accessible(?); mini-mayaTrunk will go to the colo after Christmas(?)<br />
** cb-miniosx01 has Ts disabled due to paging/low installed RAM<br />
** we should think about setting up a testerbox to catch Core bugs breaking embedding APIs (mini-mayaTrunk alternate builds?)<br />
* Dev docs<br />
** Chris got another round of comments on the [[Development:Third-Party_prefPanes]] docs; still some issues with the sample code<br />
** Can we get a quick list of some examples in our code (mxr links) of various ways of <br />
*** Calling private APIs<br />
*** Writing safe code for latest-OS-only features<br />
**: Add [[http://wiki.caminobrowser.org/Development:Reviewing#Coding_for_latest-OS-version_features_or_using_private_APIs|here]]; we're getting more patches wanting to do these things, so even if "the" solution cannot be prescribed, examples of various situations and techniques will help<br />
* Weekly Bugs and Queues update<br />
** Another stellar week of bug-fixing and queue management, but please keep eye on follow-up bugs (and reviews for them).<br />
<br />
==Specific bugs that need action==<br />
<br />
=== 1.6b3pre ===<br />
* {{bug|408593}} - Only check for the default browser once<br />
** Re-discuss, with mento's objections?<br />
* {{bug|413501}} - Provide a one-per-version startup warning about problem hacks<br />
* {{bug|371895}} - Flashblock whitelist - has patch, been rotting since October -- what's the holdup?<br />
<br />
=== 1.5.5 ===<br />
* nothing right now<br />
<br />
===Other (if there's time)===<br />
<br />
* 10.5 Visual UX<br />
** Bookmark bar - {{bug|401340}}<br />
** Tab bar<br />
** Toolbar icons - {{bug|384725}}<br />
** App icon lines - {{bug|402967}}<br />
<br />
* UNCOs<br />
** {{bug|376930}} - Overflow tab menu covers whole upper right part of my screen<br />
*** Need to find a way to "promote" this as an area we'd like user feedback on in 1.6a1 (we note this as a feature on the preview site)<br />
* '''Trunk'''<br />
** Need to keep an eye on trunk regressions, determine if they're Camino-only or partly/wholly Core, and consider requesting blocking1.9? for the latter set.<br />
** xpfe cleanup<br />
*** see older Agendas if you're interested <!--<br />
*** {{bug|383085}} has a patch to remove a number of xpfe directories<br />
*** stefanh has a "build finishes, crashes on startup" MOZ_XUL_APP [http://hem.fyristorg.com/s_her/camino/camino-test.diff patch]<br>[4:16pm] stefanh: "<Standard8>stefanh, so, my guess is you need to implement something like http://mxr.mozilla.org/seamonkey/source/suite/app/ (nsSuiteApp.cpp, application.ini, Makefile.in) somewhere in camino"<br>[4:16pm] stefanh: "stefanh, when you flip the flags, the main things that'll affect you immediately are the startup code, command line handlers and possibly alerts<br>[4:16pm] stefanh: stefanh, so xpfe/components/startup/ -> toolkit/components/commandlines toolkit/components/startup etc"<br>[4:17pm] stefanh: ardissone|ish: feel free to play with the code :P --><br />
<br />
==Queries==<br />
<br />
===Camino 1.6b3===<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b3%3F Blocking ?] (11) {{greyText|[-3 since last week]}} <!-- subtract FIXED here, except when only FIXED on trunk --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b3%2B Blocking +] (1) {{greyText|[unchanged]}} <!-- {{greyText|not including some parts of swupdate}} subtract FIXED here--><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b3- Blocking -] (0) {{greyText|[unchanged]}} <!-- --><br />
<br />
===Camino 1.6===<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs targeted at 1.6] (27) {{greyText|[-5 since last week]}} <!-- --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%3F Blocking ?] (6) {{greyText|[+1 since last week]}} (mostly bugs not on the 1.6 list that need evaluation) <!-- (subtract FIXED here, except when only FIXED on trunk --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%2B Blocking +] (1) {{greyText|[-1 since last week]}} (but [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&priority=P1&chfieldto=Now P1 bugs]—currently just tab dragging—are blocking) <!-- subtract FIXED here--><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6- Blocking -] (0) {{greyText|[unchanged]}} <!-- --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=---&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs without target] (553) {{greyText|['''+13''' since two weeks ago]}} <!-- '''first “CLOSEME” cleanup in a month'' --><br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&resolution=FIXED&resolution=---&chfieldfrom=2008-01-16&chfieldto=2008-01-23&chfield=resolution&chfieldvalue=FIXED Bugs fixed since last meeting] ('''28''') {{greyText|[+8 since last week]}} ('''19''' were 1.6-targeted, 2 were website, 1 was trunk-only) <!-- , 4 were trunk-only, including 2 serious regressions) --><br />
<br />
==Queues==<br />
<br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (8) {{greyText|[+1 since last week]}} <!-- '''1 untargeted''' --><br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] (2) {{greyText|[+1 since last week]}} <!-- (oldest now waiting for two weeks) (only 7 are 1.5 bugs) --><br />
<br />
<!-- <br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&keywords_type=allwords&keywords=checkin-needed&chfieldto=Now checkin-needed] (0) {{greyText|[-1 since last week]}}<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&status_whiteboard_type=allwordssubstr&status_whiteboard=project&chfieldto=Now project patch(es) needed] (0) {{greyText|[-1 since last week]}} --><!-- --></div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8709Development:Third-Party Preference Panes2008-01-09T02:25:37Z<p>Clawson: /* Creating the Xcode project */ add screenshot for new project assistant</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
In Xcode's New Project Assistant (see below), scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next and continue through the Assistant.<br />
<br />
[[Image:Newproject.png]]<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class would be <code>ComJohndoeAwesomeprefs</code>.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). This means that <code>PreferencePaneBase.h</code> is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=File:Newproject.png&diff=8708File:Newproject.png2008-01-09T02:24:40Z<p>Clawson: Screenshot of the New Project dialog in Xcode, showing the appropriate plug-in to use for preference pane development</p>
<hr />
<div>Screenshot of the New Project dialog in Xcode, showing the appropriate plug-in to use for preference pane development</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8707Development:Third-Party Preference Panes2008-01-09T02:14:17Z<p>Clawson: more updates</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning. You'll also want to be familiar with the basics of preference pane development, for which Apple has provided [http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/ an excellent tutorial] as well.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward. Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
In Xcode's New Project Assistant, scroll down and expand the "Standard Apple Plug-ins" group and select "PreferencePane", then click Next.<br />
<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. Go to Xcode's Project menu and select "Edit Active Target", which will bring up the Target Info window. Click on the Properties tab and you'll be able to change the creator code, as seen in the screenshot below:<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
You should also ensure that your classes have unique names, as class name conflicts can also be a problem. Continuing with the above example, your preference pane's class would be <code>ComJohndoeAwesomeprefs</code>.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|Nib Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods directly, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class (which is, in turn, a subclass of the standard AppKit NSPreferencePane class). This means that <code>PreferencePaneBase.h</code> is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher.<br />
<br />
You'll also need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Calling Gecko functions directly from a third-party preference pane is somewhat more involved. You'll still need to link against the appropriate libraries, but rather than copying the headers, which is likely to be a big headache (there are a great number of interdependencies amongst Gecko's header files, and it's easy to miss one), you'll probably be better off adding appropriate paths to the HEADER_SEARCH_PATHS parameter in Xcode's Target Info window. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* Anything with C++ code in it built by gcc 4 won't run on Mac OS versions prior to 10.3.9. If you need to deploy on 10.3.8 or lower, you'll need to select an earlier gcc version.</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-01-02:Agenda&diff=8685Status Meetings:2008-01-02:Agenda2008-01-02T16:55:21Z<p>Clawson: /* 1.5.5 */ make it clear that 1.5.5 does not include "other" immediately below</p>
<hr />
<div>Wed 02 Jan 9am PST (17:00 GMT/UTC) in #camino-mtg<br />
<br />
==General Plans==<br />
* Camino 1.6a1<br />
** [http://talkback-public.mozilla.org/reports/camino/CM16a1/index.html Talkback] ([http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=&vendor=MozillaOrg&product=Camino16&platform=MacOSX&buildid=2007120712&sdate=&stime=&edate=&etime=&sortby=stack&rlimit=500 all 1.6a1 crashes])<br />
** Are we getting enough user coverage? Talkback suggests no using the nsCOMPtr_base crashes for a comparison (only 56 crashes total)<br />
* Camino 1.6b1<br />
** Moving feature/l10n freeze from b1 to b2 and doing a b1 soon (to get more testing in general, and specifically on swupdate)?<br />
** What P1/P2 features won't make it?<br />
** What 10.5 [[#Other (if there's time)|UI integration]] fixes do we want?<br />
*** Need call for designers to get mockups for 10.5 tab/bookmark bar refresh<br />
** l10n freeze, so all strings/nib changes must be done by beta; please nominate these<br />
** please help out with any P1s (see query below)<br />
* Camino 1.6<br />
** [[Development:Planning:Camino 1.6|Scoping]]<br />
*** Most of Tab Scrolling is done, as is AppleScript (P3)<br />
*** swupdate: only minor stuff left: Ts regression {{bug|405542}}), appcast script ({{bug|401474}}), '''testing via b1'''<br />
*** jeff has been poking the tab dragging code; new WIP on {{bug|160720}} with animation<br />
*** batwood has patches for both of his 1.6 bugs (multiple accounts needs new patch after r-)<br />
*** murph has patches for search editor (needs new patch; update?) and OpenSearch (need smorgan [re]review); should have a solution to fully establish a working key-view loop throughout the browser window after that<br />
*** ardissone has been fighting Makefiles for AppleScript feed handlers<br />
*** breakpad: mento was going to talk to ted about server-side stuff (and write our handlers); smorgan was going to write the reporter<br />
* [[Releases:1.5.4:Links|Camino 1.5.4]]<br />
** Next Gecko release scheduled for [http://wiki.mozilla.org/Releases 5 Feb]. We need to push some crash fixes with it (close tabs, quit; Trash button)<br />
** [http://talkback-public.mozilla.org/reports/camino/CM154/index.html Talkback] for 1.5.4<br />
*** topcrasher (#1, #2, and #6) already fixed; it's on quit, but it's pretty heavy<br />
**** The change that caused it landed on the MOZILLA_1_8_BRANCH one month before we spun 1.5.4 RC build. Are we not getting enough testing of the branch?<br />
*** Crash on quit ("pass-the-buck" Core {{bug|349463}}) is #3 (bsmedberg has a trunk patch!)<br />
*** Flash is #4, #5 (the latter ultimately in Cocoa) <br />
<!--*** #6 is asstd libSystemB crashes, mostly related to plug-ins (Flash, QT, Divx, F4M)<br />
*** #7 is a 10.5.1 Flash-related crash, possibly all 1 user<br />
*** #8 is a random hex, AppKit/JEP/metadata<br />
*** #9 is libobjc, all pretty random except for one 1passwd<br />
*** #10 is FillFontInfoFromCMAP, possibly related to Asian fonts--><br />
<!--<br />
*** 5 of 20 [http://tinyurl.com/2e3b3o libobjc] (#3) crashes are 1passwd<br />
*** libSystemB (#4) {{Bug|401835}} is plugin-related (where there are constant stacks; we have some emails, if there's anything we might ask them)<br />
*** CoreFoundation (#5)<br />
*** DesktopServicesPriv (#6) - {{bug|402169}}, random hex + DesktopServicesPriv + Spotlight (#7)<br />
*** Cocoa (#9) - random crashes on 10.5<br />
*** [http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsDocumentObserverList::RemoveElement&vendor=MozillaOrg&product=Camino15&platform=All&buildid=2007080914&sdate=&stime=&edate=&etime=&sortby=bbid nsDocumentObserverList::RemoveElement] (#10) - {{bug|395916}} (Smokey emailed the two we have an email for, asking for Camino Diagnostics and more info); there's also a live user in the [http://forums.mozillazine.org/viewtopic.php?t=600994 forum]<br />
--><br />
** Still cleaning up stuff from the website switch; file bugs against Product Site if you see anything.<br />
* Tinderboxen<br />
** no new news on binus or maya<br />
** ss has replacement minis for binus (to run 10.3) and mayaTrunk; mini-binus is in the colo but not accessible(?); mini-mayaTrunk will go to the colo after Christmas<br />
** cb-miniosx01 has Ts disabled due to paging/low installed RAM<br />
** we should think about setting up a testerbox to catch Core bugs breaking embedding APIs (mini-mayaTrunk alternate builds?)<br />
* Weekly Bugs and Queues update<br />
<br />
==Specific bugs that need action==<br />
<br />
=== 1.6b1pre ===<br />
* {{bug|408593}} - Only check for the default browser once<br />
* {{bug|394651}} - Set "Accept cookies only from sites I visit" as default (dwitte fixed the Core problem; this can land whenever.)<br />
** any chance of the [https://bugzilla.mozilla.org/show_bug.cgi?id=404399 NSPR fix] needed to enable this landing on the branch, or should we just trunk-only it?<br />
<br />
=== 1.5.5 ===<br />
* nothing right now<br />
<br />
===Other (if there's time)===<br />
<br />
* {{bug|410193}} - cvs remove FindDialog.nib<br />
** Are we done with it?<br />
* {{bug|154580}} - Save URL of downloaded documents in comment<br />
** We can do this easily on 10.4 and up now; advantages are it's editable/copyable vs WhereFrom<br />
<br />
* 10.5 Visual UX<br />
** Bookmark bar - {{bug|401340}}<br />
** Tab bar<br />
** Toolbar icons - {{bug|384725}}<br />
** App icon lines - {{bug|402967}}<br />
<br />
* UNCOs<br />
** {{bug|376930}} - Overflow tab menu covers whole upper right part of my screen<br />
*** Need to find a way to "promote" this as an area we'd like user feedback on in 1.6a1 (we note this as a feature on the preview site)<br />
* '''Trunk'''<br />
** mainly the background drawing/tab-bleeding-on-10.4 bug ({{bug|406784}}) remains<br />
** Need to keep an eye on trunk regressions, determine if they're Camino-only or partly/wholly Core, and consider requesting blocking1.9? for the latter set.<br />
** xpfe cleanup<br />
*** see older Agendas if you're interested <!--<br />
*** {{bug|383085}} has a patch to remove a number of xpfe directories<br />
*** stefanh has a "build finishes, crashes on startup" MOZ_XUL_APP [http://hem.fyristorg.com/s_her/camino/camino-test.diff patch]<br>[4:16pm] stefanh: "<Standard8>stefanh, so, my guess is you need to implement something like http://mxr.mozilla.org/seamonkey/source/suite/app/ (nsSuiteApp.cpp, application.ini, Makefile.in) somewhere in camino"<br>[4:16pm] stefanh: "stefanh, when you flip the flags, the main things that'll affect you immediately are the startup code, command line handlers and possibly alerts<br>[4:16pm] stefanh: stefanh, so xpfe/components/startup/ -> toolkit/components/commandlines toolkit/components/startup etc"<br>[4:17pm] stefanh: ardissone|ish: feel free to play with the code :P --><br />
<br />
==Queries==<br />
<br />
===Camino 1.6b1===<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b1%3F Blocking ?] (14) {{greyText|[+3 since two weeks ago]}} <!-- subtract FIXED here, except when only FIXED on trunk --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b1%2B Blocking +] (1) {{greyText|[unchanged]}} <!-- {{greyText|not including some parts of swupdate}} subtract FIXED here--><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b1- Blocking -] (0) {{greyText|[unchanged]}} <!-- --><br />
<br />
===Camino 1.6===<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs targeted at 1.6] <!-- (31) {{greyText|[-5 since two weeks ago]}} --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%3F Blocking ?] (9) {{greyText|[+1 since two weeks ago]}} (mostly bugs not on the 1.6 list that need evaluation) <!-- (subtract FIXED here, except when only FIXED on trunk --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%2B Blocking +] (1) {{greyText|[unchanged]}} (but [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&priority=P1&chfieldto=Now P1 bugs]—currently just tab dragging—are blocking) <!-- subtract FIXED here--><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6- Blocking -] (0) {{greyText|[unchanged]}} <!-- --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=---&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs without target] (546) {{greyText|['''+5''' since two weeks ago]}} <!-- '''first “CLOSEME” cleanup in a month'' --><br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&resolution=FIXED&resolution=---&chfieldfrom=2007-12-19&chfieldto=2008-01-02&chfield=resolution&chfieldvalue=FIXED Bugs fixed since last meeting] ('''14''') {{greyText|[-6 since two weeks ago]}} (5 were 1.6-targeted), 2 were website, 1 was trunk-only) <!-- , 4 were trunk-only, including 2 serious regressions) --><br />
<br />
==Queues==<br />
<br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (16) {{greyText|[+1 since two weeks ago]}} <!-- '''1 untargeted''' --><br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] (2) {{greyText|[+1 since two weeks ago]}} <!-- (oldest now waiting for two weeks) (only 7 are 1.5 bugs) --><br />
<br />
<!-- <br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&keywords_type=allwords&keywords=checkin-needed&chfieldto=Now checkin-needed] (0) {{greyText|[-1 since last week]}}<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&status_whiteboard_type=allwordssubstr&status_whiteboard=project&chfieldto=Now project patch(es) needed] (0) {{greyText|[-1 since last week]}} --><!-- --></div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Status_Meetings:2008-01-02:Agenda&diff=8684Status Meetings:2008-01-02:Agenda2008-01-02T16:54:19Z<p>Clawson: /* 1.6b1pre */ dwitte fixed the core blocker behind 394651</p>
<hr />
<div>Wed 02 Jan 9am PST (17:00 GMT/UTC) in #camino-mtg<br />
<br />
==General Plans==<br />
* Camino 1.6a1<br />
** [http://talkback-public.mozilla.org/reports/camino/CM16a1/index.html Talkback] ([http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=&vendor=MozillaOrg&product=Camino16&platform=MacOSX&buildid=2007120712&sdate=&stime=&edate=&etime=&sortby=stack&rlimit=500 all 1.6a1 crashes])<br />
** Are we getting enough user coverage? Talkback suggests no using the nsCOMPtr_base crashes for a comparison (only 56 crashes total)<br />
* Camino 1.6b1<br />
** Moving feature/l10n freeze from b1 to b2 and doing a b1 soon (to get more testing in general, and specifically on swupdate)?<br />
** What P1/P2 features won't make it?<br />
** What 10.5 [[#Other (if there's time)|UI integration]] fixes do we want?<br />
*** Need call for designers to get mockups for 10.5 tab/bookmark bar refresh<br />
** l10n freeze, so all strings/nib changes must be done by beta; please nominate these<br />
** please help out with any P1s (see query below)<br />
* Camino 1.6<br />
** [[Development:Planning:Camino 1.6|Scoping]]<br />
*** Most of Tab Scrolling is done, as is AppleScript (P3)<br />
*** swupdate: only minor stuff left: Ts regression {{bug|405542}}), appcast script ({{bug|401474}}), '''testing via b1'''<br />
*** jeff has been poking the tab dragging code; new WIP on {{bug|160720}} with animation<br />
*** batwood has patches for both of his 1.6 bugs (multiple accounts needs new patch after r-)<br />
*** murph has patches for search editor (needs new patch; update?) and OpenSearch (need smorgan [re]review); should have a solution to fully establish a working key-view loop throughout the browser window after that<br />
*** ardissone has been fighting Makefiles for AppleScript feed handlers<br />
*** breakpad: mento was going to talk to ted about server-side stuff (and write our handlers); smorgan was going to write the reporter<br />
* [[Releases:1.5.4:Links|Camino 1.5.4]]<br />
** Next Gecko release scheduled for [http://wiki.mozilla.org/Releases 5 Feb]. We need to push some crash fixes with it (close tabs, quit; Trash button)<br />
** [http://talkback-public.mozilla.org/reports/camino/CM154/index.html Talkback] for 1.5.4<br />
*** topcrasher (#1, #2, and #6) already fixed; it's on quit, but it's pretty heavy<br />
**** The change that caused it landed on the MOZILLA_1_8_BRANCH one month before we spun 1.5.4 RC build. Are we not getting enough testing of the branch?<br />
*** Crash on quit ("pass-the-buck" Core {{bug|349463}}) is #3 (bsmedberg has a trunk patch!)<br />
*** Flash is #4, #5 (the latter ultimately in Cocoa) <br />
<!--*** #6 is asstd libSystemB crashes, mostly related to plug-ins (Flash, QT, Divx, F4M)<br />
*** #7 is a 10.5.1 Flash-related crash, possibly all 1 user<br />
*** #8 is a random hex, AppKit/JEP/metadata<br />
*** #9 is libobjc, all pretty random except for one 1passwd<br />
*** #10 is FillFontInfoFromCMAP, possibly related to Asian fonts--><br />
<!--<br />
*** 5 of 20 [http://tinyurl.com/2e3b3o libobjc] (#3) crashes are 1passwd<br />
*** libSystemB (#4) {{Bug|401835}} is plugin-related (where there are constant stacks; we have some emails, if there's anything we might ask them)<br />
*** CoreFoundation (#5)<br />
*** DesktopServicesPriv (#6) - {{bug|402169}}, random hex + DesktopServicesPriv + Spotlight (#7)<br />
*** Cocoa (#9) - random crashes on 10.5<br />
*** [http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsDocumentObserverList::RemoveElement&vendor=MozillaOrg&product=Camino15&platform=All&buildid=2007080914&sdate=&stime=&edate=&etime=&sortby=bbid nsDocumentObserverList::RemoveElement] (#10) - {{bug|395916}} (Smokey emailed the two we have an email for, asking for Camino Diagnostics and more info); there's also a live user in the [http://forums.mozillazine.org/viewtopic.php?t=600994 forum]<br />
--><br />
** Still cleaning up stuff from the website switch; file bugs against Product Site if you see anything.<br />
* Tinderboxen<br />
** no new news on binus or maya<br />
** ss has replacement minis for binus (to run 10.3) and mayaTrunk; mini-binus is in the colo but not accessible(?); mini-mayaTrunk will go to the colo after Christmas<br />
** cb-miniosx01 has Ts disabled due to paging/low installed RAM<br />
** we should think about setting up a testerbox to catch Core bugs breaking embedding APIs (mini-mayaTrunk alternate builds?)<br />
* Weekly Bugs and Queues update<br />
<br />
==Specific bugs that need action==<br />
<br />
=== 1.6b1pre ===<br />
* {{bug|408593}} - Only check for the default browser once<br />
* {{bug|394651}} - Set "Accept cookies only from sites I visit" as default (dwitte fixed the Core problem; this can land whenever.)<br />
** any chance of the [https://bugzilla.mozilla.org/show_bug.cgi?id=404399 NSPR fix] needed to enable this landing on the branch, or should we just trunk-only it?<br />
<br />
=== 1.5.5 ===<br />
<br />
===Other (if there's time)===<br />
<br />
* {{bug|410193}} - cvs remove FindDialog.nib<br />
** Are we done with it?<br />
* {{bug|154580}} - Save URL of downloaded documents in comment<br />
** We can do this easily on 10.4 and up now; advantages are it's editable/copyable vs WhereFrom<br />
<br />
* 10.5 Visual UX<br />
** Bookmark bar - {{bug|401340}}<br />
** Tab bar<br />
** Toolbar icons - {{bug|384725}}<br />
** App icon lines - {{bug|402967}}<br />
<br />
* UNCOs<br />
** {{bug|376930}} - Overflow tab menu covers whole upper right part of my screen<br />
*** Need to find a way to "promote" this as an area we'd like user feedback on in 1.6a1 (we note this as a feature on the preview site)<br />
* '''Trunk'''<br />
** mainly the background drawing/tab-bleeding-on-10.4 bug ({{bug|406784}}) remains<br />
** Need to keep an eye on trunk regressions, determine if they're Camino-only or partly/wholly Core, and consider requesting blocking1.9? for the latter set.<br />
** xpfe cleanup<br />
*** see older Agendas if you're interested <!--<br />
*** {{bug|383085}} has a patch to remove a number of xpfe directories<br />
*** stefanh has a "build finishes, crashes on startup" MOZ_XUL_APP [http://hem.fyristorg.com/s_her/camino/camino-test.diff patch]<br>[4:16pm] stefanh: "<Standard8>stefanh, so, my guess is you need to implement something like http://mxr.mozilla.org/seamonkey/source/suite/app/ (nsSuiteApp.cpp, application.ini, Makefile.in) somewhere in camino"<br>[4:16pm] stefanh: "stefanh, when you flip the flags, the main things that'll affect you immediately are the startup code, command line handlers and possibly alerts<br>[4:16pm] stefanh: stefanh, so xpfe/components/startup/ -> toolkit/components/commandlines toolkit/components/startup etc"<br>[4:17pm] stefanh: ardissone|ish: feel free to play with the code :P --><br />
<br />
==Queries==<br />
<br />
===Camino 1.6b1===<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b1%3F Blocking ?] (14) {{greyText|[+3 since two weeks ago]}} <!-- subtract FIXED here, except when only FIXED on trunk --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b1%2B Blocking +] (1) {{greyText|[unchanged]}} <!-- {{greyText|not including some parts of swupdate}} subtract FIXED here--><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6b1- Blocking -] (0) {{greyText|[unchanged]}} <!-- --><br />
<br />
===Camino 1.6===<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs targeted at 1.6] <!-- (31) {{greyText|[-5 since two weeks ago]}} --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%3F Blocking ?] (9) {{greyText|[+1 since two weeks ago]}} (mostly bugs not on the 1.6 list that need evaluation) <!-- (subtract FIXED here, except when only FIXED on trunk --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%2B Blocking +] (1) {{greyText|[unchanged]}} (but [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&priority=P1&chfieldto=Now P1 bugs]—currently just tab dragging—are blocking) <!-- subtract FIXED here--><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6- Blocking -] (0) {{greyText|[unchanged]}} <!-- --><br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=---&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs without target] (546) {{greyText|['''+5''' since two weeks ago]}} <!-- '''first “CLOSEME” cleanup in a month'' --><br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&resolution=FIXED&resolution=---&chfieldfrom=2007-12-19&chfieldto=2008-01-02&chfield=resolution&chfieldvalue=FIXED Bugs fixed since last meeting] ('''14''') {{greyText|[-6 since two weeks ago]}} (5 were 1.6-targeted), 2 were website, 1 was trunk-only) <!-- , 4 were trunk-only, including 2 serious regressions) --><br />
<br />
==Queues==<br />
<br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (16) {{greyText|[+1 since two weeks ago]}} <!-- '''1 untargeted''' --><br />
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] (2) {{greyText|[+1 since two weeks ago]}} <!-- (oldest now waiting for two weeks) (only 7 are 1.5 bugs) --><br />
<br />
<!-- <br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&keywords_type=allwords&keywords=checkin-needed&chfieldto=Now checkin-needed] (0) {{greyText|[-1 since last week]}}<br />
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&status_whiteboard_type=allwordssubstr&status_whiteboard=project&chfieldto=Now project patch(es) needed] (0) {{greyText|[-1 since last week]}} --><!-- --></div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8664Development:Third-Party Preference Panes2007-12-22T03:44:18Z<p>Clawson: /* Other potential gotchas and caveats */ add bug 358318</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward (thus requiring Mac OS X 10.3.9 or higher). Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own. If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class. This means that <code>PreferencePaneBase.h</code> is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher. ''[Will bad things happen if the prefpane and the app both have a copy of PreferencePaneBase.mm compiled into them? -cl]''<br />
<br />
In order for the -bundle_loader switch to do its job, you'll need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Using Gecko code in a third-party preference pane is somewhat more involved. You'll need to copy the proper headers (see above) and link against the appropriate libraries. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
* {{bug|358318}} can result in preference panes displaying values that are inconsistent with the actual preference value in about:config (or across preference panes) in certain circumstances. Patches are being accepted. :)</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8663Development:Third-Party Preference Panes2007-12-22T02:38:34Z<p>Clawson: /* Using Camino methods */ new screenshot done</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward (thus requiring Mac OS X 10.3.9 or higher). Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own. If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class. This means that <code>PreferencePaneBase.h</code> is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher. ''[Will bad things happen if the prefpane and the app both have a copy of PreferencePaneBase.mm compiled into them? -cl]''<br />
<br />
In order for the -bundle_loader switch to do its job, you'll need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Using Gecko code in a third-party preference pane is somewhat more involved. You'll need to copy the proper headers (see above) and link against the appropriate libraries. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
Crossing that bridge when we come to it...</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8662Development:Third-Party Preference Panes2007-12-21T22:42:22Z<p>Clawson: a few more <code> tags</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward (thus requiring Mac OS X 10.3.9 or higher). Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own. If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, your preference pane should subclass Camino's <code>PreferencePaneBase</code> class. This means that <code>PreferencePaneBase.h</code> is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile <code>PreferencePaneBase.mm</code> (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher. ''[Will bad things happen if the prefpane and the app both have a copy of PreferencePaneBase.mm compiled into them? -cl]''<br />
<br />
In order for the -bundle_loader switch to do its job, you'll need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this ''[needs to be re-screenshot -cl]'':<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in <code>[~]/Library/Application Suppport/Camino/PreferencePanes/</code>.<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Using Gecko code in a third-party preference pane is somewhat more involved. You'll need to copy the proper headers (see above) and link against the appropriate libraries. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
Crossing that bridge when we come to it...</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8661Development:Third-Party Preference Panes2007-12-21T22:38:10Z<p>Clawson: more revisions</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward (thus requiring Mac OS X 10.3.9 or higher). Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is <code>MOZC</code> (Camino's creator code) instead of the default <code>????</code>. You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own. If you use the provided project, make sure you change your preference pane's bundle identifier from <code>org.mozilla.caminoprefpane</code>, as bundle ID conflicts can prevent your pane from loading. Bundle identifiers generally take the form of <code>tld.developer.productname</code>, so your preference pane might be <code>com.johndoe.awesomeprefs</code>, for example.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, your preference pane should be a subclass of the Camino PreferencePaneBase class. This means that PreferencePaneBase.h is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile PreferencePaneBase.mm (in the Compile Sources phase of the target). This step is unnecessary if you plan to deploy your preference pane ''only'' for Camino 1.6 or higher. ''[Will bad things happen if the prefpane and the app both have a copy of PreferencePaneBase.mm compiled into them? -cl]''<br />
<br />
In order for the -bundle_loader switch to do its job, you'll need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in [~]/Library/Application Suppport/Camino/PreferencePanes/ .<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Using Gecko code in a third-party preference pane is somewhat more involved. You'll need to copy the proper headers (see above) and link against the appropriate libraries. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
Crossing that bridge when we come to it...</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8660Development:Third-Party Preference Panes2007-12-21T22:25:27Z<p>Clawson: /* Creating the Xcode project */ bundle ID must be unique</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward (thus requiring Mac OS X 10.3.9 or higher). Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is MOZC (Camino's creator code) instead of the default "????". You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own. If you use the provided project, make sure you assign your preference pane a unique bundle identifier (different from "org.mozilla.caminoprefpane"), as bundle ID conflicts can prevent your pane from loading.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, your preference pane should be a subclass of the Camino PreferencePaneBase class. This means that PreferencePaneBase.h is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile PreferencePaneBase.mm (in the Compile Sources phase of the target).<br />
<br />
In order for the -bundle_loader switch to do its job, you'll need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in [~]/Library/Application Suppport/Camino/PreferencePanes/ .<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Using Gecko code in a third-party preference pane is somewhat more involved. You'll need to copy the proper headers (see above) and link against the appropriate libraries. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
Crossing that bridge when we come to it...</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8659Development:Third-Party Preference Panes2007-12-21T22:23:13Z<p>Clawson: /* Disclaimer */ users' lolcats are also at risk</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward (thus requiring Mac OS X 10.3.9 or higher). Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat -- or your users' cats, or both -- on fire.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is MOZC (Camino's creator code) instead of the default "????". You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, your preference pane should be a subclass of the Camino PreferencePaneBase class. This means that PreferencePaneBase.h is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile PreferencePaneBase.mm (in the Compile Sources phase of the target).<br />
<br />
In order for the -bundle_loader switch to do its job, you'll need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in [~]/Library/Application Suppport/Camino/PreferencePanes/ .<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Using Gecko code in a third-party preference pane is somewhat more involved. You'll need to copy the proper headers (see above) and link against the appropriate libraries. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
Crossing that bridge when we come to it...</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8658Development:Third-Party Preference Panes2007-12-21T22:17:45Z<p>Clawson: more revisions</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
===Applicability and support===<br />
These instructions can be used by anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.5 onward (thus requiring Mac OS X 10.3.9 or higher). Developers may choose to support only Mac OS X 10.4+ or Camino 2.0pre+, but this is ''highly'' discouraged unless certain limitations of the Mac OS or Camino/Gecko code make supporting Mac OS X 10.3.9 or the Camino 1.5 branch impossible.<br />
<br />
===Disclaimer===<br />
These instructions are presented in good faith, but we make no guarantees as to the stability of Camino's APIs (even across minor versions), and we cannot guarantee preference panes developed using this guide will not set your cat on fire.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is MOZC (Camino's creator code) instead of the default "????". You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, your preference pane should be a subclass of the Camino PreferencePaneBase class. This means that PreferencePaneBase.h is a required header. If you plan to deploy your preference pane on Camino 1.5.x, you'll also need to compile PreferencePaneBase.mm (in the Compile Sources phase of the target).<br />
<br />
In order for the -bundle_loader switch to do its job, you'll need to tell the linker where it can find a Camino application. Using the Target Info window, point the linker's "Bundle Loader" to a copy of Camino on your hard disk. For example, if Camino is in your Applications folder, it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in [~]/Library/Application Suppport/Camino/PreferencePanes/ .<br />
<br />
==Using Gecko functions and methods==<br />
<br />
Using Gecko code in a third-party preference pane is somewhat more involved. You'll need to copy the proper headers (see above) and link against the appropriate libraries. ''[An example here would be great. -cl]''<br />
<br />
If there's something in Gecko you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our developers as much as possible.<br />
<br />
==Other potential gotchas and caveats==<br />
<br />
Crossing that bridge when we come to it...</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8657Development:Third-Party Preference Panes2007-12-21T21:48:51Z<p>Clawson: /* Using Camino methods */ cap</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
These instructions should work for anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.0.x onward.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is MOZC (Camino's creator code) instead of the default "????". You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, you'll need to tell the linker how to find a Camino application in order for the -bundle_loader switch to do its job. Again using the Target Info window, point the linker's "Bundle Loader" to a Camino app on your hard disk. For example, if Camino is in your Applications folder, inside a folder called "Internet", it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in [~]/Library/Application Suppport/Camino/PreferencePanes/ .<br />
<br />
==Other potential gotchas and caveats==<br />
* It is not currently possible to use Gecko code directly in third-party preference panes. If there's something you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our Cocoa developers as much as possible.<br />
<br />
==Error messages==<br />
<br />
===Undefined Symbols===<br />
<br />
''it compiles ok, but if it's in deployment mode I get an undefined symbol error'' [Is this still a problem with -bundle_loader? -cl]<br />
<br />
* Get info on your target (or project) and set "Other Linker Flags" to "-undefined dynamic_lookup" for all configurations<br />
* You only need the appropriate header files (the header files for the classes you're using/subclassing) if you're using -undefined dynamic_lookup; you don't need to link against the Gecko code (often, this is just PrefPaneBase.h)<br />
<br />
===Camino doesn't like my prefPane; it says it has to have a 'MOZC' signature===<br />
<br />
* Get Info on your prefpane target<br />
* Go to "Properties"<br />
* Change the "Creator" field to "MOZC" (without quotes)</div>Clawsonhttp://wiki.caminobrowser.org/index.php?title=Development:Third-Party_Preference_Panes&diff=8656Development:Third-Party Preference Panes2007-12-21T21:46:31Z<p>Clawson: preliminary work on actual instructions</p>
<hr />
<div>{{draft}}<br />
<br />
''See {{bug|384800}} for more information on the status of this page. The current how-to should not be attempted by people unfamiliar with Xcode and its related tools or the Camino codebase.''<br />
<br />
==Who should read this document?==<br />
Camino, per our mission statement, "is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users." This, along with the limited time available for our all-volunteer programming team to implement features, means that certain choices have to be made about what should and shouldn't be part of the Camino application itself. As with Firefox extensions, there are many opportunities for third-party developers to step in and provide niche features or UI for things that Camino doesn't provide by default. This document is intended to provide a jumping-off point for third-party developers interested in developing additional preference panes for Camino.<br />
<br />
==Getting started==<br />
These instructions assume a basic working knowledge of Apple's Developer Tools, including Xcode and Interface Builder, as well as the Objective-C language itself. If you are unfamiliar with these, [http://developer.apple.com/ Apple Developer Connection] is an excellent place to start learning.<br />
<br />
These instructions should work for anyone developing preference panes on Mac OS X 10.4 or higher, with Xcode 2.4.x or higher and Interface Builder 2.x or higher, to be deployed on any version of Camino from 1.0.x onward.<br />
<br />
==Creating the Xcode project==<br />
Camino's preference panes are standard Apple PreferencePanes with a small twist: their creator code is MOZC (Camino's creator code) instead of the default "????". You can change this in the Properties tab of Xcode's Target Info window (see screenshot).<br />
<br />
[[Image:Properties.png]]<br />
<br />
We've put together a [CBSamplePane.zip sample Xcode project] (download size) for developers to use when writing preference panes for Camino. Feel free to use this project as a starting point, or make your own.<br />
<br />
==Laying out the UI==<br />
<br />
In order to keep the UI of your preference panes as consistent as possible with the preference panes shipped with Camino itself, please use our [[Development:Editing_Nibs|NIB Editing Guide]] as a reference for laying out the UI when developing preference panes for Camino.<br />
<br />
==Using Camino methods==<br />
<br />
If you plan to use any of Camino's methods, you'll need to tell the linker how to find a Camino application in order for the -bundle_loader switch to do its job. Again using the Target Info window, point the linker's "Bundle loader" to a Camino app on your hard disk. For example, if Camino is in your Applications folder, inside a folder called "Internet", it would look like this:<br />
<br />
[[Image:Setting-path.png]]<br />
<br />
If you have multiple copies of Camino, point it to the oldest one you plan to support with your preference pane.<br />
<br />
You'll also need to copy over any Camino header files for methods you're using in your preference pane. You can add them to the Copy Headers phase of the project, like this:<br />
<br />
[[Image:Adding-files.png]]<br />
<br />
That's it! You should be able to build the project and test your preference pane with Camino. Remember to re-launch Camino after placing the preference pane in [~]/Library/Application Suppport/Camino/PreferencePanes/ .<br />
<br />
==Other potential gotchas and caveats==<br />
* It is not currently possible to use Gecko code directly in third-party preference panes. If there's something you really need to use that simply doesn't have a Cocoa wrapper on it in Camino, please bring it to our attention. We may be willing to add wrapper code for it, since one architectural goal we have for Camino is to hide Gecko from our Cocoa developers as much as possible.<br />
<br />
==Error messages==<br />
<br />
===Undefined Symbols===<br />
<br />
''it compiles ok, but if it's in deployment mode I get an undefined symbol error'' [Is this still a problem with -bundle_loader? -cl]<br />
<br />
* Get info on your target (or project) and set "Other Linker Flags" to "-undefined dynamic_lookup" for all configurations<br />
* You only need the appropriate header files (the header files for the classes you're using/subclassing) if you're using -undefined dynamic_lookup; you don't need to link against the Gecko code (often, this is just PrefPaneBase.h)<br />
<br />
===Camino doesn't like my prefPane; it says it has to have a 'MOZC' signature===<br />
<br />
* Get Info on your prefpane target<br />
* Go to "Properties"<br />
* Change the "Creator" field to "MOZC" (without quotes)</div>Clawson