Editable script actions

[Paulo Moura Guedes]

On Wednesday 27 February 2008 19:55:16 you wrote:
> +class KPARTS_EXPORT ScriptableMainWindow : public MainWindow
>
> I am not that sure there if that's really the best(TM) solution since it
> means an additional inheritance-hierachy while MainWindow (or better the
> underlying KXMLGuiClient framework) does already provide a bunch of
> flexible ways to integrate own functionality here without introducing an
> own class every consumer needs to inherit from. So, the KXMLGuiClient way
> is to just create an own guiclient and attach aka merge it in.
>
> A good sample here may here how we did it on KDE3 aka Koffice 1.6;
> http://websvn.kde.org/branches/koffice/1.6/koffice/lib/kross/main/scriptgui
>client.h?view=markup
>
> http://websvn.kde.org/branches/koffice/1.6/koffice/kspread/plugins/scriptin
>g/scripting.cc?view=markup shows then how it was integrated.

Agreed. I will investigate this approach. The ScriptGUIClient needs a way to 
access KXMLGUIFactory though, to get the menus...

> +void ScriptableMainWindow::slotEditScriptActions()
> +{
> +    if(!KIO::NetAccess::exists(KUrl(d->userActionsFile),
> KIO::NetAccess::SourceSide, this)) {
> +        KUrl dir = KUrl(d->userActionsFile).directory();
> +        KIO::NetAccess::mkdir(dir, this);
>
> uh? Why create a directory here and where will slotEditScriptActions() be
> used?

It is used when the user wants to add or edit script actions. The user file, 
located in $KDEHOME/share/apps/{application}/scripts/scripts.rc will override 
the one located at (if it exists at all) 
$KDEDIR/share/apps/application/scripts/scripts.rc.

> +        QFile f(d->userActionsFile);
>
> not sure there (without looking at the dox), but does;
>
> d->userActionsFile =
> KGlobal::dirs()->locateLocal("appdata", "scripts/scriptactions.rc");
>
> really locate the writable configfile? 
Yes.
> so, not those that i installed e.g. 
> at /usr/... where !=root does not have write-access anyway. iirc there was
> a method in KStandardDirs that asks for the writeable place, sosomething
> like e.g. ~/.kde/...

Yes, it's locate() vs locateLocal(). Also had this doubt myself :)

> +                QTextStream out(&f);
> +                QString defaultContent =
> +                        QString("<!-- ")
> +                        + QString("\n")
> +                        [...]
> +                        + QString("</KrossScripting>");
>
> lot of lines ;)
> Is it really needed here to create a new QString all the time to just build
> up a string?

Quick and dirty ;)

> +    KRun::runUrl(KUrl(d->userActionsFile), QString("text/plain"), this,
> false);
>
> uh? Guess now I got for what that function is. It is to open the script in
> an external editor, right? 

I don't know what do you mean by the script but it is the file where the 
actions can be defined, e.g.:

<KrossScripting>
    <collection name="file" text="File" comment="File menu">
        <script name="export" text="Export..." comment="Export content" 		
file="export.py" />
    </collection>
</KrossScripting>

A visual editor, similar to designer, in order to edit the menu bar and the 
menus would be cool to have but, like I said, this is just a proof of 
concept.

> Heh, good idea. Though I am not that sure if it 
> should be really hardcoded since e.g. Kexi comes already with an embedded
> scriptingeditor + I am not sure if there is a garantee that there is an
> editor for text/plain registered on !=KDE.
>
> +void ScriptableMainWindow::slotResetScriptActions()
> +{
> +    KIO::NetAccess::del(KUrl(d->userActionsFile), this);
> +}
>
> Guess we should really try to get such logic into an own class that could
> be direct used by the KParts::Plugin. iho that would be really the most
> flexible way and also prevents to touch any line of code at the app itself
> what makes adoption much easier ;)

Agreed.

> Well, maybe it would be even an idea to extend
> koffice/libs/kokross/KoScriptingPart.cpp or probably even turn it into a
> more general usuable kparts::plugin that can be moved to kdelibs/kross/ui/*
> to be reusuable by even more apps?!

Perhaps. Maybe the best would be to change this patch and when it's good, see 
how we can integrate this with KoScriptingPart which has some things specific 
to koffice.

> Re;
>
> Index: kdeui/actions/kstandardaction.cpp
> Index: kdeui/xmlgui/ui_standards.rc
>
> Can't we try to keep changes related to either the kparts::plugin, to code
> in kdelibs/kross/* or to code in koffice/libs/kokross/* ? Guess to spread
> code so much around would make it more difficult to split things e.g. for
> the case kross may move up a step into e.g. kdesupport to be reusuable even
> without kdelibs (e.g. scribus-devels asked for this since a while :) So,
> better no crosschange to thinks like kdeui/* that imho doesn't really need
> to know anything about scripts/kross/etc.

Right. :)

I will come back with a new patch.

Thanks,
Paulo