> On Nov. 17, 2016, 5:06 p.m., Marco Martin wrote: > > like it, still have some issues with the > > my concern is that an id by itself is not really identifying information > > enough (would in this case for instance colorschemes.knsrc in the url > > identify something on the server which can be used to check the item of id > > 1159726 that has been downloaded is actually the needed color scheme or is > > just description?) > > Aleix Pol Gonzalez wrote: > This is a review for the other patch... ;) > > To see what information we have ATM, you can look at > `.local/share/knewstuff3/colorschemes.knsregistry` although it won't be > trivial to make OCS searches on most of them. IMHO, the way to improve it > would be to provide unique appstreamid's from OCS/kde-store. > > Aleix Pol Gonzalez wrote: > Another weird complication, the provider id is weird as f*k: > `<providerid>https://api.kde-look.org/ocs/v1/</providerid>` > > I'd suggest to get this patch in with the appstream/pk variant on > frameworksintegration and then approach kns specifically.
Hm... i would have to agree with that idea... No reason to block a genuinely useful thing because one of the optional sub-parts is being problematic :) - Dan Leinir Turthra ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129298/#review100913 ----------------------------------------------------------- On Nov. 17, 2016, 4 p.m., Aleix Pol Gonzalez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129298/ > ----------------------------------------------------------- > > (Updated Nov. 17, 2016, 4 p.m.) > > > Review request for KDE Frameworks, Plasma, Dan Leinir Turthra Jensen, and > Marco Martin. > > > Repository: kpackage > > > Description > ------- > > Makes it possible to specify components to be installed together with a > KPackage. They will be specified by a url, we'll have handlers for any kind, > making reasonably extensible and doesn't tie us to a technology. > > See RR in frameworksintegration for kns and appstream&packagekit: > https://git.reviewboard.kde.org/r/129419/ > > > Diffs > ----- > > autotests/CMakeLists.txt 395b16e > autotests/data/testpackagesdep/contents/ui/main.qml PRE-CREATION > autotests/data/testpackagesdep/metadata.json PRE-CREATION > autotests/data/testpackagesdep/testpackagesdep.testappdataxml PRE-CREATION > src/kpackage/config-package.h.cmake 61f2f0c > src/kpackage/private/packagejobthread.cpp 0a0cc01 > src/kpackage/private/packagejobthread_p.h 1babf0b > > Diff: https://git.reviewboard.kde.org/r/129298/diff/ > > > Testing > ------- > > None. just builds. It's a proof of concept, not even the test I added was > tested, it was just to display what it could look like. > > > Thanks, > > Aleix Pol Gonzalez > >
