17502 - [feature] Implement "Recent Files" submenu under "File"

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P2)

Description

[Charles Manske]

We absolutely, positively need this feature! I implemented it in Gromit and
miss it dearly. We have 10 prefs for saving the last-edited file URLs and their
titles. These are used to fill a "Recent Files" submenu (under "Open" on the
File menu) so user can reopen recently-edited files.
Beth: Please put this on the schedule. Maybe M14?

Comment 1

[rubydoo123]

setting to M15 - post betat push

Comment 2

[Charles Manske]

Changing to M14.

Comment 3

[rubydoo123]

moving to m17

Comment 4

[Charles Manske]

This isn't that difficult. We better get the guts implemented as it is a 
"new feature", so moving to M16. It requires adding new menu item
to the File menu, so we want strings to be done for M16 as well.

Comment 5

[rubydoo123]

updating priority and severity for beta 2 radar

Comment 6

[Charles Manske]

I will checkin:
the file menu item and strings and the JS InitRecentFilesMenu()" method today.
Kathy has voluntered to help.
Todo: Fill in InitRecentFilesMenu() to build the menu from values stored in
prefs.
Write methods to save the Title and URL of each page we open into the prefs,
doing the appropriate search for existing item in the prefs and shuffling so
the most recently edited page is at the top of the list, except, of course
in an editor window that is open with that page.

Comment 7

[Charles Manske]

I checked in the menu item and JS stub to build the menu in 
InitRecentFilesMenu() in EditorCommands.js

Comment 8

[Phil Peterson]

[nsbeta2+ until 5/16] 

Comment 9

[Matthew T (active 1999-2002)]

You could make this feature a lot more usable by doing this:

`File' > `Open' submenu
-----------------------
  _Location ...    Ctrl+L
  _File ...        Ctrl+O
-------------------------
  {recent file 1}
  {recent file 2}
  {recent file 3}
  {recent file 4}
  {recent file 5}
  {recent file 6}

This would:
* simplify the `File' menu by making it two items shorter (merging `Open
  File', `Open Location', and `Recent Pages');
* make Composer more consistent with other apps, which only have one `Open' item
  in their `File' menus (not three);
* make the Recent Files feature more likely to be used, as the recently-opened
  files would be visible when the user opened the `File' > `Open' submenu
  (rather than the user having to guess whether the file they wanted was one of
  the most recent ones, before they chose which menu item to select);
* remove the need for extra code to enable/disable the `Recent Pages' submenu
  depending on whether there or not there were any Recent Pages to show (the
  submenu would always be enabled, because it would have the `Open Location ...'
  and `Open File ...' items in it as well);
* remove the need for the `Recent Pages' string altogether.

Comment 10

[Charles Manske]

I really like Matthew's suggestion. I could complete it by 6/1 if Kathy has
more important drag/drop and context menu work to complete for Beta2.
My only change would be to put the "File..." item first in the submenu, since
this will be the more common action. Note that the "previously-edited" list
below will have both local and remote URLs, so there' no required association
between them and the "File..." and "Location..." items.

Comment 11

[Matthew T (active 1999-2002)]

It would be a good idea to do this as an overlay, so that Navigator (and maybe 
other components) could use it as well. The recently-opened files list (Composer) 
and the recently-Opened URLs list (Navigator) should probably be one and the same 
thing.

Comment 12

[Charles Manske]

No, I totally disagree. A "recently-edited" file/url list should not interact 
with "recently-visited" URLs of the browser -- the latter is "history" and 
would completely flood the usefullness of Composer's list.

Comment 13

[Matthew T (active 1999-2002)]

Sorry, my mistake. For `recently-Opened URLs list (Navigator)', read
`recently-opened local files list (Navigator)'.

Comment 14

[Charles Manske]

While that's certainly a better suggestion, I'm still not sure if it's 
worth the extra effort. IMHO, monitoring URLs loaded into just Composer seems
the most appropriate implementation.

Comment 15

[Kathleen :Brade]

Hurricane offered to help look into this.

Comment 16

[Charles Manske]

