Prefer to find oktetapart by desktop file, not binary name
ClosedPublic

Authored by kossebau on Feb 9 2019, 5:39 PM.

Details

Summary

Okteta >= 0.26 installs the oktetapart binary in the kf5/parts subdir
of the plugins, so the old check will not find it.
But that version also installs a desktop file again, so prefer to use that.

Test Plan

Okteta KParts plugin is found also with devel version of what will be 0.26
in some weeks.

Diff Detail

Repository
R167 Krusader
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
kossebau requested review of this revision.Feb 9 2019, 5:39 PM
kossebau created this revision.

@yurchor Thanks for (the instant) review :)

Related questions while waiting for the final "Accept":

  • in which branch to push then?
  • when would the next release of Krusader happen?

Asking because I plan to do the release of Okteta 0.26.0 at the begin of March. And then this change will be needed also in released version of Krusader, otherwise Krusader will no longer find the oktetapart.

@yurchor Thanks for (the instant) review :)

Related questions while waiting for the final "Accept":

  • in which branch to push then?

git/master should be safe. Nikita (or our other developer) will decide if it worth to merge (or cherry-pick) it with some stable branch.

  • when would the next release of Krusader happen?

There are no definite plans yet.

Asking because I plan to do the release of Okteta 0.26.0 at the begin of March. And then this change will be needed also in released version of Krusader, otherwise Krusader will no longer find the oktetapart.

Thanks for the notice.

nmel added a subscriber: nmel.Feb 13 2019, 7:14 AM

The code looks fine to me. Let me test it over the weekend and I'll sign off if no issue found. I can also test a new code path if there is a way to modify v0.25 accordingly.

Regarding the stable release, we can put the patch into stable branch and release it with v2.7.2. No schedule is defined yet but we can make arrangements.

In D18881#411267, @nmel wrote:

The code looks fine to me. Let me test it over the weekend and I'll sign off if no issue found. I can also test a new code path if there is a way to modify v0.25 accordingly.

For that you would

  1. move oktetapart.so from /usr/lib64/qt5/plugins/ to the subdir in there kf5/parts
  2. deploy the oktetapart.desktop file directly from the Okteta sources of current master branch to the services metadata folder, e.g. like this:
kdecp5 https://cgit.kde.org/okteta.git/plain/parts/kpart/oktetapart.desktop /usr/share/kservices5/

and perhaps run kbuildsycoca5 afterwards just to make sure the db is up-to-date, if not automatically triggered by filesystem watching.
Untested, but that should do it.

nmel accepted this revision.Feb 18 2019, 6:49 AM

I verified it's working correctly in both cases. Thanks for the patch! Please push it to the master, I'll take care of the stable branch afterwards.

This revision is now accepted and ready to land.Feb 18 2019, 6:49 AM
This revision was automatically updated to reflect the committed changes.
kossebau added a comment.EditedFeb 18 2019, 5:03 PM

Thanks again for review and getting this in. So code-wise Okteta 0.26 should be prepared by the direct consumers known to me (KDevelop & Krusader), I now still just need to inspire you for respective releases ;)

I am soon running out of things to put into Okteta 0.26, so currently plan to branch upcoming week and do a release around March 11th or the days after. If you the Krusader developers do not have the time or motivation to do a release, I will point packagers to the needed patch then, so they know how to re-marry things for the time being. But would of course be happy if I can point out to existing releases instead :)