Handling Configuration Dialogs in the Scripting api

[Richard Dale]

2008/5/8 Aaron J. Seigo <aseigo at kde.org>:

> On Thursday 08 May 2008, Richard Dale wrote:
> >   In appletscripting.h there is a method called
> > showConfigurationInterface():
> >
> >   /**
> >      * Show a configuration dialog.
> >      */
> >     virtual void showConfigurationInterface();
> >
> > Note that the comment describes it as a 'dialog', and so the first
> question
> > is why isn't it named 'showConfigurationDialog()' - interface seems
> pretty
> > meaningless to me.
>
> because it's not guaranteed to be a dialog. right now the C++ API puts an
> assumption in there about a dialog, but it's actually not universal.
>
> > Similarly the C++ equivalent is called
> > createConfigureInterface() and would be better named
> > createConfigurationDialog() in my opinion.
>
> hm. actually, that was purposeful to leave it like that in the scripting
> API.
>
> showConfigurationInterface in Applet automatically creates a config based
> on
> ui files and configXML if that is available in the package, otherwise it
> calls showConfigurationInterface in the script, which is supposed to do the
> analog of showConfigurationInterface in Applet: decide how best to create
> and
> display a config interface for the given API.
>
> so given that pattern, i figured to keep the naming in line with Applet
> itself, rather than what plasmoids implement.
>
> there are two small flaws in the existing "automatically generate a config
> dialog from config xml and a ui file":
>
> * KConfigSkeleton is completely unaware of KConfigGroup; it's KConfig
> centric
> and so fails us here. i will fix this in KDE 4.2
>
> * the dialog that gets created isn't connected to any slot to signal that
> the
> configuration has changed. having some way to signal such updates such that
> the loaded widget updates itself needs to be taken into consideration. i
> see
> you've already noticed this, however ;)
>
> > why doesn't the
> > scripting api have a method that is called when the user presses ok or
> > apply buttons?
>
> nobody was using this yet, and i had other things to take cafe of. now that
> there are scripts circling the tank, it needs to be addressed.
>
> perhaps a SLOT in AppletScript that notifies of configuration changes?
>
> > So after the above preamable we can call showConfigurationIterface(), and
> > it does its stuff and creates a widget with the dialog. And then what?
> The
> > method is a void, and I think it should return the created widget
> instead.
>
> no, this is completely up to the scripting API. consider HTML/CSS for a
> really
> bizarro possibility: that stuff probably knows nothing about controls and
> code outside of html forms and javascript. building assumptions into the
> ScriptEngine API such as "knows about Qt/KDE dialogs" is going to fail us.
>
> > Then the scripting api code can put the widget in the KConfigDialog:
> >
> > parent->addPage(widget, parent->windowTitle(), icon());
> >
> > When the slot configurationAccepted() is invoked the scripting api would
> > then call back into the scripting code, which would get the config
> details
> > from the dialog.
>
> that's certainly a pattern that more powerful scripting APIs will likely
> follow. <https://mail.kde.org/mailman/listinfo/panel-devel>


Actually, I think I can just implement  a  createConfigurationInterface()
method with a  KConfigDialog argument for Ruby.

I thought the purpose of the ScriptEngine api was about 'enforcing
simplicity', when actually you are trying to 'allow flexibility'. Therefore,
if the aim was the first one implementing a 'createConfigurationInterace()'
api for Ruby would have been 'cheating', on the other hand if the aim was
'being flexible' aim would mean that it is perfectly acceptable.

So you can't just look at what the ScriptEngine code does, you have to know
the intent behind the code too. Which I think I finally do.

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080509/f0c86f76/attachment.html