KDE-Docs.org - knewstuff and beyond

[Frank Karlitschek]

On Sunday 17 April 2005 17:20, Enrico Ros wrote:
> -- 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.

Yes. I can easily provide different files for newest,most dowloaded and 
highest rated. But KHotNewStuff can't use this information at the moment.

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

I see, but i don't think this is possible. We have a lot of new submissions 
every day. For example more than 10 new wallpapers every day. 
I'm not sure if our translators can handle this amount of work.

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

Yes. A better integration would be great. For example for voting. But there 
will always be a point where users have to go to the website. For example for 
the forum. 
What do you think about a khtml part integrated into the KHotNewStuff Dialog 
to show the website?

> 4) other limitations.  We're not currently aware of them, since is rather
> unexplored field.
>
> -- limitations: programming-wise --
> The following are the limitation I faced while programming a KNS client. No
> need to argument on that since some are already on the KNS TODO list and I
> think that code can refactored continously:
> - tree depth: 1 (2 if you use providers as root nodes of the contents tree)
> - can't create your own client easily (you have even to fetch files with
> kio) - 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.
> - 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
> - custom attributes: need them, every app sould need custom attributes and
> that can be defined in the dtd
> - more..
>
> 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. 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").
>
> Thanks to Josef for opening such a wide world to us, thanks again to Frank
> for being so cool and to KHTML developers (yes, that's a personal one, but
> I created the interface of my client using khtml_part in only 2 hours.. 5
> times less than the time it took me to implement the KNS 'client bones'
> :-).
>
> ** Final Note: I'd like to hear comments on that, to evaluate wether or not
> spending time helping out or working on this new KDE technology. If
> everything goes right I can open a wiki for discussion next weekend
> summarizing thread contents. (I'll be somewhat offline for somedays but
> I'll be working on my client). **
> Thanks for reading till there.
>
> Ciao,
> Enrico

Thank you very much for you ideas. You have my full support if you plan to 
enhance KHotNewStuff for KDE4.

Cheers
Frank


-- 
Frank Karlitschek
karlitschek at kde.org