Comment 17 for bug 1312104

Revision history for this message
Harald Sitter (apachelogger) wrote :

Well, to be honest the notion using Name=Marble is the real problem. Separation etc. ought, and is, done on distro level anyway (except for a few, to mind comes slackware which does not produce split binary units from one source unit). But if the user installs more than one marble it's impossible to tell which is which [1] (generic name being the same doesn't help either, but there's menu implementations that do not actually show the generic name at all anyway...). Arguably this is not really a major issue because the user should only ever need to install one anyway. But, that is where the same Name for different binary units becomes even more annoying.
For example ubuntu's app-install data is the metadata powering the software store, this data is autogenerated from desktop files. For marble you therefore get 4 distinct entries in the ubuntu software store and muon discover [2].

All that being said, I do appreciate why you want it to have the same name and I think that generally this is a good idea. So here is how I would solve this:
- have one desktop file with Name=Marble
- introduce a starter-binary that decides at runtime which marble UI to actually start
- the desktop file then Exec=marble-starter and the starter applies a priority scheme to decide which marble to start (e.g. kde > touch > mobile > qt) depending on what is actually installed

^ In addition to that one could then still have desktop files that have a distinct more technical name like Name=Marble Qt.

Packagewise I think most distributions (or at least the ones that split the binary units into different packages) can represent that sort of dependency on a packaging level.
For example on our end this would probably look like a bit like this:

-marble.deb
  Depends: marble-bin-kde | marble-bin-qt | marble-bin-touch...
  Contains: usr/share/applications/kde4/marble.desktop (Name=Marble)

-marble-bin-kde.deb
  Contains: usr/bin/marble-kde

-marble-bin-qt.deb
  Contains: usr/bin/marble-qt

-marble-kde.deb
  Depends: marble-bin-kde
  Contains: usr/share/applications/kde4/marble-kde.desktop (Name=Marble KDE)

-marble-qt.deb
  Depends marble-bin-qt
  Contains: usr/share/applications/kde4/marble-qt.desktop (Name=Marble Qt)

So, you have the starter package, which needs at least one of the GUI binaries. Independent of everything you have the gui binaries in their own package. Finally you have the GUI specific desktop entry packages that allow the user to explicitly start a specific GUI once those packages are installed.

Mind you, the starter could also display a selection when more than one GUI is installed, the GUI specific desktop files could be dropped altogether as you can then start all guis through the starter even when all of them are installed at the same time.

LibreOffice does something similar with their starter I think.

[1] http://i.imgur.com/tUhGdRS.png
[2] http://i.imgur.com/efg1oS4.png

HTH