Red Hat Bugzilla – Bug 499474
Open Office writes 'soffice %u' as an exec value in .recently-used.xbel
Last modified: 2009-05-27 11:22:10 EDT
Open Office writes 'soffice %u' as an exec value in ~/.recently-used.xbel, which is not the right command for opening Open Office documents.
This wrong value is later being picked up by such utilities as GtkRecentManager and returned as an application execution command by gtk_recent_info_get_application_info().
We encountered this problem when launching recent documents in gnome-shell and had to switch to using a default application for a document's mime type instead of the application execution command returned by gtk_recent_info_get_application_info(). See http://bugzilla.gnome.org/show_bug.cgi?id=577380 for the gnome-shell bug info.
Its a right command to launch OOo document, just not the full path to the command.
g_set_prgname is used to set a consistent name across applications (swriter, scalc, etc) otherwise accessibility support is confused about the pesudo multi app behaviour across launched from oowriter, oocalc, /usr/lib/openoffice/. etc) and gtk_recent_manager_add_item must take that value to stuff in there, maybe gtk_recent_manager_add_full might be a way to workaround this
Rather miserable to try hacking with gtk_recent_manager_add_full, the easiest thing is to just simply add a /usr/bin/soffice. Checking the vanilla rpms I see that's what they have these days as well, so best fix in case there's anything else implicitly depending on it somewhere
Will be in >= 3.0.1-15.5 for F-10 if there is such a push, and >= 3.1.0-11.3 for F-11/F12
Sorry for coming back to this issue, but I think we really need to separate OO.o apps just like they are already divided in different desktop files. The current behavior is preventing us from getting a list of recent documents touched by a specific OO.o apps (say: text documents opened with Writer).
How does this behavior confuse accessibility? I'd expect the contrary to be true, just like 'soffice' is confusing GNOME Shell. If that's a matter of window classes not corresponding to program names, we should try to fix that upstream as well (hope!). Thanks!
Because swriter/scalc/whatever are just scripts that launch the same binary with different command line arguments. If e.g. swriter is used to launch OOo, and "swriter" was set with g_set_prgname then if file->new->calc is used to launch the spreadsheet component then the name would remain as "swriter" even though it is now a spreadsheet. So the specific launcher name under which any OOo component is initially launched is basically irrelevant to what component is used to load/save any given file or as to what name to present to a11y tools.
So g_prg_name is set to soffice as that's the underlying script/program that the other wrappers call. And the recently-used stuff by default is the simple gtk one which take g_prg_name as what to bung in there as the app to launch off.
Specific window classes all work fine, they're named as they should be IIRC.
Now, what you probably want is to have every file in the recent-used recorded with an appropriate launcher that indicates the component it was last opened by, here unfortunately you're screwed as the simple current internal api only stores the url of the file, and the mime-type of the file, not the component that file was actually opened with
So that api would have to be extended to indicate the component (e.g. writer/calc) and then the recent-used implementation would have to be able to map the component to the best-fit launched name. Not impossible, but not doable with a quick fix or a solo-run of my own. So best to take that more general problem upstream.
So the best would be to use exec lines in the form 'soffice -writer' or 'ooffice -writer' (that's what I get on Ubuntu in .desktop files) so that they don't confuse a11y programs, and still allow us to compare the full command. But then we must be sure that these commands are shared between .desktop files and recently used files.
I'll mail upstream to see if they are willing to do something, but they may consider that's too much of a shift for such a little improvement. Let's see.
Done as openoffice.org-3.1.0-11.3.fc11