KDE 4.9 has branched, and so the Pâté plugin “host” for Python plugins has moved from Kate’s playground to be a mainstream plugin. Since a plugin-for-plugins might be a bit confusing, here is a quick tour of how it is managed and works, and especially a few rough edges it still has.
NOTE If you’ve installed this from a package, hopefully your distro will have added kate.so under PyKDE4 as needed, but if you are building from source, see the notes at the end of this post.
Start by enabling the enabling the Pâté plugin:
That should cause the Pâté plugin’s configuration page to pop into existence, but you may need to press the Reload button to see the right hand pane filled in like this:
Enable specific Python plugins of interest, and press the Reload button. The comment will be set to “Loaded”, then close and reopen the dialog (rough edge #1) to see any new configuration pages that the plugin provides:
Go back to the Pâté plugin’s configuration page, and now look at the second tab:
Use the combo box to select one of the built-in support modules (kate and kate.gui) or any of the loaded plugins. The first tab shows HTML documentation for the Python code and you can see any actions it has added into the Kate UI on the second tab (this will be empty for the built-in modules, but not for console):
It looks as though the Python console has added one entry to the View menu, alog with a shortcut. And so it has:
Yaay! See if you can guess what to do next 🙂
IF YOU HAVE BUILT FROM SOURCE
And then installed the results in say /usr/local, attempting to enable the plugin may result in a crash with something this on the terminal:
> File "/home/.../kate/plugins/pate/kate/__init__.py", line 38, in <module> from PyKDE4.kate import Kate > No module named kate > Could not import kate"
This is because the Pate build should install kate.so as part of the PyKDE4 bindings, but typically, a developer build will install this locally, and not to where the remaining system-supplied PyKDE4 files are installed:
Install the project... -- Install configuration: "RelWithDebInfo" -- Up-to-date: /usr/local/lib/python2.7/dist-packages/PyKDE4/kate.so ...
The system-supplied PyKDE4 binding modules should be in Python’s sys.path:
srhaque> python Python 2.7.3 (default, Apr 20 2012, 22:39:59) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.path ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7']
For me, Ubuntu puts PyKDE4 at /usr/lib/python2.7/dist-packages/PyKDE4, so we need a link from there to the actual location:
srhaque> ls -l /usr/lib/python2.7/dist-packages/PyKDE4/kate.so
lrwxrwxrwx 1 root root 53 May 20 09:51 /usr/lib/python2.7/dist-packages/PyKDE4/kate.so -> /usr/local/lib/python2.7/dist-packages/PyKDE4/kate.so
Note that just having this location in PYTHONPATH and/or in sys.path does not work because the PyKDE4 needs an __init__.py to be seen (see the one in the system directory to understand why).
I’ve not thought of a good way to simplify this for developers, and I assume end-users won’t see it because we’ll install in the default path. Suggestions/fixes welcome.