No applications available for photo editing if Gnome is not installed

Thanks for reporting bugs. However, this one does not look like a real bug to me: when you install F-Spot, you don't always want to have GIMP coming with it. Thus, it is normal that you cannot edit photos since you have no image processing app. If you need one, just manually install GIMP.

We may possibly see this as a KDE issue: they could provide an image manipulation program in the default desktop, but this is a problem since AFAIK KDE has no such program. Am I missing something?

Sorry for not making this clear: Gimp was already installed as well. As was Opera and okular, which also showed up as available applications once I had installed Gnome. These three applications were installed prior to installing f-spot, but still weren't picked up. I also double-checked that Gimp's entry in /usr/share/applications/gimp.desktop was correct, which it was. (AFAIK, that's where f-spot picks up its list of applications that can handle a given mime-type)

OK. So could you try reinstalling gimp and okular, and then if that does not solve the problem, reinstalling f-spot? This would give us more information about the problem. Please use 'apt-get --purge remove PACKAGE' so that system configuration files go away too.

I reinstalled Gimp. It made no difference. Same for reinstalling f-spot. Installing Gnome immediately fixed the problem, also in KDE (without logging out and in again).

Since it's been a very long time since any additional info was added to this bug, I'm just checking to see if this is still an issue, and find out what additional work should be done on this bug.

Unfortunately I'm no longer a KDE user, so I'm unable to test this with my current setup.

Closing since reporter is no longer having issue (no longer using KDE).

I'm setting this back to incomplete since I'm having the same problem: I'm using Kubuntu 9.04 (KDE 4.2.2) and I have f-spot and The Gimp installed. When I right-click on an image the "Open with" option tells me "No applications available".

When I try to install the package "gnome" as Eira said, I get an error message that the package libgpod4-nogtk needs to be uninstalled to do so (needed to communicate with iPods). This package seems to be a dependency of amarok, though.

To make things short: I haven't found a way to get this bug fixed in KDE 4.2.2 without uninstalling important components of it.

Apparently, there are two versions that Amarok can use of libgpod4: one with GTK, and one without. I guess that if you install the package libgpod4, and then gnome, that should work. But that should be handled more nicely, would you mind filing a bug against that package?

But about the true causes of the present bug, I don't really know. Please try to run 'sudo update-desktop-database /usr/share/applications/' before you try installing GNOME - but it would be strange that KDE is not doing so already.

And even 'sudo update-desktop-database', without any argument. ;-)

OK, I've found it. Please run 'grep gimp /usr/share/applications/mimeinfo.cache', that will show you every file type for which GIMP is registered.

Hm, are you sure you're talking about KDE 4, Milan? At least this is what happened when I followed your steps:

~$ grep gimp /usr/share/applications/mimeinfo.cache
grep: /usr/share/applications/mimeinfo.cache: No such file or directory

~$ sudo update-desktop-database
sudo: update-desktop-database: command not found

I can try the libgpod4 option later...

I'm a GNOME user, but these are supposed to be desktop-neutral, though I can't find the spec that deals with this precise problem. So from the result of these commands, it looks like the file does not exist, which can perfectly explain the problem.

Can you install the package desktop-file-utils and then retry the second command? That must be the thing that installing GNOME does. Now, I don't know why KDE acts differently - and maybe GIMP should depend on that package.

I just installed the package desktop-file-utils and ran sudo update-desktop-database and now the problem is solved: The applications show up in the menu and work. So should this be a dependancy?

Thanks a lot!

Cool! The problem here is that I could not find what system KDE 4 uses for MIME associations. It doesn't seem it uses update-desktop-database even though that's a freedesktop.org standard. So we could require GTK apps to depend on desktop-file-utils, but that's not really an easy task.

Could somebody familiar with KDE explain how that's supposed to work?

For KDE users, does running kbuildsycoca4 after installed the gnome app work?

For me, running kbuildsycoca4 doesn't change anything in f-spot, i.e. it doesn't solve the problem. (I removed the package desktop-file-utils and the file /usr/share/applications/mimeinfo.cache before.)

