GNOME Color Manager Shows in Software Center as "Color Profiles"

[sam tygier]

Binary package hint: gnome-color-manager

if i search for "color manager" in the software center it does not show gnome-color-manager

[sam tygier (samtygier)]

ok, it seems to be there, but called 'Color Profiles'. this makes i quite hard to find.

[Robert Ancell (robert-ancell)]

That's the name used in the preferences menu. Doesn't seem appropriate for the software center

[Robert Ancell (robert-ancell)]

@Michael, is there a way to set the name in the control centre different to the .desktop name?

[Matthew Paul Thomas (mpt)]

You could override it in app-install-data-ubuntu, but that would work only temporarily until app-install-data-ubuntu is abolished.

I'm tempted to say that if you want a program to have a markedly different name in the menus than it does in the software catalogue, that's a branding bug in the program.

[Robert Ancell (robert-ancell)]

Matthew, the issue here is it's not an application but a new configuration option. If you look at all the names in the System>Preferences and System>Administration menu they'd all look out of place in the software center if they were separately packaged.

Perhaps the sofware store should ignore .desktop files that don't appear in the Applications menu?

[Matthew Paul Thomas (mpt)]

For me in 2.0.1, gnome-color-manager shows up as "ICC Profile Installer". Is this bug still valid?

[sam tygier (samtygier)]

in the usecase that i read about gnome-color-manager on hughsie's blog, and then try to install it. it is still a bit hinden.

[Robert Ancell (robert-ancell)]

I see what it's done - it's now ignoring gcm-prefs.desktop and looking at gcm-import.desktop instead. However it should ignore this one too as it has NoDisplay=true set. If this is fixed then software center will fall back to using the dpkg description "Color management integration for the Gnome desktop environment"?

[Matthew Paul Thomas (mpt)]

So Robert, are you saying that USC should ignore .desktop files that have NoDisplay=true? If so (or if you're not sure), perhaps you could list a few other existing packages containing .desktop files with NoDisplay=true, so we can see what the effect would be?

[Robert Ancell (robert-ancell)]

No sure answer but these are the issues as I see them:
- Settings applications have very generic names that make sense in the context of a settings menu but not on their own [2]
- Packages can contain multiple .desktop files and I don't think software center can guarantee to pick the best one
- A common case of multiple .desktop files is to make MIME handlers which almost certainly will be a bad pick

The Desktop Entry Specification [1] says:
"NoDisplay means "this application exists, but don't display it in the menus". This can be useful to e.g. associate this application with MIME types, so that it gets launched from a file manager (or other apps), without having a menu entry for it (there are tons of good reasons for this, including e.g. the netscape -remote, or kfmclient openURL kind of stuff)."

So if USC is considered a "menu" then these shouldn't be used.

Some packages of note:
gnome-orca - Has NoDisplay=true, if the .desktop is ignored it would display "Scriptable screen reader" from dpkg
gnome-utils - Classic multi application package (dictionary, screenshot, ...) - It doesn't appear in the software center [3]
gnome-bluetooth - Has the "Bluetooth" settings entry - It doesn't appear in the software center

Other NoDisplay packages: onboard, file-roller, gdebi, ...
(grep NoDisplay /usr/share/applications/*)

The only safe method of USC using the Name and Description from a .desktop file is if the package contains only one .desktop file with NoDisplay=false and it would be displayed in the "Applications" menu, i.e. it is not in the Settings category.

[1] http://standards.freedesktop.org/desktop-entry-spec/latest
[2] Perhaps USC could mark settings differently?
[3] I think these packages should be split, probably not the responsibility of USC

[Matthew Paul Thomas (mpt)]

Thanks for that comprehensive answer, Robert. Now I have four more questions. :-)

1. We already show Category=Settings items *separately*, in the "Themes & Tweaks" department. So anything we did to show all Settings items *differently* probably would cause a lot of visual noise here. Now, some of these "Settings" items have names that make sense in isolation (e.g. "Art Manager", "Desktop Drapes", "Disk Utility"), while others understandably don't (e.g. "Bluetooth", "Default Printer", "Password"). Does that latter group have something programmatically in common? Do they share a dependency or reverse dependency on gnome-control-center, or something like that? If so, then we could do something like displaying an explanatory "(control panel)" after the titles of just those ones.

2. About choosing the correct .desktop file to show in USC, what do you think of this algorithm? "If a package contains more than one .desktop file and all except one of them has NoDisplay=true, show only the one that doesn't. Otherwise, show every .desktop file." Maybe that would still show some .desktop files that we'd rather were hidden. But would it hide any that we wanted shown?

3. Why do Orca's and onBoard's .desktop files have NoDisplay=true?

4. In my 10.04 installation, gnome-utils shows up in USC as "Get Software" > "Accessories" > "GNOME Desktop Utilities", and gnome-bluetooth shows up as "Get Software" > "Themes & Tweaks" > "Bluetooth". Is this an aberration?

[Launchpad Janitor (janitor)]

[Expired for gnome-color-manager (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for software-center (Ubuntu) because there has been no activity for 60 days.]