KDE-Docs.org - knewstuff and beyond

[Josef Spillner]

Am Sonntag, 17. April 2005 17:20 schrieb Enrico Ros:
> -- limitations: framework-wise --
> 1) contents are static.  I mean that the user can select the 'most
> downloaded stuff' or 'highly voted stuff' from the list she/he receives,
> but he cannot change to the list of the 'highest voted wallpapers on the
> kde-look' from the list he receives -> The framework should provide dynamic
> providers.

As long as the stuff.xml file is in reality a script (which it is in my case, 
it's named stuff.xml.php and if you request stuff.xml it is accessed 
dynamically), this should be easy to do using a (standardized?) parameter 
set, e.g. ?author=name or ?mostrecent=100.

> 2) too little i18n.  Even if you have only 1 provider, fixed contents, it's
> NAME it's not i18n'ed (but hardcoded in the remote providerslist). Plus
> contents are not translable via the NewStuff gui. By implementing the
> translating code and feeding it back to the server (or having a web
> interface for it) we could provide contents in native languages (and that
> is so important).

There is a web interface for it already, at least work in progress. There was 
already a bug report about the ability to translate the title, but the 
payload, preview and description can already be translated. For the other 
attributes it won't make much sense.

> 3) one way interaction.  While the downloading stuff is already good
> organized, and there is some upload too, there is no way to perform simple
> remote tasks like 'voting' for example (why should I open konqueror, go to
> kde-look, find a backgound, vote it,  when I just installed it with TWO
> clicks and without knowing what INTERNET is!). -> 2 way interaction.

Right, and I see that with an integrated khtml component this can be done much 
easier than implementing a RMB action which sends a request by hand. Hm. The 
current way assumes that a fair share of downloaders will still use the web 
interface, but this might as well not happen. Agreed.
The screenshot looks very nice, is this based on Aaron's mockup?

> 4) other limitations.  We're not currently aware of them, since is rather
> unexplored field.
...
> - can't create your own client easily (you have even to fetch files with
> kio)

This I don't understand. You mean something like QDomdocument doc = 
myKNewStuff::fetchAndMergeAllPossibleDataItemsFromWhereeverTheyAre()?

> - uncategorized content. I may get contents on 1 of the 70+ kde 
> languages, not post-filter a list of 20 and hope to find 1 entry that
> matches.

Same as above (the script backend).

> - installing stuff
> - notifying apps of installed stuff (defer notifications too) - that could
> be a great point that will leat to have a unified 'update manager too' and
> applications will get updates when started.. only an idea

Right. How about a QStringList of files which were installed? Or better a 
QValueList of objects which contain a string and an install/uninstall status.

> - custom attributes: need them, every app sould need custom attributes and
> that can be defined in the dtd

For this an example would be useful. You're thinking of a tag like <options 
var1="value1" var2="value2" .../>?

> - more..

Always :)

> In the conclusion I'd like to offer Josef my help, and ask for others
> programmers to join to create a central KNS technology for KDE4 as valid as
> kio, khtml, kconfigxt, kparts, are.

I thought there would never be a KDE 3.5 but now that there seems to be one I 
delayed this stuff and am currently concentrating on other KDE projects. But 
of course if action is due now (in preparation for the KDE 4 release cycle), 
count me in.

What is of special importance to me is two things: Uploads (discussion about 
those was so far underrepresented but), and maintainer control queues, the 
problem annma referred to, should be included in the web backends. 
Unfortunately the code to kde-*.org is still not available so from a trust 
POV I'll still have to toy around with this stuff in an alternative backend. 
Even more so since if any other project is to integrate GHNS, they'll more 
likely do so if they can install without much pain a server-side framework. 
And with all the options you and I have in mind it'll need more than a few 
simple scripts.

> In future visions I'd like to have the 
> applications define their 'update' or 'resource' files in xml and having a
> metacompiler (like moc, kconfigxt one, etc..) to generate the code to
> handle that (and only implement the "Installation Notification/Handling
> code").

I once thought it'd be cool to have a multi-stage file dialog, and in the 
speedbar there's an icon for a knewstuff ioslave. Then the KFileXYZ 
information would list all the details as it would when displaying a local 
KOffice document, e.g. author, last modified etc. (just made this up).
But from a usability POV it might be hell to integrate it this way.

Thanks for kicking off this discussion!

Josef