breadcrumbs: Design Documents > page_name: appmode-mac title: Mac App Mode (draft)
Chromium provides a way to create a “custom” browser shortcut for any web site (not yet implemented on Mac). Our ultimate goal for the Mac implementation is to make such a shortcut appear to be first-class application. In particular, its UI should consist of a browser displaying the specified web site, but with many “normal” browser features removed (no bookmarks, navigation, a custom menu bar, etc.). Usage examples include Gmail, Reader, Facebook, and so on.
The following are absolutely essential:
The following would be nice to have:
[work in progress, more to come -Trung]
[sorry for the mess, work in progress -Trung]
Old stuff:
Gears provides an way to create desktop shortcuts to web sites (Desktop.createShortcut()). Chromium expands on this to try and make a “custom” browser for the site. Our ultimate goal for the Mac implementation is to have the shortcut appear to the OS as a first-class application. Its UI consists of a browser displaying the website but with many of the browser features removed (ie-no bookmarks, navigation, etc.). Examples would be “applications” such as Gmail, Reader, etc.
The desired user experience is:
The desired technical details are:
Make each AppMode shortcut a little Cocoa app bundle. The binary itself would be extremely small. When launched, it would find Chromium.app, load it as a bundle, and invoke an exported system to relay the shortcut info. The vended API from w/in Chromium.app would start up Cocoa, WebKit, etc. This would keep the “binary contact” between the shortcuts and Chromium as small as possible so they don't have to be updated w/ new versions of Chromium. The shortcut app would effectively be another instance of Chromium in “browser” mode, maintaining an independent set of renderers, plugin hosts, etc.
Make each AppMode shortcut a little app that simply launches the Chromium application (if not already running), sends over the shortcut info, and exits.
Rather than creating a separate application, create a new document type that the Finder recognizes as a Chromium document to store the site location. When the user double-clicks the a saved shortcut document, the Finder (through LaunchServices) automatically sends a message to Chromium, launching it first if it's not already running. Chromium responds to the open event by creating a new window with AppMode chrome and disabling the navigation menu items when that window is in the foreground. This window will co-exist in the same browser process as other non-AppMode windows, thus can share the profile and data stores.
Rather than trying to load and sub-load parts from another application bundle, have the shortcut be a full copy of the Chromium application.
Shim Apps to sub-load Chromium does require a long term contract around the interface used to find, load, and invoke the real browser. If we ever needed changes to the Cocoa info.plist or different arguments, we‘d have to find ways to handle this without the AppMode stub being updated (as the running user might not have privledges to rewrite it). Make a Full-blown Copy has a major drawback; the inability to update the shortcut applications. Keystone/Omaha requires a one-to-one mapping from GUID to installed application, and self-generated GUIDs would receive no updates as they don’t match the GUID on the server. So once a copy was made for a short cut, there wouldn't be a way to target it for updates (feature, security, etc).
Hybrid solutions: There are a number of possible hybrid solutions. For example, one could make a persistent Launcher App which, instead of quitting immediately after launching, persists and performs tasks such as “forwarding” Dock activations to the main browser process. One should also be able to switch out the main menu on the demand, and such an model would allow a better imitation of a full-fledged application. (One could also imagine other hybrids, e.g., a Launcher App which just opens an embedded Shortcut Document. This has certain flexibility advantages; see below.)
Launcher/Copy: Another possible hybrid is a Launcher App which simply launches, for each specific App Mode shortcut, a copy of Chromium with special settings/command-line arguments. This would avoid the major drawback of a true copy, yet provide most of the benefits. (It would still have the drawback of making sharing storage/cache/etc. difficult.) This is very similar to a Shim App, but with no binary contact. It would be lightweight on disk space requirements (though lack of cache sharing might make increase disk space usage); memory usage would hopefully be similar to a Shim App, in that perhaps text pages could be shared, and hopefully lighter than that of a Full-blown Copy.
Flexibility and upgradeability: Regardless of model, it is worth considering how App Mode capabilities may be modified/upgraded (possibly changing models) in the future. In general, Shim and Launcher Apps seem most flexible; upgrading a Shortcut Document might be troublesome. A possible upgrade model is as follows: Upon loading, the Shim/Launcher App locates the primary Chromium application bundle and checks if this bundle contains a more up-to-date Shim/Launcher App. If necessary, it can then update itself, and relaunch. (This assumes that the App Mode data is well-segregated inside the Shim/Launcher App's bundle.)
“Captivity”: A problem with a web app posing as a normal application is that web apps are typically not captive, in the sense that there‘s usually no clear delineation of where the application ends. For example, in a native mail client, clicking on a link will take one outside the mail program. Likewise, it either has calendar functionality built-in, or it doesn’t. With a “Gmail App”, things are not so clear. What should happen if one clicks on “Calendar”? If one has a separate “Calendar App” set up, perhaps one would like it to launch or switch to that. Perhaps one would view it as integral to the “Gmail App”. Or perhaps one would prefer that it be opened in a regular browser window. (Worse, one might prefer different things for different links, even within the same “site”, however sites are delineated. For example, one may want “Docs” to be a separate app, but keep “Calendar” in the same app.) With web apps, of course, there are also usually many external links. Probably one would usually want to open external links in a regular browser window, but it is not clear how to distinguish between the different cases (open in current app, open in different app, open in a regular browser window).
Shortcut Documents, Launcher Apps, and variants skirt this problem by not truly distinguishing between different App Mode windows and the regular browser. The distinction made is very weak: an “application” is just a window in the regular browser with a few special properties. It is then very easy to open normal browser windows running with one's normal browsing profile. Depending on the approach, there may be no real distinction between an App Mode window running, e.g., Gmail from one running Calendar or Docs.
The Shim App, etc. approaches which provide more full, separate applications suffer here. For example, if one is in Gmail and one clicks on a link to, say, Flickr, not only does one probably want Flickr to open in a normal browser window (unless one has a Flickr App set up!), but one probably also wants it to open using the profile associated with one‘s normal browser -- one doesn’t typically want to maintain have separate Flickr logins between one‘s Gmail App and one’s normal browser. (On the other hand, one might want distinct Gmail logins!)
Other considerations: In addition to making the Dock icon, menus, etc. work, it would be good if an App Mode shortcut worked properly with Spaces. In particular, one can assign a particular space to each application (e.g., one space for the “Gmail App” windows and a different space for normal Chromium browser windows). The general lack of API for Spaces means that only Shim Apps, full-blown copies, and perhaps the Launcher/Copy hybrid could work properly with Spaces.