KDE-Docs.org - knewstuff and beyond

[Enrico Ros]

On Saturday 16 April 2005 18:50, Frank Karlitschek wrote:

Hi Frank,

> i have put KDE-Docs.org online. The idea is to connect our strong user
> community with the KHotNewStuff Framework and our applications.

You did a ~GREAT~ yob!

> The plan is to transform users into contributors.

I your vision of the game, and I'm sure users will like it too. The amount of 
data cassified as 'personal storage' in the world is way bigger than the 
amount of every other contents (TV, press, any media, etc..) summed up, and I 
know that, on managing contents created by the users (or arranged by them), a 
lot of businnes and research will fly around (attended a conference of the 
biggest telecom lab here in italy).
So, what you're doing it's exactly this, and you're doing it so right :-).

> We have KHotNewStuff feeds for: [ ...lots of stuff...  ]
> I can easily add more categories if something is missing.

So, you're far ahead from developers (providing feeds for contents while the 
apps are already not aware of it :-). But the gap is starting to shorten:
http://robotics.dei.unipd.it/~koral/frank.png (sorry for not being english)
Ok, let's come to the:
==second part of the reply== 

> What do you think?

Basically that we need a -programming framework- on KDE to manage this. I like 
knewstuff, but we're now extending the concepts behind it, so in the end I'll 
propose to go for a KNewStuff2.

It's amazing the job thet Josef put on getting knewstuff as easy as it is and 
starting to get people addicted. Getting a new background has never been 
easier... but we can get more, and Frank is proving that!
And I'm going to prove it too; here are the limitations I see now:

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

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

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.

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
 

 

 --

 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 

 Sponsor:

 Natsabe.it la più grande erboristeria online italiana 

* prezzi bassi tutto l'anno !

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1298&d=17-4