Review Request 125778: Allow kio .protocol files to be app local and local kioslave deployment

Sun Oct 25 20:00:52 UTC 2015

> On Oct. 25, 2015, 5:09 p.m., David Faure wrote:
> > So every app (packaged this way) will need a copy of the .protocol files and the kioslave executable...
> > 
> > I much preferred the solution we talked about previously, where .protocol files would be embedded (as JSON) into the kio_<protocol> slave plugin. This at least simplified the deployment question to: how to ship and locate these plugins. And it's the Qt5 way :)
> > 
> > Wouldn't that make it simpler to package other apps like what you're doing?
> 
> Christoph Cullmann wrote:
>     Yeah, you need the kioslave exe in each bundle/installer, but that is unavoidable, as you can't rely on having a "compatible" version around.
>     
>     For the .protocol files: I would like to have the metadata solution, too, but after looking more into how it works ATM, that is more work than thought, given you can have multiple .protocol files per slave (like for kio_http) and then one needs an extra tool to convert that stuff (as e.g. the current desktoptojson will just take one file and output one toplevel json map).
>     
>     I am still thinking about doing that long term, but at least the local lookup of kioslave exe will still be needed and I think that the above proposed solution is neither intrusive nor will it hurt the normal non-bundled use case on linux or some ports system and it gives people a 'working' kio on plain qt.
>     
>     And yes, without .protocol files one deployment step would be removed.
> 
> David Faure wrote:
>     Will your deployment solution be documented somewhere for everyone to see and possibly replicate?
>     
>     I don't like adding "weird" code that makes one undocumented use case work.
>     Looking up .protocol files in AppLocalDataLocation (which is btw the non-deprecated name for DataLocation in Qt >= 5.4) is very unintuitive and unexpected to me, I assume you're doing that because you're adding a path in the .qrc file to AppLocalDataLocation somehow, or because that's where you're copying files after installation. But then, wouldn't it be possible to copy these files to somewhere where GenericDataLocation will find them?
>     
>     To say this another way... if we modified QSP to look into an app-specific dir also for GenericDataLocation, then you wouldn't need to modify every single use of GenericDataLocation in KF5 and KDE apps and replace it with [AppLocal]DataLocation.
>     GenericDataLocation means shared, but it's already documented to not really be shared on sandboxed OSes like iOS and Android .... and what you're doing is basically sandboxing on OSX ;)
>     
>     As long as the app-specific dir is the fallback, I see no reason against doing this.
>     
>     Completely untested: http://www.davidfaure.fr/2015/qstandardpaths_mac_fallback.diff
> 
> Christoph Cullmann wrote:
>     For the deployment and documentation: using DataLocation (or its replacement from Qt 5.4 which I can't use given we rely only on 5.3 ;=) as default lookup place seems easy to document and handle by bundling. If you create application bundles you need anyway to put your stuff somewhere in the bundle, neither with this or any other patch this can be changed.
>     
>     For the patch to standarddirs, I think that doesn't cut it: First must be the app local lookup, then the generic one. Otherwise, you can break any bundle by just installing globally some different frameworks version. E.g. you can break the kate.app bundle by installing some mac ports that uses a more up-to-date Qt version.
>     
>     We really need to ensure that application local stuff wins (which is btw. a problem with my other patches with "use resources" as fallback, too. You just need to install some old/broken ui_standards.rc in etc => bamm, all applications that use kxmlgui are dead, there in the long run I would even remove the lookup in the filesystem).
> 
> Christoph Cullmann wrote:
>     Btw., what would be nice would be if one could tell QStandardPaths: Search first in that location, than in that. That way one could decide which order is wanted without my ugly "search here and then there" hack.
>     
>     Or simpler some fallback from app => generic for all operating systems, just the reverse of your patch and for all OSes, but perhaps I misread the diff.
>     
>     Still even then, as least until such a thing is in and we require such a version of Qt, the manual app => generic search fallback would be needed?

You got me ;=) I will write some .protocol => json converted and the rest of the needed stuff.

- Christoph

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125778/#review87371
-----------------------------------------------------------

On Oct. 24, 2015, 7:06 p.m., Christoph Cullmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125778/
> -----------------------------------------------------------
> 
> (Updated Oct. 24, 2015, 7:06 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> Allow .protocol files to be bundled with applications.
> Search in app local paths first.
> Side effect: protocols() result is now sorted by name and allProtocols won't create duplicated cache entries if .protocol files are duplicated
> 
> kioslave helper is search locally, too.
> 
> forkSlaves check was missing in holdSlave to avoid segfault without dbus.
> 
> 
> Diffs
> -----
> 
>   src/core/kprotocolinfofactory.cpp 29ba8f4 
>   src/core/slave.cpp 9ce0d78 
> 
> Diff: https://git.reviewboard.kde.org/r/125778/diff/
> 
> 
> Testing
> -------
> 
> .protocol files are now found if bundled with the application
> kwrite http://www.kde.org works on mac now.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151025/301b5997/attachment-0001.html>