[ghns] KNewStuff2

[Frederik Gladhorn]

Hi Josef,
thanks for getting us started.

El Saturday 08 December 2007, Josef Spillner escribió:
> 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 :)
I know, I'm working with Jeremy.

> 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.
Nope, I'll go through the archive to get all file names, no problem there, got 
it working.
Now I'll add a QStringList to the entry class to have the files handy. What I 
do not like about that is that I have a few extra tags in the registry xml 
wich does not correspond to the dtd for entries, but I don't see a better way 
to do it. Suggestions are welcome. But I think this way is ok.

> 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.
I debugged that a while ago and made Jeremy implement it ;)
Because you actually had a new empy list returned...
Since the returned entries are of no use when deleted, we leave it to the app 
to do a qDeleteAll or similiar after returning them now. Api-Docs are 
updated.


> >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.)
Sounds good, hard to test.
Josef: You do have a test server somewhere right? Would it be possible to give 
access to that for Jeremy and me? We'd save quite some time if we could test 
with it actually. I don't have time or energy to try to figure out how to 
setup the server side. Also is rating and stuff like that supported server 
wise?


The next big problem that comes up is getting a real server. At the moment 
kde-edu uses the normal kde website to serve the files statically but that 
really sucks.
This is also interesting for plasma and games and all other uses of KNS. I am 
not familiar enough with kde internals, is there a chance of getting a 
dedicated server up and running in the near future?

Greetings,
Frederik



-- 
Parley - The Vocabulary Trainer
http://edu.kde.org/parley/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/ghns/attachments/20071208/51c211f3/attachment.pgp