[Panel-devel] Superkaramba applets configuration

[Fred Schaettgen]

On Tuesday, 21. June 2005 16:53, Aaron J. Seigo wrote:
> On Tuesday 21 June 2005 07:32, Fred Schaettgen wrote:
> > Or a similar problem - will I be able to pop up a calendar next to the
> > clock with a SK theme?
>
> keep in mind that the definition of a plasma applet and an SK theme are not
> the same. an SK theme is currently confined to Python, as one example. the
> clock that ships with plasma will almost certainly continue to be written
> in C++ with KJSEmbed hooks for themes. 

Your describing the status quo. But why should we have completely different 
theme interfaces even with different scripting languages for the clock and 
for other widgets? 

> the taskbar will also almost 
> certainly continue to be C++. other applets will almost certainly not be
> C++, however. all will be "plasma applets", however.

I see. IIRC you said somewhere that you want all plasma applets to the 
themeable, then there was the announcement of SK becoming part of KDE4. So my 
conclusion was that your plan was to do the UI of all plasma applets with a 
scripting language at some point.

> so yes, you'll be able to pop up a calendar next to the clock =) whether
> you can do that in language X is another question. if a calendar is a
> common enough need for scripted plugins, then we may include an interface
> for that in libplasma.

That was my point. The calendar will only be used for the clock for sure. So I 
was hoping that I'll be able to create an own widget host, which derives from 
the generic widget engine, but provides an additional "ShowCalendarWidget" 
method to the themes it is hosting.
The same could be done for any other applet. The taskbar engine would provide 
methods or objects to the script to get information about the running tasks 
and so on, which should probably be done in C++. The theme would just provide 
the view and controller part. We could decide case by case what should be 
handled in C++ for efficieny reasons and what can be scripted.

> > What if we limit the scripted part of the applets to just the regular
> > applet GUI, not including configuration and other dialogs opened by
> > interacting with the applet?
>
> i don't think this is necessary. for specific instances like the clock i
> think it makes all the sense in the world. but we need to keep the entry
> bar low for people writing applets, which means the ability to have
> pure-Ruby/Python/JS/Java applets as well. libplasma needs to be able to
> serve as the infrastructure here.

I don't see how this would complicate the live of applet authors. They would 
simply write their applet script and do whatever they want as usual. But 
probably they won't be able to do everything with a script in a clean, usable 
and efficient way. If they want to write a task management applet or a system 
monitor applet, they would specify somewhere in their applet descriptor to 
use the task management applet engine and they would be provided with the API 
they need for that task, together with proper configuration dialogs for that 
specific use case. The C++-programmers can do the nasty stuff in the 
background and the theme authors can concentrate on a cool look. If the 
generic script API is powerfull enough to do everything, then fine. But 
somehow I doubt that this is possible.
Being able to provide enhanced script engines would allow us ship themeable 
applets with KDE, which are fast and usable and in general don't suffer from 
limitations of an incomplete scripting API, because the API can be tailor 
made for each applet. At the same time we can try to make the generic applet 
scripting engine usable for each and every purpose, but still we wouldn't 
depend on the success of that part.

> and to be honest, with Qt Designer files it's pretty easy to do slick
> configuration dialogs in JS or Ruby. i'm sure it's the same or similar in
> Python.

Hm, then give me a single reason why I should reinvent the wheel for 
styleclock and define a Javascript API and everything else instead of making 
it a SK applet ;)

Fred

-- 
Fred Schaettgen
kde.sch at ttgen.net