No subject
Tue Jun 24 01:01:01 CEST 2008
if (d->package && d->configXml) {
QString uiFile = d->package->filePath("mainconfigui");
if (uiFile.isEmpty()) {
return;
}
KConfigDialog *dialog = new KConfigDialog(0, dialogId,
d->configXml);
dialog->setWindowTitle(windowTitle);
dialog->setAttribute(Qt::WA_DeleteOnClose, true);
QUiLoader loader;
QFile f(uiFile);
if (!f.open(QIODevice::ReadOnly)) {
delete dialog;
if (d->script) {
d->script->showConfigurationInterface();
}
return;
}
Why does this code suddenly lurch off into calling
showConfigurationInterface(); if the scripting interface is being used? If I
have configXml set I assume it means I actually want to dynamically load the
.ui and .kcfg files and not have to intervene. I actually might want my
scripting api to see a hash table of the config options if it doesn't have
all the KConfigSkeleton classes wrapped. I we add KConfig specific calls to
the ScriptEngine api you said last time I asked that it might mean it wasn't
general enough to cater for non-Qt/KDE widgets such as dashboard. So how can
the same api be just right for those entirely alien apis, and at the same
time be good for near-KDE type apis.
The script engine interface makes assumptions about using dynamically loaded
.ui files in other places when the Python, Ruby, C# and Java languages have
all got perfectly good versions of the uic compiler:
void Applet::Private::setupScriptSupport()
{
...
if (!package->filePath("mainconfigui").isEmpty()) {
q->setHasConfigurationInterface(true);
}
The point I am making is that nobody is using this code and it isn't
receiving any developer/user feedback like the rest of Plasma is, and points
like this aren't being addressed. If we leave it until 4.2 we will only have
one opportunity to get it right.
>
> > change. All I know is that the current group are all 100% 'ninja' to use
> > Aaron's terminology and would expect to be able to use the full C++ api.
> So
>
> and we'll never get the other 98% of people unless we adjust ourselves from
> catering to those people.
Well, that's your theory, and I have expectations based on understanding the
current Ruby programmer user base. Until we have practical experience and
have actually expanded the user base by 100x I don't think it is possible to
argue one way or the other.
>
>
> > my plan for KDE 4.1 is to try and provide both a ScriptEngine based api,
> > and the full C++ api (with or without proper plasma packaging), and get
> > something moving.
>
> cool; i guess that answers my what's actually read question above.
>
> > In a couple of weeks we are having a hacker sprint in Berlin with a lot
> of
> > the bindings guys (python, ruby, c# and php) and Kross too, and I would
> be
> > very keen on discussing there what to do about Plasma bindings for KDE
> 4.1.
>
> i just hope that the point, purpose and advantage of the ScriptEngine
> strategy
> isn't lost because people are still thinking about things in the
> traditional
> manner of "wrap an API, it's what we want!" versus "define an API, it's
> what is
> manageable and increases the audience"
I'm afraid it the purpose and advantage is lost because we have no practical
experience. It may well be true that your ideas will work, but all I can say
is that ideas about what end user programming should be about have a very
long and distinguished history of being wrong. A good example is AppleScript
with all those wonderful english-like constructs, which is actually pretty
end-user hostile in practice as far as I know. Apple currently have a visual
development tool at present for end users ,and maybe the best answer for
Plasma would be to have something like that. Until we start trying things
out, make mistakes and getting user feedback, I regard talk about increasing
the audience as just talk. If we leave it all until 4.2 we will only really
have one shot.
-- Richard
------=_Part_33515_20951018.1214341938247
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div class="gmail_quote">2008/6/24 Aaron J. Seigo <<a href="mailto:aseigo at kde.org">aseigo at 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 Tuesday 24 June 2008, Richard Dale wrote:<br>
> 2008/6/23 Aaron J. Seigo <<a href="mailto:aseigo at kde.org">aseigo at kde.org</a>>:<br>
> > On Monday 23 June 2008, Janz wrote:<br>
> > > give any hint) and couldn't find about how to get started with a<br>
> > > non-C++ plasmoid. I saw a few examples (tiger JS plasmoid and all of<br>
> > > those in script/ on svn playground) but I can't install them under KDE<br>
> > > 4.1 beta Kubuntu package<br>
> ><br>
> > we actually have a plasmapkg application in kdebase now that can install<br>
> > such<br>
> > packages.<br>
><br>
> I would like to be able to use the plasapkg packaging mechanism for non-C++<br>
> languages such as C# which don't use the ScriptEngine api.<br>
<br>
</div>which is completely plausible; the two aren't actually linked in any way. we<br>
use packages for other things as well, e.g. themes.</blockquote><div>Yes, I can write a Ruby plugin type that would load pretending to be a C++ plugin and then load the ruby code using the plasma packaging api. It's just that it wouldn't be built into Plasma like the ScriptEngine/Package loading is. I think that is the best solution for KDE 4.1, and what I will try to actually implement.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> C# is not a<br>
> scripting language and I think people will expect either the C++ api or<br>
> nothing<br>
<br>
</div>makes sense. in which case C# just becomes Another Language which libplasma is<br>
unaware of. this means less integration and no out of the box magic.</blockquote><div>Umm, the problem is that the current ScriptEngine api doesn't offer 'out of the box' magic apart from the packaging mechanism. It may in the future, and maybe knowledge about the security api would affect my opinions. I can only see what I currently see in the code.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
personally, i don't see why, in light of that, we need such languages, other<br>
than to inflate the language count, when we have a number of alternatives. but<br>
if people wish to write in C#, go for it by all means.</blockquote><div>Yes, I would class C# bindings in the 'for educational use' category. That is a use case would be for people who want to spend a weekend or two playing with a language like C#, and a relatively small self contained api like the Plasma one, hacking up a clock or something with no practical value. Of course once we actually have C# programmers my opinion may well change.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> - I really can't see how it would make sense to go through the<br>
> ScriptEngine.<br>
<br>
</div>i don't want to compromise the tidyness of it on the libplasma side, however.<br>
<div class="Ih2E3d"><br>
> There will be the same issue if we have Java QtJambi bindings<br>
> I think. I have exchanged private emails with Aaron about whether or not<br>
> Ruby should use the ScriptEngine, and I still am not keen on using it as it<br>
> currently stands.<br>
<br>
</div>then it becomes like the C# issue above. a proper API for applets written in<br>
Ruby can also be provided via ScriptEngine at some point. it's not an<br>
either/or, it's really a matter of doing it in a way that lets plasma help you<br>
or whether you are completely on your own.<br>
<br>
obviously, integration points and easing support of managing packages, etc is<br>
probably the nicest thing. doesn't mean it's the only thing.<br>
<div class="Ih2E3d"><br>
> I personally would prefer to get something going for 4.1 because I don't<br>
> think we can know what people want - which languages, what skill level and<br>
> so on - until we start iterating with something and get community feedback.<br>
<br>
</div>agreed; but what's actually *ready*?</blockquote><div>Well nobody is working on improving the script engine api, it has stayed unchanged for over 2 months. I did ask about the method to invoke a config dialog a while ago, saying that the ScriptEngine api didn't allow you to access a KConfig instance to save the api details. Of course you can just access the underlying applet to do that, but would that be following the script engine api? Or are you just supposed to go via the provided methods and wait for more methods to be added in the future.<br>
<br>From applet.cpp:<br><br> if (d->package && d->configXml) {<br> QString uiFile = d->package->filePath("mainconfigui");<br> if (uiFile.isEmpty()) {<br> return;<br>
}<br><br> KConfigDialog *dialog = new KConfigDialog(0, dialogId, d->configXml);<br> dialog->setWindowTitle(windowTitle);<br> dialog->setAttribute(Qt::WA_DeleteOnClose, true);<br><br> QUiLoader loader;<br>
QFile f(uiFile);<br> if (!f.open(QIODevice::ReadOnly)) {<br> delete dialog;<br><br> if (d->script) {<br> d->script->showConfigurationInterface();<br> }<br>
return;<br> }<br><br>Why does this code suddenly lurch off into calling showConfigurationInterface(); if the scripting interface is being used? If I have configXml set I assume it means I actually want to dynamically load the .ui and .kcfg files and not have to intervene. I actually might want my scripting api to see a hash table of the config options if it doesn't have all the KConfigSkeleton classes wrapped. I we add KConfig specific calls to the ScriptEngine api you said last time I asked that it might mean it wasn't general enough to cater for non-Qt/KDE widgets such as dashboard. So how can the same api be just right for those entirely alien apis, and at the same time be good for near-KDE type apis.<br>
<br>The script engine interface makes assumptions about using dynamically loaded .ui files in other places when the Python, Ruby, C# and Java languages have all got perfectly good versions of the uic compiler:<br><br>void Applet::Private::setupScriptSupport()<br>
{<br> ...<br> if (!package->filePath("mainconfigui").isEmpty()) {<br> q->setHasConfigurationInterface(true);<br> }<br><br>The point I am making is that nobody is using this code and it isn't receiving any developer/user feedback like the rest of Plasma is, and points like this aren't being addressed. If we leave it until 4.2 we will only have one opportunity to get it right.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> change. All I know is that the current group are all 100% 'ninja' to use<br>
> Aaron's terminology and would expect to be able to use the full C++ api. So<br>
<br>
</div>and we'll never get the other 98% of people unless we adjust ourselves from<br>
catering to those people.</blockquote><div>Well, that's your theory, and I have expectations based on understanding the current Ruby programmer user base. Until we have practical experience and have actually expanded the user base by 100x I don't think it is possible to argue one way or the other.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> my plan for KDE 4.1 is to try and provide both a ScriptEngine based api,<br>
> and the full C++ api (with or without proper plasma packaging), and get<br>
> something moving.<br>
<br>
</div>cool; i guess that answers my what's actually read question above.<br>
<div class="Ih2E3d"><br>
> In a couple of weeks we are having a hacker sprint in Berlin with a lot of<br>
> the bindings guys (python, ruby, c# and php) and Kross too, and I would be<br>
> very keen on discussing there what to do about Plasma bindings for KDE 4.1.<br>
<br>
</div>i just hope that the point, purpose and advantage of the ScriptEngine strategy<br>
isn't lost because people are still thinking about things in the traditional<br>
manner of "wrap an API, it's what we want!" versus "define an API, it's what is<br>
manageable and increases the audience"</blockquote>I'm afraid it the purpose and advantage is lost because we have no practical experience. It may well be true that your ideas will work, but all I can say is that ideas about what end user programming should be about have a very long and distinguished history of being wrong. A good example is AppleScript with all those wonderful english-like constructs, which is actually pretty end-user hostile in practice as far as I know. Apple currently have a visual development tool at present for end users ,and maybe the best answer for Plasma would be to have something like that. Until we start trying things out, make mistakes and getting user feedback, I regard talk about increasing the audience as just talk. If we leave it all until 4.2 we will only really have one shot.<br>
<br>-- Richard<br></div><br>
------=_Part_33515_20951018.1214341938247--
More information about the Panel-devel
mailing list