| Line Item | SWAG | Description |
|---|---|---|
| B.5 | 24 days |
Improve Helper Application Management
|
| G.1 | 4 days |
Improve the "Plug-in Finder" Experience
|
| G.2 | 5 days |
Polish Reveal Location Functionality
|
| G.3 | 10 days |
Polish Unknown Content Type Dialog/Experience
|
| G.4 | 2 days |
Better Windows Integration
|
| G.5 | 3 days |
Enable Users to Automatically Launch Executables
|
| Printing Line Items | ||
| A.1 | 15 days |
Print Preview (1 of 2, BE and FE)
|
| A.2 | 5 days |
Page Setup (BE and FE)
|
| A.3 | 2 days |
Fit to Page Print Option (BE and FE)
|
A.4 | 5 days |
Print Preview (2 of 2, BE and FE)
|
This set of features relate to the "Helper Applications" preference panel.
The "features" listed under this line item can be categorized as follows:
Specifically, "reflecting" OS-defined helper applications.
Specifically, "importing" settings from 4.x.
Specifically, "reflecting" registered helper apps and user decisions, and "Fix bugs."
Re: Making it work the way it is supposed to
This is bug fixing and not addressed by this plan.
Re: Automatically import settings from 4.x:
The only place this can happen is when migrating a 4.x profile, or, optionally when creating a new profile. It can apply in the latter case because the Communicator settings are actually stored on a per-machine (or per-Windows-user) basis so we could extract that information for every new profile, not just ones explicitly "copied" from a specific Communicator profile.
Regardless, this is a Profile Manager feature and will not be addressed by this plan.
Re: Helper Applications Pref Panel feature(s)
The current implementation of this panel is based on the mimetypes.rdf file, which contains only browser-specific helper application entries. Currently, this information is manipulated as a generic RDF datasource, by code in 3 places:
To merge the OS-defined settings, we need to create a new RDF data source that encapsulates the OS settings (requires separate implementation for each platform), and another datasource that merges that new one with current mimeTypes.rdf data.
This feature is the only work addressed by this plan (and the detailed Task and Issues lists, below).
Broken down into subtasks:
Broken down into subtasks:
The additional work here to deal with that additional datasource:
Helper app meta bug dependency tree
This item pertains to the behavior of the "default plug-in" that gets used for <embed> tags for which no plug-in can be found. Gecko/embedding plans to enhance that default plugin with support that will automatically download and install a number of popular plugins. That will be accomplished by tying into support provided by servers at netscape.com (or somewhere else in aol.com).
That feature will not require any "front end" work aside from the UI that the default-plugin/plugin-finder-plugin provides.
There is one bit of related "front end" work that needs to be done: Tie into that same service when appropriate content types are encountered elsewhere. That is, in contexts aside from use with <embed> or <object> tags. For example, this will apply in cases where the user clicks on a link to a stand-alone Acrobat file.
This triggers display of the "unknown content" dialog (aka "helper app launcher dialog") where we currently offer the option to launch an already installed application, or to save the content locally. We need to add a third option: to find a plug-in that can handle the content.
Choosing that option would then trigger the same thing that happens when such content is encountered within a "plugin" (<embed> tag).
The first sub-item is trivial, of course (provided we can agree on the precise wording). There is a potential problem if the button would grow too wide (thus making the dialog wider).
The second sub-item would appear to be more work, and require independent Mac and Windows implementations (see below under "Issues" for discussion of the situation on Linux). I have taken a glance at the Win32 shell APIs and it seems that selecting a file in a folder is possible. The Mac will likely require a bit less effort because the Finder APIs are better/simpler. However, Mac OS X may require yet another implementation that will be rolled into this subtask.
I believe we should use this item to encompass a more substantial overhaul of the nsIMIMEService and nsIMIMEInfo implementations.
Currently, we have (at least) 3 sets of code that uses low-level RDF to manipulate the mimeTypes.rdf file that sits behind the "Unknown Content Type Dialog" and the Helper Applications pref panel. It would be better to move that code into the nsIMIMEInfo so that it can be re-used.
Further, Line Item B5, "Improve Helper Application Management" requires us to encapsulate the OS settings for "mime types" in a new RDF data source. That data source replicates much of the function implemented in parts of the URI loader. The URI loader should be modified to take advantage of the new data source.
Given that, the next step is to do the "polish." The main thing that needs to be done is to "fix" the Edit and New Type dialogs so that they are consistent in terms of the fields they display and the way they behave. Each has some flaws, currently (e.g., New Type doesn't let you turn off the "Always ask me", "Edit type" doesn't let you change the mime type). A single dialog can suffice, with some code to deal with the separate "modes."
That would facilitate the generic "make it easier" requirement(s).
We will not address the specific requirement that users be able to change "always ask me" on a per-mimeType basis on the pref panel. That requires some major expenditure of effort to extend the dialog and the benefit seems negligible. There is a prominent Edit button there that opens a dialog with the checkbox on it. When the user is asked, there is a checkbox that enables them to specify "don't ask me any more." I suspect that what prompted this "requirement" was the lack of this capability in Netscape6.0/6.01. If still lacking, that is simply a bug.
The second sub-item is already implemented (modulo bugs; I did verify that it is still working OK on Windows in 6.1).
The first sub-item could be implemented in a number of ways. The simplest is probably to detect when the "download directory path" pref is empty and then pick a reasonable default. We could probably pick a reasonable default on Mac and Linux, too, while we're at it.
I think it is preferable to pose an extra dialog in this case (rather than add wording to the current dialog that could be too easily missed by the user).
The implementation should be easy enough. Currently, the code checks that the file and disables "Launch" if it is executable. Instead, we'd just wire that button so that it opened another "Are you sure?" dialog whose "Yes" button did the launch.
There is one other situation: clicking on a link to an executable. Currently, that goes straight to the file picker (and then the download progress dialog). If we're going to permit launching applications, we should also permit that to happen "directly" (i.e., download and run from temporary location without prompting the user for a destination). This change would require a tweak to the code that currently bypasses the "unknown content type dialog" and the insertion of similar "verify before launch" logic, as described above, in that dialog (at the point where the user chooses to "open" the content).
Adding the "Print Preview" menu choice, by itself, is trivial. The menu choice will be enabled/disabled in parallel with the existing Print... menu choice. It is unclear whether this menu choice will be available only in Navigator or also in Mail/News, though. The assumption here is that we're adding it to Navigator only.
That menu choice, when enabled, will either open a new "Print Preview" window, or, change the current window to "print preview mode." The former appears at this time to be vastly simpler to implement and is the course we plan to take.
The new (or existing window), is put in "print preview mode" by QI'ing the nsIWebBrowser (or some other object?) for the nsIWebBrowserPrint interface and calling that interface's ShowPrintPreview method. That method returns an nsIPrintPreviewNavigation interface, which then provides the methods that advance through pages, etc.
Unfortunately, that's all in theory. nsIWebBrowserPrint doess not currently declare the method ShowPrintPreview. It appears that this was supposed to be fixed per bug 72691 but that bug was closed (perhaps erroneously). So the method needs to be added, and more importantly, implemented. That would seem to be a "BE" (back end) task.
Once the proper interfaces are in place and implemented, then it should be relatively straightforward to implement the new window. We will implement that window using any simplifying assumptions that can materially reduce the work involved, while not materially reducing the value to the user. For example, it may turn out to be necessary to make the Print Preview window "modal" to the browser window from which it is opened. E.g, if it turns out that subsequent navigation on that parent window raises significant stability issues.
This large task is broken down into the following subtasks:
This feature involves adding a new "Page Setup..." choice to the main menu under File, at the beginning of the section with Print... (and the new Print Preview...). This menu choice, when selected, will open a modal "Page Setup" dialog that will prompt for page printing options:
These options correspond to the various methods and attributes of the nsIPrintOptions interface. The implementation will simply pre-fill the dialog from the current print options, and after the user selects Ok, will set the new option values back into that object (it is a service).
One of the difficulties here is deciding how/where to surface this feature in the UI. It seems that there are only 2 reasonable places to do so:
This is where the user currently specifies what to print (all pages, certain pages, selection). We should add another section to the dialog (note that we are already adding the "print selection" stuff) with a checkbox and text input labelled "compress printed material to fill N pages" (or equivalent). The native dialog is currently part of the "back end" (BE) so this plan will not address adding this feature.
The user is most likely to want to use this feature when previewing the print output. That's because it is difficult prior to that to know how many pages the selected material will take to print without it being compressed. In addition, the user will certainly want to see how the material will look after being compressed to the specified number of pages.
So this plan is restricted to addressing only this incremental feature/add-on to the Print Preview window discussed above. This also means that the work described here cannot be done prior to completion of much of the work described there.
To implement this, the nsIPrintPreviewNavigation interface will need to be enhanced with methods/attributes that can be used to specify how many pages the printed material should span. This plan assumes that method (or methods) are in place.
re: Zooming in Print Preview...
The following is based on the following presumptions:
This means that implementing this feature will be relatively straightforward.
re: Frame printing options in print preview...
The options are already offered via the nsIPrintSetting interface so this feature should just require front-end work.
2 days
Note that this greatly magnifies the risk since it basically depends not only on the two new features being implemented, but on them working together.