ScripterNG: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 108: Line 108:
''I'd like to have some logical "object-related" structure for it. Something like e.g.:''
''I'd like to have some logical "object-related" structure for it. Something like e.g.:''
   scribus.Document().pages[0].items[0].text()
   scribus.Document().pages[0].items[0].text()
Henning:
'' I had similar thoughts. Instead of methods we can use the properties in Python directly:''
scribus.CurrentDocument.Pages[0].Items[0].Text
''This will call the get- and set-methods automatically.''
Perhaps we should design an API which is similar to the API used in KOffice:
* [http://techbase.kde.org/Development/Tutorials/KWord_Scripting KWord]
* [http://techbase.kde.org/Development/Tutorials/KSpread_Scripting KSpread]
* [http://techbase.kde.org/Development/Tutorials/Krita_Scripting Krita]


See also the wiki page on [[public C++ API]]
See also the wiki page on [[public C++ API]]
Line 114: Line 125:
= Comparison with Kross =
= Comparison with Kross =


ScripterNG and [http://en.wikipedia.org/wiki/Kross_(KDE) Kross] both use the introspection features of Qt. The script language would not see any difference between called by ScripterNG or Kross. So if we start writing the C++ api now, we could switch later to Kross and could still use this api.  
ScripterNG and [http://en.wikipedia.org/wiki/Kross_(KDE) Kross] both use the introspection features of Qt. The script language would not see any difference between called by ScripterNG or Kross. So if we start writing the C++ API now. We could switch to Kross later and could still use this API.  


Kross btw is great but it currently still depends on kdelibs. ScripterNG is available now. Of course it isn't that mature but it depends on mature technologies (PyQt, sip, pythonize).  
Kross btw is great but it currently still depends on kdelibs. ScripterNG is available now. Of course it isn't that mature but it depends on mature technologies (PyQt, sip, pythonize).  

Revision as of 22:20, 14 November 2007

This article is part of the Scripts series.


ScripterNG is a new plugin to provide scripting facilities in Python and Javascript (actually Ecmascript via QtScript). The plugin is still in development and was based on the myplugin example code which is also documented in the Plugin-Howto.


Quickstart

  • get Scribus from svn trunk (the Qt4 port is needed)
  • get latest snapshot from http://henning.cco-ev.de/scribus/scripterng.tgz
  • extract the files into the plugin directory (scribus/plugins/scripterng)
  • add ADD_SUBDIRECTORY(scripterng) in scribus/plugins/CMakeLists.txt
  • (perhaps disable scriptplugin for testing)
  • install python-dev, python-qt4-dev, perhaps sip-dev if you haven't already
  • run cmake, make, make install
  • go to scribus/plugins/scripterng/scribuspyqt
  • run cmake, make and copy *.py and *.so to INSTALLPREFIX/lib/scribus/plugins/scripterng (sorry this is a bug)
  • start scribus
  • create/open document
  • menu Extras -> ScripterNG
  • test and see messages on console
  • send patches - thanks :)
  • retry, fix thinks I forgot to mention here..


Development

About the files

  • cmake/modules/*
    • Some extra macros from PyKDE to find SIP and PyQt.
    • They are used in scribuspyqt/. There seems to exist some conflicts with other existing macros.
    • So I had to compile scribuspyqt alone
    • I am not sure if they work well on Windows.
  • pythonize.{cpp,h}
    • This is a nice small interface to use Python in C++
  • scripterng.{cpp,h}
    • hooks into Extras menu
    • low level plugin stuff (like in myplugin)
  • scripterngimpl.{cpp,h}
    • parent is QApplication::instance()
    • sets objectName to ScripterNG (only named objects are exposed)
    • loads Python and runs scripterng.py on startup
    • implements example function: aboutScripterNG()
    • object is magically available as Application.ScripterNG
  • scribuspyqt/scribuspyqt.{cpp,h}
    • compiles to libscribuspyqt.so
    • provides additional code to wrap without sip
    • invokeMethod using variants (to call unwrapped objects)
  • scribuspyqt/scribuspyqt.sip
    • sip interface to make invokeMethod available to Python
    • creates python module _scribuspyqt.sip
    • links against libscribuspyqt.so
  • scribuspyqt/scribuspyqt.py
    • import this module instead of _scribuspyqt directly
    • PyQtObject can be used to wrap any QObject
      • slots can be called like methods
      • full property support
  • scribuspyqt/scripterng.py
    • called at startup from plugin
    • looks for application instance and makes it available
    • will be used to hook into Scribus with PyQt, to provide menus to load scripts etc
  • scribuspyqt/pyqtscript.py
    • prove of concept: activates QtScript from Python
    • no speed loss
    • mix Python and QtScript
  • scribuspyqt/compat.py
    • start of a compatibility layer
    • provides same api as the "old" scripter

Making functions available to ScripterNG

Here is an example:

class CoreModule : QObject {
   CoreModule();
   public slots:
      void quit(bool ask_save);
      int answer();
}
CoreModule::CoreModule() : QObject(
          QApplication::instance()->findChild("ScripterNG")) {
  setObjectName("Core");
}
void CoreModule::quit(bool ask_save) {
  if (ask_save() && confirm() .. ) {
     qDebug("Bye");
     QApplication::instance()->quit();
  }
}
int CoreModule::answer() {
  return 42;
}
CoreModule *m_core = new CoreModule();

Now you can do

>> print Application.Core.answer()
42
>> Application.Core.quit(true)
Bye


API brainstorming

Petr wrote: I'd like to have some logical "object-related" structure for it. Something like e.g.:

 scribus.Document().pages[0].items[0].text()

Henning: I had similar thoughts. Instead of methods we can use the properties in Python directly:

scribus.CurrentDocument.Pages[0].Items[0].Text

This will call the get- and set-methods automatically.

Perhaps we should design an API which is similar to the API used in KOffice:


See also the wiki page on public C++ API


Comparison with Kross

ScripterNG and Kross both use the introspection features of Qt. The script language would not see any difference between called by ScripterNG or Kross. So if we start writing the C++ API now. We could switch to Kross later and could still use this API.

Kross btw is great but it currently still depends on kdelibs. ScripterNG is available now. Of course it isn't that mature but it depends on mature technologies (PyQt, sip, pythonize). One main difference is that ScripterNG tries to do most stuff in Python. So it can be more flexible and development should be faster. Any sensible speed loss by this approach is not expected.

Kross also only has support for KJSEmbed (part of kdelibs) and not for QtScript (see http://akademy.kde.org/conference/slides/kjsembed-and-qtscript.pdf).