Won't KNewStuffQuick be a runtime dependency in the end?

Why isn't the downloadmanager core?

Is it really needed to leave QML optional?

Why the change? Can't EntryPrivate keep a toEntry method?

QML plugins are MODULE instead of SHARED.

It will... Though, this is pretty much just doing what Kirigami does as well, am i doing something wrong here?

DownloadManager is already an exported symbol in KNewStuff, and consequently i am rather worried about binary compatibility with this. The same is the issue with Entry, which is why i had to swap the logic for converting Entry and EntryInternal instances (though that one already has all the logic in EntryPrivate, which is a terrible name that we could sort, and probably should).

The prime option i see for this would be: Replace the namespace KNS3 with KNSCore in the Core library, rename KNS3::DownloadManager to KNSCore::DownloadManager, and create a new, straight forward reimplementation of KNSCore::DownloadManager called KNS3::DownloadManager, which would result in us still having that symbol exported from KNewStuff, while the functionality would end up in Core. The same (basic) situation as with Entry and EntryInternal (which should then, perhaps, become KNS3::Entry and KNSCore::Entry respectively). Thoughts?

Hmm... i guess it isn't really, no... i'll just make that un-optional, makes it a bit cleaner as well, which is always nice :)

Ah, so they are :)

i get that probably the problem of kio is depending from widgets, but is it wise to have such a big reimplementation here? (note, i'm probably ok with this, just want to see a rationale for it)

+1 on that

It's all terribly annoying, yes, and the rationale is, quite simply, to retain the job based method for copying and downloading things, while also not adding a dependency on kio... One option would be to move this into a separate framework of its own, but i'm also not sure that is the best idea in the world - possibly an option, mind, and to facilitate this it might be an idea to not export the symbols from this part of the work (so it could be moved out while retaining binary compatibility).

See comment regarding DownloadManager in general... In principle that'd be lovely, but Entry is in KNewStuff, while EntryInternal is in Core...

do you see particular problems by publicly exposing just the kjobs, even if the actual implementation of the jobs would be those (not exported) subclasses?
not super-important to me tough, just trying to see what's the lest footprint solution

ok

No, that does seem likely to be the most straightforward option - i'll fiddle it a bit and unexport these ones, for potential future ripping-out-and-frameworkifying, in case we decide to do that at some point :)

Is this change really necessary? The API should be backwards compatible.

const &?

Also in the ones below.

const &

Why do we de-couple from KIO?

It's possibly a good opportunity to use initializer lists.

Also aren't standard Qt roles supported? i.e. Qt::DisplayRole...

This looks odd, maybe remove all empty?

why's the commented code?

I would emit after the ResetModel transaction, it's usually better that they're as atomic as possible.

Maybe it's an assert? Or a warning in the else branch? When is it going to fail?

Author was not previously exported, so there isn't a great deal of difference here... Not sure why this would be an issue? Anything in KNSCore was previously not exported, so the API was never publicly exposed...

Good call, yup, i'll get that sorted

We decouple from KIO because it is a very large dependency (or, rather, tree of dependencies), and because depending on a tier 3 framework would push KNSCore into tier 3, which is explicitly what we are trying to avoid. We did discuss this in Randa, though i must confess that i do not remember if you were present when we talked about it...

Hmm, i guess that might make sense... i never did use those before, so i guess this is as good a time as any ;)

Personally i prefer to not expose the magic values, but that is a personal thing without any particularly good reasoning behind it, other than not being fond of making that kind of choice for the api user... i guess display and decoration are reasonably well defined in this case (as name and the first item in previewsSmall), i just was never fond of those. If this is a thing that is commonly done in frameworks, though, i'm not absolutely against it.

Hmm... yeah, i guess that would be the least-odd choice here, i'll do that

because the model is not fully completed yet...

i tend to view begin/end calls in models as parenthetic, and moving the engine change emit outside that logical parenthesis just feels... wrong to me...

It is really a "don't be silly, programmer" so yes, an assert would likely make more sense, i'll change it to that instead.

if i understood correctly both qwidget and qml implementation implement a questionmanager that would render the dialog or whatever...

I wouldn't know how to do it differently, but would be possible to make this asyncronous in some way?

const & here too

what's the reason for this timer?

i was racking my brains to try and come up with other ways of doing it and just couldn't figure anything out... Making it asynchronous would be lovely, i just don't see how to do so... which, obviously, sucks, but... yeah.

Ah, as it turns out, no, these are not const. The documentation is, however, not correct, so i will fix that.

Normally yes... but, i looked through these, and the problem turns out to be that in most of these, you basically /want/ the entry to change (uninstalling or installing changes the status of the entry to either Deleted or Installed, respectively).

It intends to postpones the job starting until after the calling function has it in hand again... In reality, i guess it's not really needed, though, i'll just remove that :)

Are these two necessary to install? AFAICS the new targets don't install any headers.