[upstream] recent documents don't sort the reopen documents of OpenOffice.org

I stand to be corrected, since I am no expert by any means, but I think the
content of the Places menu is controlled by Nautilus.

Would someone confirm or correct me?

openoffice should update the list when opening something, reassigning the bug

I think that if you open a file since Gnome or nautilus ---> use the associate extension of Gnome, then the Recent Documents must be updated.
But if you open a file since the specified application, then Recent Documents mustn't be updated.

I think that if a application (Nautilus or Recent Documents or other generalist file software) use the Gnome API association file extension to open file with its specified program, then is the Gnome API who must update the Recent Documents list.

If the application is only gnome (gedit, ...) then it is possible that the application update Recent Documents, but is very difficult that applications that run in other places (OpenOffice.org, KDE applications, Windows applications with WINE, ...) update the Recent Documents theyself.

I think that is Gnome who must update the Recent Documents when use the association extension file.

Other programs and systems:

If you open a file since Adobe Acrobat, the Recent Documents is not updated.
If you open a file since Adobe Acrobat in MS Windows, the Recent Document IS updated.

When you download a file since Firefox, the Recent Documents is not updated.
When you download a file since Firefox in MS Windows, the Recent Documents IS updated.

I think the problem is in the system Gnome and not in each application.

I believe that this bug has been corrected in Ubuntu hardy openoffice.org 1:2.4.0~rc2-1ubuntu3 so I am marking it as Fix Released. If after upgrading you continue to have problems with this issue then feel free to reopen this bug.

Thanks,

Chris Cheney

The bug is in Ubuntu 8.04 Hardy Heron.
I have run the Beta version (5-april-2008) with the CD-Live and the problem continue.

Ok, If the file is a .png all is OK, you reopen the .png file in Recent Documents and the name.png go to first position.

But if you reopen a .odt file (or .odp, .ods, ...) the file don't change position.

More, if you open a file from Archive-Open in OpenOffice.org, the file isn't put in Recent Documents. If you download a file with Firefox, the file isn't put in Recent Documents.

The problem is that Gnome must control the opened files in the system and put the name in Recent Documents.

More, in MS Windows the Recent Documents is forever in alphabetic order, the opened order is count internally for erase the file name in the 10th position when open a new file, if reopen file, the Recent Documents not change, only change the internal opened order.

Bye.

Ok, I have been able to reproduce it. It is interesting, probably an upstream bug but I will have to look into it further.

If you reopen the same file using File->Open then it works properly. However if you reopen the file using File->Recent Documents in OOo it doesn't cause it to go back to the top of the list in Gnome.

Oh yea, I also see that opening the file using Places->Recent Documents doesn't cause it to resort to the top of the list either, which I think was what the original bug report was about.

Not only OpenOffice.org.

If you reopen html documents (opened with Firefox), not file name go to first position.

The error is in not include a function in API function for open the files, then each application that open a file, necessary go to append or reorder the recent documents.

Seems like this is one of this bugs, which will newer be fixed. Just because canonical can't do it, the better do some nonsense like notify-osd. And Sun will newer do it, because they wont to make a new makeup... so all sort of busy.

This is fixed in openoffice.org (1:3.2.0-7ubuntu4)

Opening from either the Recent Documents or opening the file directly, the file will now appear on top of the list.