> 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.
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 - David ----------------------------------------------------------- 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