Great. Be sure to follow Matthews new "Open>" submenu plan -- Jennifer Glick
also thought that was a good idea. I think the order should be:
  _File ...        Ctrl+O
  _Location ...    Ctrl+L
-------------------------
  _1 {recent 1}
  _2 {recent 2}
  _3 {recent 3}
  _4 {recent 4}
  _5 {recent 5}
  _6 {recent 6}
  _7 {recent 7}
  _8 {recent 8}
  _9 {recent 9}

We should store up to 10 URLs and TITLES. Display the page TITLE if not empty,
otherwise display th URL. Don't include the currently-open page, thus 
most pages will have 9 items, except for an unsaved new page.

Comment 17

[Matthew T (active 1999-2002)]

> We should store up to 10 URLs and TITLES.

Charley, if we counted in hexadecimal, would you be recommending up to 16 URLs 
and TITLEs because we happened to have 16 numeric keys on the keyboard? Or if we 
were living in the Babylonian era, would you be recommending up to 60 URLs and 
TITLEs??? The reason I chose 6 was because it matches with the 7 +/- 2 item 
short-term memory of most humans, so it's easy to scan. If you're going to use 
another number, that's fine, just make sure you have a good reason.

> Don't include the currently-open page

No, you *should* include any currently-open documents in the submenu. The submenu 
should also have check marks next to items for currently-open documents, to 
indicate their open status.

I can give you a spec for what to do in the general case of a user opening a file 
which is already open, but that's really a separate bug because it's not 
restricted to the Recent Files feature.

Just as a side note: This isn't a `new' submenu plan -- it's part of an *old* 
draft of the Aphrodite menu spec, one which has since been superceded by assuming 
(for the sake of further simplifying the menus) that there will be access to 
recently-opened files in the Open dialog itself. But that's quite hard to do XP 
in the real world, so it makes sense for Seamonkey to use my old ideas instead of 
my new ones right now. :-)

Comment 18

[Charles Manske]

My 10 file suggestion was arbitrary -- it happens to be what I implemented in
gromit. The "7" rule is irrelevant -- there is no UI-memory going on here, since 
the items are always changing. That rule, which I do think is important, is for
helping users remember "normal" items in menus that are always there.
Akanna suggested that this number should be a use pref. I have no strong opinion
other than it should be at least 6 or 7. 10 seemed convenient since it maps to
the keys 1 through 0 on the keyboard.
I said you shoudn't include the currently open "page" (singular) -- the file
you are editing. There's obviously no point to including that, correct?
Of course you should include other pages that may happen to be open in other 
windows.
And as far as being "new", it is a "new idea" relative to the current mozilla
spec. I really don't if it came from Aphrodite or whereever -- I'm just trying
to give you credit for suggesting a good idea, that's all!

Comment 19

[Matthew T (active 1999-2002)]

The number is a user pref in programs like MS Word, but you could get your 
stopwatches out in the usability lab and find the best number to use for real 
life. You'd end up (given sufficient data) with a graph like this:
        A
Average |\
time to | \      optimum      _____
open a  |  `._      |    ,-'"'
file    |     `"`--.|.-''
        +-----------|-------------->
  Number of items in Recent Files menu

I don't know what the optimum number would be, but it might well be less than 
ten.

> I said you shoudn't include the currently open "page" (singular) -- the file
> you are editing. There's obviously no point to including that, correct?

There's just as much point in wanting to open multiple copies of the file which 
is open in the current window (e.g. to make multiple varied copies of it) than 
there is in wanting to open multiple copies of a file which is open in any other 
window (e.g. to make multiple varied copies of it).

Comment 20

[Charles Manske]

