Issue 90155 - Update X11 desktop integration
Summary: Update X11 desktop integration
Alias: None
Product: Installation
Classification: Application
Component: code (show other issues)
Version: DEV300m14
Hardware: All Unix, all
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2008-05-30 12:43 UTC by nospam4obr
Modified: 2017-05-20 10:55 UTC (History)
6 users (show)

See Also:
Issue Type: TASK
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description nospam4obr 2008-05-30 12:43:21 UTC
We have multiple issues with the way OO.o used to integrate into X11 desktop

* one can not install desktop integration for multiple major versions/brands in

* there are two places to update the version information (instsetoo_native & sysui)

* the freedesktop-menus package is sufficient for almost all current linux distros. 

* unbundled products should not install binaries to /usr/bin.

So I propose to:

* split the menu entries from the mime type registration (to allow multiple
majors/brands to appear in the menu at the same time)

* drop the distro specific -menus packages and all legacy files for GNOME < 2.6

* move the package creation to instset_native

Thoughts anyone ?
Comment 1 nospam4obr 2008-05-30 12:45:02 UTC
How do other packagers patch the Exec line of the .desktop files ?
Comment 2 caolanm 2008-05-30 12:54:23 UTC
FWIW one of things that I do is rename all the versioned icons to an unversioned
one, and so on for the product name and such references. We're not interested in
having different versions of the same product side by side and presenting that
version info in the menus etc.

We do support (for 3.0) installing and together and
I just change the launcher from to in the desktop files and make a copy of called
with the name location of soffice changed appropriately
Comment 3 nospam4obr 2008-05-30 13:16:00 UTC
Thanks for the info. Do you make use of the UNIXWRAPPERNAME variable introduced
with issue 75366 and/or the create_tree script ?
Comment 4 caolanm 2008-05-30 13:22:37 UTC
yeah, both. Though the wrapper name just with "" and a copy and
sed on the results afterwards to make the broffice versions.
Comment 5 pmladek 2008-06-02 19:06:18 UTC
ooo-build-based builds currently use own desktop files, see It is just from historical
reasons. No volunteer has been found to merge them with the desktop files in
sysui yet.

Though, we still install the desktop files from sysui into <ooo-home>/share/xdg.
And <ooo-home>/share/xdg/qstart.desktop is used by the GNOME quickstart module
to start ooffice the right way. This was the reason to introduce the
UNIXWRAPPERNAME variable in the issue 75366 and it is still valid.

Regarding your proposed change. I think that it makes sense. I think that the
freedesktop-menus package really should be sufficient for most current
distributions. Moving the package creation to instset_native is step forward,

If you will create the desktop integration in instset_native together with other
packages, it will be even much easier for us to start using them and get rid of
the ugly duplicit desktop files in ooo-build.

I am only not sure about splitting the mime type registration. What do you
exactly mean with it? IMHO, if two similar applications appear in the desktop
menu, it is perfectly fine to associate them all with the related MIME types.
Comment 6 nospam4obr 2008-06-03 05:03:20 UTC
Thanks for the feedback.

I think mime type registration and association are two steps: the former bundles
a name, extension, magic and icon under a type name, the latter tells the system
which applications are able to cope with which file types.

In vanilla OO.o, we have a number of potential conflicts inside the registration

* the names of the pre ODF document types are brand specific
* most of the document icons are brand specific and 
* the symbolic gnome-mime- links to the brand-prefixed icons conflict with those
of a different brand package

Also there can only be one /usr/bin/soffice ;-) (needed for SDK bootstraping).

The idea is to put those conflicting files in a dedicated package, which can be
omitted without harming the rest of the desktop integration.

Comment 7 pmladek 2008-06-03 09:59:07 UTC
I see it now. The split makes sense to me.
Comment 8 nospam4obr 2008-06-23 13:31:28 UTC
Unfortunately it looks like I won't get this ready until code freeze :-(, so
shifting target.
Comment 9 nospam4obr 2008-07-22 08:44:10 UTC
Please take over.
Comment 10 Marcus 2017-05-20 10:55:18 UTC
Reset assigne to the default "".