From kde-core-devel  Sun Jan 16 14:43:31 2005
From: Anders Lund <anders () alweb ! dk>
Date: Sun, 16 Jan 2005 14:43:31 +0000
To: kde-core-devel
Subject: KNewStuff
Message-Id: <200501161543.33294.anders () alweb ! dk>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110588671526410

Hi,
I don't know if this is the correct list for knewstuff, but I have a few 
suggestions for it, in order to make it more flexible.

The background is that I have started using KNewStuff/GHNS for Kate, so far 
for downloading file templates. But I see a lot of potential for Kate, for 
example for highlight files and various plugin data files (Meta DTDs for the 
XML plugin, snippet files etc.)

First, it allways looks in the application configuration, and the groups it 
looks in can't be set. It would be nicer if the configuration object could be 
set in the KNewStuff object or through a API method. 
If an application have more than one type of files that can be downloaded, the 
current storage of the version data could clash, I suggest that it is 
associated with the resource type.

Second, I would like to have a way to call KNewStuff::upload with KNS::Entry 
object, allowing the application to prefill the upload dialog. This would 
make a lot of sense for files where the meta data is partially contained in 
the file it self, such as kates highlight files, which contains author, 
version, name and more that could be used.

Third, I consider using KNewStuff to offer automated updating of kates 
highlight files, and I wonder if having a geeneric functionality for checking 
for new versions of files in the library would be a good idea.

I looked in the source, but the flow seems not to be designed with that sort 
of flexability in mind, since the dialogs involved calls the method to 
initiate the next step in the upload process.

So my question is if the maintainers of KNewStuff are interrested in having 
the above features added, if so I'll be happy to work on it.

-anders

-- 
www: http://alweb.dk
jabber: anderslund@jabber.dk