This is turining into an interesting UI discussion!
We will definitely NOT allow muliple copies of the same file to be open in 
different windows, at least not in the first version. To do that, you first have
to *force* user to do "save as" otherwise, you end up with the "changes in > 1
window" conflict: user edits in window 1 and saves changes. Then goes to window 
2, makes different changes, and presses "Save". Which changes win? In fact, we
have a dialog that will pay attention to the filestamp time and prompt the
user to resolve this kind of conflict, which is possible by editing in Composer
at the same time as, say, notepad.
If the user wants to save to different versions, they should do "Save As" to
a new filename (URL), as soon as they do that, the "recent files" list will 
show the previous Title/filename (since it will no longer be the current 
window's document) and they can open it there. So we shouldn't include the URL 
of the open page in its own "recent url" list".
If user doesn't change the Title, which is what we should show in the menu,
we should probably append "-1", "-2" to differentiate between them in both the
recent menu items and probably also in the window's titlebar.
When you move through the menuitem in the "recent url" list, we should display
its URL in the status line.

Comment 21

[Matthew T (active 1999-2002)]

+---------------------------------------------------------+
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
+---------------------------------------------------------+
| /!\ The file "The Odyssey of King Fred" is already open |
| `"' in Composer.                                        |
|                                                         |
|     If you make changes to this copy of the file, you   |
|     should save it under a new name or in a different   |
|     folder.                                             |
|                                                         |
| [?] ( Open Read-Only )   ( Cancel ) (( Open New Copy )) |
+---------------------------------------------------------+
- `Open Read-Only' opens the document in a window which does not allow any
  editing until the document is saved. It does not need to be implemented for
  this version.
- `Cancel' cancels the opening, and instead brings the first window with the file
  in to the front.
- `Open New Copy' opens a new copy of the document, but the new copy behaves just
  like an unsaved document -- the first time `Save' is chosen in the new window,
  the Save dialog is opened, rather than just overwriting the other copy.

Now, that wasn't that painful, was it? It doesn't require the user to save the 
file under a different name from the beginning, so they don't get annoyed if they 
didn't want to save it at all (for example, if they're making a couple of memos 
just to print out, memos which are based on the same template).

You still have the problem of what to do if the user tries to Save As a file 
which is already open -- but you already had that problem anyway, and you can 
probably figure out the solution to that yourselves. :-)

Comment 22

[Matthew T (active 1999-2002)]

Correction: `If you make changes to this copy of the file' --> `If you make 
changes to the new copy of the file'.

Comment 23

[Hurricane]

Alright, well I'm watching this bug and doing some work on it, but until I know 
which way we want to go for this feature I can't do much. What's going to be 
the final resolution to this UI issue? :) - Hurricane

Comment 24

[Ben Goodger (use ben at mozilla dot org for email)]

I don't see how the clutter induced by the 'Open Location' dialog is remedied by 
moving 'Open File' into a submenu. File opening is a very common action in 
document editors, and it seems to me to be a mistake to shift this into a 
submenu. A simple click and drag should allow the user to invoke the open 
dialog. What shall we do next, move Save and Save As into a submenu to save an 
item?

My text editor has these items:

Open
Open from the Web
Recent Files >

I recommend something similar. I understand that this has another item in the 
toplevel (open from the web) but this being a webpage editor, this is hardly 
surprising. Most other webpages editors have many more menu items. While we're 
at it, what is 'save as charset...' and why does it deserve more prominence than 
Open File...?

Comment 25

[Matthew T (active 1999-2002)]

> File opening is a very common action in document editors, and it seems to me to
> be a mistake to shift this into a submenu. A simple click and drag should allow
> the user to invoke the open dialog.

If you're using a document editor, you're very likely to be using the keyboard, 
in which case Ctrl+O is much more accessible than even a main menu item; so it's 
really a moot point. And there's also a big fat `Open' button on the toolbar, is 
there not?

> What shall we do next, move Save and Save As into a submenu to save an item?

Well, that's another thing that Aphrodite used to do (but doesn't any more) ...

>                                                        While we're at it, what
> is 'save as charset...' and why does it deserve more prominence than Open
> File...?

