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