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

[Guillermo Molleda]

Ubuntu 7.10 Gutsy Gibbon
Gnome

If you open a document, for example "AAA.odt", with double-click in nautilus, the document is added to Recent documents list.
If you open other documents, the document "AAA.odt" go to down to second, third, ... place in Recent documents.
Now you go to Recent documents and open the document "AAA.odt" other time, it is not placed in the first line.

If the document is "AAA.txt" then the document is placed up in the first position. But if it is OpenOffice.org format (OpenDocument) then Recent documents not sort again.

Sorry my english, in Spain all TV is in spanish and is imposible learn English all days.

More: I think the error is not in Nautilus. The error is in gnome because error is when click in file name sited in menu Places - Recent Documents >

Nautilus is ok because if you open a file since Nautilus, the name file is put in Places - Recent Documents

[Dereck Wonnacott (dereck)]

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?

[Sebastien Bacher (seb128)]

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

[Guillermo Molleda (gmolleda)]

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.

[Guillermo Molleda (gmolleda)]

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.

[Chris Cheney (ccheney)]

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

[Guillermo Molleda (gmolleda)]

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.

[Chris Cheney (ccheney)]

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.

[Chris Cheney (ccheney)]

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.

[Guillermo Molleda (gmolleda)]

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.

[Mmeeks (mmeeks)]

In 11.0 we are using the new gtk 'recent' integration & API - and this is not supported by OO.o.

We need to extract & back-port the up-stream work in this area:

  http://www.openoffice.org/issues/show_bug.cgi?id=75190

for 11.0 ...

[Jpr-novell (jpr-novell)]

Tor, please take a look for 11.0

[Pmladek (pmladek)]

Hmm, I am afraid that we missed the deadline for openSUSE-11.0.

Well, I think that it is not a real blocker. OOo itself remembers the history. It just does not update the system wide list. I would consider it as a major bug.

I am sorry, I do not feel comfortable to backport the patch myself at this stage (into 11.0-GMC). I am not sure about the problem with initializing GTK. Note that we have the GNOME support in separate package, so it need not be used even when running OOo in the GNOME desktop.

Tor, please do not forget to fix this for openSUSE-11.1/SLED11.

[Tlillqvist (tlillqvist)]

Installing OpenSUSE 11 now in a virtual machine...

[Oleksij Rempel (olerem)]

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.

[Vish (vish)]

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.

[Behlert (behlert)]

This seems to work now with 3.2.1 - please re-open if I misunderstood the bug description, Michael.