straightforward use of engines

Jordi Polo mumismo at gmail.com
Wed Apr 2 21:38:27 CEST 2008


I've tried to create a twitter runner today for the sake of knowing how to
make one from the ground up.

The twitter engine has several interfaces, but I only wanted to use the send
information "interface" (or should I call it hack?).
It seemed pretty straighforward but I got a message  "Authentication
required".
As I have the twitter applet up and running I suppose that each
DataEngineManager::self()->load("twitter"); will do exactly that and create
a new engine. That needs to be configured.
So it should be perfectly possible to have several applets with different
users logged in. What is a good thing.

But as it needs to be configured with a password the runner doesn't know, we
need some solution:

- Send the data from runner to the applet and let it manage it. The applet
has all the information of configuration needed. But if we have several
twitter applets loaded what applet will we call?
- The engines should store the configuration, not the applets. The applets
will read and write configuration in engines. It will be always possible to
run an engine without configuring it (default configuration), of course the
default configuration may be done by the user but once done it is default
can can be used automatically.
- Create a GUI to configure this runner. This GUI will be launched from the
GUI that eventually will be done for whitelisting runners, prioritizing,
etc.
- The engines have their own configuration gui. The configuration gui of the
applets can call the configuration gui of the engines. A way to launch its
own GUI if still unconfigured and someone tried to use it  for engines.

Maybe none of these ideas are good solutions. Or maybe they are desirable
for some point in the future.
It may be a solved or trivial problem. It is 4.30 am here and can't really
think clearly :P


-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080403/0eaf7ec2/attachment.html 


More information about the Panel-devel mailing list