<br><br><div class="gmail_quote">2009/2/20 Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span><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 Friday 20 February 2009, Richard Dale wrote:<br>
</div><div class="Ih2E3d">> Yes, but how does that differ from just adding<br>
> createConfigurationInterface() to the scripting api in addition to<br>
> showConfigurationInterace()?<br>
<br>
</div>because that would only work nicely for the Python and Ruby script engines.<br>
for everything else, there'd be more code still required. saving a couple<br>
lines in the Python/Ruby engines by making AppletScriptEngine more specific to<br>
their design patterns doesn't really fit with the idea that the engine parent<br>
class is trying quite purposefully to not dictate or prescribe API.<br>
<br>
the Python and Ruby engines take the "we are binding libplasma, KDE and Qt"<br>
approach, which is just fine and completely appropriate.<br>
<br>
that is not, however, the goal of AppletScriptEngine.</blockquote><div>Well it isn't about code ('the C++ api'), it is about UI consistency. There are three type of plasma applets; native C++, kde scriptengine and alien (such as Apple dashboard or google widgets). It is important for the kde based scriptengines to have consistent behaviour in their configuration dialogs (you know 'DRY' meaning do not repeat yourself), but reimplementing showConfigurationInterface() in every binding violates that principle.<br>
<br>In my opinion hasConfigurationInterface(bool) is wrong and instead it should take an enum to mean 'no config interface', 'kde config interface' or 'alien config interface'. Then according to what was passed when the plasma runtime invokes a hook for the scriptengines config dialog it should call a different one for alien conf dialogs.<br>
<br>-- Richard<br></div></div><br>