In D7130#132397, @ltoscano wrote:

I think there is more than what you want: the translations of desktop are handled automatically by scripty.

Thanks for the hint. I copied the desktop files from the system installation. I know that translations are updated automatically. But what should be done (i.e. remove the translations manually before checkin)?

Just update the English messages.
More generally, why do we need copies of the system desktop files (even the ones developed by KDE, org.kde.filelight.desktop?) Isn't there a way to use the existing desktop files if installed? We don't want to duplicate what exists.

In D7130#132409, @ltoscano wrote:

Just update the English messages.
More generally, why do we need copies of the system desktop files (even the ones developed by KDE, org.kde.filelight.desktop?) Isn't there a way to use the existing desktop files if installed? We don't want to duplicate what exists.

KMoreTools provides information about applications (gives hints about their existence) that are maybe not installed yet. Back then, the idea was to reuse the translations in the desktop files. Do the duplicate desktop files cause duplicate translation work?
Personally, I also find the desktop file handling a bit clumsy, but currently I have no better idea.

BUG: 369646

It doesn't seem to fix the bug here, it's still saying that filelight and partitionmanager are not installed (but they are).

In D7130#132640, @elvisangelaccio wrote:

It doesn't seem to fix the bug here, it's still saying that filelight and partitionmanager are not installed (but they are).

Can you tell me what distro you are using and maybe the full path to the installed desktop files of filelight and partitionmanager

In D7130#132742, @gregormi wrote:

In D7130#132640, @elvisangelaccio wrote:

It doesn't seem to fix the bug here, it's still saying that filelight and partitionmanager are not installed (but they are).

Can you tell me what distro you are using and maybe the full path to the installed desktop files of filelight and partitionmanager

/usr/share/applications/org.kde.filelight.desktop
/usr/share/applications/org.kde.partitionmanager.desktop

(on archlinux)

In D7130#132762, @elvisangelaccio wrote:

In D7130#132742, @gregormi wrote:

In D7130#132640, @elvisangelaccio wrote:

It doesn't seem to fix the bug here, it's still saying that filelight and partitionmanager are not installed (but they are).

Can you tell me what distro you are using and maybe the full path to the installed desktop files of filelight and partitionmanager

/usr/share/applications/org.kde.filelight.desktop
/usr/share/applications/org.kde.partitionmanager.desktop

(on archlinux)

Hmm, this looks fine. Actually, KMoreTools uses KService to find out if an application is installed by passing the desktop filename (without extension), i.e. "org.kde.filelight" or "org.kde.partitionmanager" (KService::serviceByDesktopName(desktopEntryName)). I did not fully understand how it works internally. It uses some caching mechanism. Could you run kbuildsycoca5 or relogin and try again? I have no idea how I should reproduce it here on my machine because it works here. When dealing with KService I got the impression that it is hard to find out why a particular service (desktop file) is _not_ found.

In D7130#132425, @gregormi wrote:

In D7130#132409, @ltoscano wrote:

Just update the English messages.
More generally, why do we need copies of the system desktop files (even the ones developed by KDE, org.kde.filelight.desktop?) Isn't there a way to use the existing desktop files if installed? We don't want to duplicate what exists.

KMoreTools provides information about applications (gives hints about their existence) that are maybe not installed yet. Back then, the idea was to reuse the translations in the desktop files. Do the duplicate desktop files cause duplicate translation work?
Personally, I also find the desktop file handling a bit clumsy, but currently I have no better idea.

It may be duplicated work for translations from KDE (translation memory helps, but the message can be non aligned anyway).
This role (show information of non-installed tool) is better suited for appdata.

In D7130#132809, @gregormi wrote:

Hmm, this looks fine. Actually, KMoreTools uses KService to find out if an application is installed by passing the desktop filename (without extension), i.e. "org.kde.filelight" or "org.kde.partitionmanager" (KService::serviceByDesktopName(desktopEntryName)). I did not fully understand how it works internally. It uses some caching mechanism. Could you run kbuildsycoca5 or relogin and try again? I have no idea how I should reproduce it here on my machine because it works here. When dealing with KService I got the impression that it is hard to find out why a particular service (desktop file) is _not_ found.

Right, worked after a kbuildsycoca5 run.
I guess +1 from my side, but this will break again as soon as one of the desktop files changes upstream.

In D7130#132857, @ltoscano wrote:

In D7130#132425, @gregormi wrote:

In D7130#132409, @ltoscano wrote:

Just update the English messages.
More generally, why do we need copies of the system desktop files (even the ones developed by KDE, org.kde.filelight.desktop?) Isn't there a way to use the existing desktop files if installed? We don't want to duplicate what exists.

KMoreTools provides information about applications (gives hints about their existence) that are maybe not installed yet. Back then, the idea was to reuse the translations in the desktop files. Do the duplicate desktop files cause duplicate translation work?
Personally, I also find the desktop file handling a bit clumsy, but currently I have no better idea.

It may be duplicated work for translations from KDE (translation memory helps, but the message can be non aligned anyway).
This role (show information of non-installed tool) is better suited for appdata.

