[ghns] KNewStuff2

Josef Spillner spillner at kde.org
Sat Dec 8 07:05:03 PST 2007


Hi all,

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.)

Josef


More information about the ghns mailing list