D28169: [krununittest] Skip the test if ktelnetservice5{, .desktop} isn't found

[David Faure]

dfaure added a comment.


  In D28169#631893 <https://phabricator.kde.org/D28169#631893>, @ahmadsamir wrote:
  
  > Yesterday, I did try tweaking XDG_DATA_DIRS to make it find the .desktop file without it being in /usr/share/applications
  
  
  It's more portable to use QStandardPaths test mode and copy the file where QStandardPaths will expect it.
  XDG_DATA_DIRS wouldn't work on macOS or Windows.
  
  > but I didn't think that it'd take time for ksyscoca to pick it up (or even that ksycoca was involved, though in retrospect that makes sense).
  
  KMimeTypeTrader is all about querying ksycoca.
  
  > - I still think the workaround for vlc should be tightened, with e.g. checking for .desktop file name
  
  I don't think this is VLC specific at all.
  xine or mplayer or other non-KIO-based apps would have the exact same problem. They can't get hold of the password.
  Anyhow, to be discussed with the FUSE people if I'm missing something. As you probably know, I'm not involved in the FUSE stuff.
  
  > - Currently the code calls hasSchemeHandler() twice, once from KRun::init() and then in resultingArguments(); also for KMimeTypeTrader::self()->preferredService(), it's called from KRun schemeService() and from hasSchemeHandler() (the latter is used twice so, preferredService() is called three times :D)
  
  Interesting point.
  Checking hasSchemeHandler in both KRun and inside the implementation ProcessLauncherJob makes sense to me. It's two different layers of public API; passing information between the two would make for horrible API.
  In KRun it allows us to say ok, we don't need to find the mimetype, go straight to running the associated service.
  In KProcessRunner (used by ProcessLauncherJob), it's indeed a bit stupid to look up the associated service when we *are* running this service. Oh, especially since KIO::DesktopExecParser::supportedProtocols already grabs those protocols from the MimeType... So `supported` is true. Then what? why? Debugging further.... OK I see. The earlier comment I deleted is true again. ssh://root@ has username, so this makes the fuse request, fails, and then blindly sets useKioexec = true for no good reason. I'll fix that logic. And then we can remove the unneeded hasSchemeHandler() hack.
  
  Thanks for making me dig further ;)

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D28169

To: ahmadsamir, #frameworks, dfaure, sitter, feverfew, ngraham
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200321/82f5a341/attachment.html>