AppData: yes, I also think that these files provide more detailed information and support should be added in the future. The duplicate translation problem would remain, though, wouldn't it? Is it possible to exclude a whole directory from translation? (There one could put pretranslated files taken from the current distribution of the developer)

In D7130#133389, @elvisangelaccio wrote:

In D7130#132809, @gregormi wrote:

Hmm, this looks fine. Actually, KMoreTools uses KService to find out if an application is installed by passing the desktop filename (without extension), i.e. "org.kde.filelight" or "org.kde.partitionmanager" (KService::serviceByDesktopName(desktopEntryName)). I did not fully understand how it works internally. It uses some caching mechanism. Could you run kbuildsycoca5 or relogin and try again? I have no idea how I should reproduce it here on my machine because it works here. When dealing with KService I got the impression that it is hard to find out why a particular service (desktop file) is _not_ found.

Right, worked after a kbuildsycoca5 run.
I guess +1 from my side, but this will break again as soon as one of the desktop files changes upstream.

Great :).

Yes, it will break again... but... the desktop file name reflects the application or component ID (see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps) and this is presumably the most stable part of an application (after consolidating all the old names to the reverse-DNS scheme).

Who will give the final Ship it?

@ltoscano, can we commit this?

The line update desktop files including fix for PartitionManager and KDiskFree (https://bugs.kde.org/show_bug.cgi?id=369646) should be fixed to have BUG:...

BUG: nnnnn

My brain knows that, but apparently my fingers didn't. :p

@ltoscano, can we commit this?

Hi Nate, thanks for pushing this forward.

I still disagree in the way this is done, as it means manually periodically updating the information and it's definitely not the right thing to do.

Hi Luigi,

I agree with you that the manual updating process is not good. As the library was written, there was no better way. The desktop file method was chosen because it was said that they avoid duplicate translation work. See last point of the Introduction https://api.kde.org/frameworks/knewstuff/html/classKMoreTools.html ("Reduce translation effort by re-using .desktop files of the services added to the menu."). Since the goal of KMoreTools is to present applications that are not installed, I currently see no other way to ship all the desktop files.

That said, if @elvisangelaccio approves this, it can go in as temporary fix but the next update should work on using the appstream library to get those information from appstream files. Or any other solutions which does not involve duplicating the information.

I looked at the appstream documentation but I was not able to extract information that would help me to understand how to use it in the KMoreTools case. To be of use in KMoreTools there should be an offline database with all needed applications and descriptions. How will this database be filled with new applications? Maybe you can point me to some suitable documentation?

I had tested the patch and it was fixing the bug.
I'm fine with this as long as @gregormi volunteers to maintain this code updated (and eventually to switch to a better design, if possible).

Hi Elvis, thanks for testing. Yes, I am currently volunteering to maintain. The library was created to keep application code (like Dolphin) clean of such details. I am regularly looking for a better design. Input welcome.

I'm afraid this doesn't merge cleanly onto master. @gregormi, can you rebase it against current master so that I can merge it?

OK, I will rebase onto master and report back when done.

I'm afraid this still doesn't merge cleanly onto Dolphin's master branch for me. arc patch D7130 reports the following:

This diff is against commit e2d0a8108ec04a208d384176d53f413686ed35f2, but
the commit is nowhere in the working copy. Try to apply it against the
current working copy state? (c58226ce4f40c5c475728587f5a735a75f8be901)

(c58226ce4f40c5c475728587f5a735a75f8be901 being HEAD)

@ngraham This patch is for knewstuff :)

In D7130#155151, @gregormi wrote:

@ltoscano, can we commit this?

I still disagree in the way this is done, as it means manually periodically updating the information and it's definitely not the right thing to do.

Hi Luigi,

I agree with you that the manual updating process is not good. As the library was written, there was no better way. The desktop file method was chosen because it was said that they avoid duplicate translation work. See last point of the Introduction https://api.kde.org/frameworks/knewstuff/html/classKMoreTools.html ("Reduce translation effort by re-using .desktop files of the services added to the menu."). Since the goal of KMoreTools is to present applications that are not installed, I currently see no other way to ship all the desktop files.

That said, if @elvisangelaccio approves this, it can go in as temporary fix but the next update should work on using the appstream library to get those information from appstream files. Or any other solutions which does not involve duplicating the information.

I looked at the appstream documentation but I was not able to extract information that would help me to understand how to use it in the KMoreTools case. To be of use in KMoreTools there should be an offline database with all needed applications and descriptions. How will this database be filled with new applications? Maybe you can point me to some suitable documentation?

The idea is that you don't care about the database. The appstream database is downloaded/updated like the list of the packages provided by the package manager. You just query the database; check what plasma-discover does, for example. @mak , who maintain many stuff related with the appstream technology, may help as well.

Thanks for committing, Nate.

My pleasure. It's always nice to get bugs fixed. :)

This probably also fixes bug 384682. Can someone confirm?

I can confirm that this fixes https://bugs.kde.org/show_bug.cgi?id=384682. Updating that accordingly.