`Save as charset' is for saving the current document in a particular character 
set. It shouldn't be in the File menu; it should be a popup menu in the file 
dialog. Unfortunately, the relevant programmers don't have the time to put such a 
popup menu in the file dialog on each platform, so there it is. Gak.

Hurricane -- It's not my call, but I'd suggest just go and implement this thing, 
with 10 items, and including currently-open items with checkmarks (where 
selecting an open item just switches to that window). The issues of (a) whether 
10 is too many, and (b) exactly how to handle opening already-open items, can be 
worked out later.

Comment 26

[leger]

hurricane is working on this.  Major complaint in 4.x environment.  Low risk, 
3 days finish.

Comment 27

[leger]

Putting on [nsbeta2-] radar.  Pulling from 5/16...did not make beta2 feature 
train.

Comment 28

[rubydoo123]

putting on beta3 train

Comment 29

[Charles Manske]

Hurricane: Please implement this as described in my comments on 
2000-05-02 15:16 and 2000-05-26 16:37.

Comment 30

[Kathleen :Brade]

regarding Charley's comments on 5/2:  I believe others have suggested to 
Hurricane that it'd be better to store them in rdf rather than prefs.

regarding Charley's comments on 5/26:  I personally do not like the idea of 
moving Open to a sub-menu.  This is inconsistent with other components (like 
Navigator).  We chose not to change the toolbar menu (even though we all have 
different toolbars) so I don't see why we'd change the Open items.

Comment 31

[Charles Manske]

I asked hyatt long ago about storing them in RDF and at the time he said there
was no reason to do that -- he even thought it would be less efficient for some
reason.
About the Open submenu: I don't really care. I agree it makes it different from
browser, but other modules don't have any open items.
Should we start a newsgroup item about the issue?

Comment 32

[Matthew T (active 1999-2002)]

Brade -- the inconsistency with other components would perhaps be better resolved 
by giving the other components one of these menus too, rather than by just 
leaving Composer how it is. :-) (Navigator's Open submenu would contain
recently-typed URLs, Chatzilla's Open submenu would contain recently-visited chat 
rooms, the Address Book's Open submenu would contain recently-edited address book 
cards ...)

Comment 33

[Hurricane]

I understand all of you are very anxious for this bug to be resolved and I'm 
working my hardest on it with my available time. Please choose another person 
to work on this bug if it is required to be completed within the next two weeks 
(worst case scenario). I'm currenty taking finals and priority one is not 
Mozilla :) -- Just tell me what you guys think and I'll either keep working or 
I'll find another issue that I can resolve and that isn't so pressing. - 
Hurricane

Comment 34

[Charles Manske]

I'll do it this afternoon.

Comment 35

[Charles Manske]

Attachment: Implementation suggestion for "Recent Pages"

Comment 36

[Charles Manske]

Hurricane wil still work on this bug. I've attached a simple implementation
that he will review and/or improve.

Comment 37

[Charles Manske]

Attachment: Better implementation - actually works!

Comment 38

[Charles Manske]

Hurricane:
I attached a diff for a version that actually works.
I talked to hyatt about using RDF instead of prefs -- the reason he thought
it would be more difficult is because you had to do some C++ to create an 
RDF datasource. But apparently you can do that now, although he didn't see
any real reason why we shouldn't just use prefs. I'll let you explore that 
issue if you wish. 
Note that I did not use a new "Open" submenu as Matthew suggested. I'm
beginning to agree with Kathy that we shouldn't.

Comment 39

[rubydoo123]

reassigning this to hurricane since he will be the implementor of this feature. 
 Ryan, please review the code options that Chraley submitted, feel free to 
rewrite/rework/modify as you believe is necessary.

Comment 40

[Hurricane]

Thanks for the help Charles Manske! I think I'll use the prefs for the recent 
files menu. I'll get it done over the weekend.

Comment 41

[Ryan Cassin]

Woo hoo! This is finally fixed and the code for recent files menu is in the 
6/28 build! Thanks A WHOLE TON to cmanske and brade who helped me out big time 
with this bug! One snag (which will been filed in another bug): the recent 
files menu isn't updated after doing a Save or Save As. Hopefully this can be 
worked out relatively soon. I'm currently working on getting the prefs for the 
recent files menu up and running, but the pref panel for the composer window is 
a bit flaky...look for those prefs to pop up in the near future, though! In the 
mean time, 10 recent files in the menu is an acceptable default. ENJOY! :-)

Comment 42

[sujay]

verified in 6/29 build.