Woohoo, the magics of standards.
@Jonathan: That would not change anything because that only updates the ksycoca but not freedesktop stuff (because by spec the installing application is supposed to do that stuff, not the desktop's implementation of the freedesktop standards), fspot being a mono/gtk+ app, doesn't care about ksycoca though ;-)

@Milan: The fact that GNOME uses it, doesn't mean that update-desktop-database is a standard, which to my knowledge it is not. It is a freedesktop.org software project, but no more and no less than that. Calling it a standard is like saying Tango is a standard, which would make GNOME not comply with the standard.

Anyway.
Lets recap.
* The freedesktop specifications/standards for desktop files (which list associated mimetypes) and for shared-mime (which lists mimetypes that can be used by desktop files) do not define update-desktop-database as standard of any kind, neither do they reference desktop-files-utils
* The freedesktop shared-mime spec however, lists update-mime-database as tool of choice for updating the possible mimetypes (which should be working just fine, because that is implemented in KDE)
* The linking of application=>mimetype is, just like managing the list of applications, up to the desktop's specific implementation (as suggested in the desktop-entry-spec)
* fspot either does not use GNOME's builtin parser, or GNOME in fact uses update-desktop-database as default parser. So, either fspot needs to depend on desktop-file-utils or the GNOME library that is responsible for reading the data provided by update-desktop-database needs to depend on desktop-file-utils.

That's what I was expecting (fearing)... The spec does not go until that part - though IMHO it could have been good to have a common command to do this kind of thing.

The problem is, no package except ubuntu-desktop and a few others depend on desktop-file-utils. So fixing that "detail" would really be a pain for many packagers. From what I understand, there used to be a Debian tool called dh_desktop, which has just been marked as deprecated; looks like we should now use directly update-desktop-database, but what about KDE? What I can expect is that every desktop environment should depend and use its own tools, and that we are still in the middle of a migration, so maybe we should open bugs against gimp and friends separately...

I'd really like a packaging guru to confirm that! ;-)

All very confusing and certainly requires investigation.

First of all I cannot imagine that KDE got a quite well working component to implement the desktop-enty-spec (namely kbuildsycoca4) and GNOME depends on update-desktop-database only. The mentioned spec does not even enforce a policy were every package that comes with a destkop file needs to invoke said command. So, considering a 3rd party developer deploys an application with desktop file and doesn't know that he should call update-desktop-database (Since it is not mentioned in the spec) GNOME would never know about his application.
Comparing that to the automated scans of kbuildsycoca4 (to find new desktop files) and its inode notification registration (to get notified about updated desktop files) makes GNOME appear in a rather bad light TBH. So, someone who knows his way through GNOME would be very welcome to explain if this is really the way GNOME does things.

Anyway, as for the fix for GNOME applications. No, we should not open bugs against gimp and friends. Because:

Technically the desktop-entry-spec suggest a two way communication module.
First you have the parsing component that interacts with the desktop files and the mime cache to build a list of applications etc. and on the other side you have the output component that provides the necessary information to the application.
Assuming that no one would be developing GNOME applications if they had to implement the output component into every application rather than one libary (update-desktop-database creates just the database, but still somehow this database needs to be accessed and processed so that its information can be used within the actual application), there must be some GNOME library that handles the interaction with the application. And this library should depend on desktop-file-utils.
Because what use does the library have if you don't have a database it can read from? ... clearly a case of Dependency ;-)

That is however only an assumption.

GNOME packages are calling update-desktop-database and update-mime-database everytime they add a file to those places. Apps rely on GIO (mostly) to get the required data, but GIO only reads the cache file, I think - and does not depend on desktop-files-utils.

Does KDE handle this automatically? Then why doesn't it detect GIMP's ability to edit images?

KDE does detect it and any KDE app would be able to access this data, so if fspot was a KDE application all this would work perfectly fine. But since fspot is a GNOME app it apparently relies on GIO to read the desktop-file database, which is not present, because KDE doesn't create or update that file since it is not even mentioned in any fd.o spec.

You have to get a different point of view on the issue: it's not about a GNOME app in KDE, it is about a GNOME app in an environment without desktop-file-utils, competely unrelated to KDE.

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