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