spillner at kde.org
Sat Dec 8 07:05:03 PST 2007
sorry for joining in late, somehow I didn't get the start of the thread (or
not yet maybe).
First of all, Jeremy is now Chief KNewStuff Officer (CKO). He might not be
subscribed to this list though. But he's been really good at improving the
library lately, and while not all wishes can be fulfilled, I think at least
for 4.1 it is going to rock :)
So back to your question. The design I had in mind was that every item would
be registered along with the files it comprises. It could mean the payload
file, or all the unpacked files. Keeping the archive file around and only
using it for uninstallation seems like the easiest thing to do, but will use
up more disk space.
About the list of changed entries... Originally (in KDE 3.x), the
dialogue-centric invocation style didn't reveal anything about what was going
on. Later (in 3.5 IIRC), a method was added which returned all installed
files. Which was horribly insufficient, but at least better than nothing :-)
With KNS2, the dialogue-centric invocation style is gone. Instead, one invokes
the engine to run a workflow, and for one of the workflows the download
dialoge makes up a part of it. When using the high-level KNS::Engine*
methods, the list of entries which were affected in any way (installed,
uninstalled, updated...) should be returned.
From what it looks like, either signalEntryLoaded() must be caught in addition
to signalEntryChanged(), or we emit a signalEntryChanged() just after
signalEntryLoaded() in KNS::CoreEngine. There are suspiciously few
occurrences of signalEntryChanged() in the core engine class, I think it
wasn't really finished so I'd lean towards the second suggestion.
Also, KNS::Engine::upload did work at some point in the KDE 4 cycle. I'm not
sure why it was disabled, but getting it enabled again shouldn't be too hard.
(My assumption is that some of the changes to the library somehow broke
existing working code, but in a way that it could be fixed again.)
More information about the ghns