Keypirinha

Extend String Extension

Unpack script from here:

C:\Users\mo\Desktop\Keypirinha\default\Packages\String.keypirinha-package

Add script here:

C:\Users\mo\Desktop\Keypirinha\portable\Profile\Packages\String\string.py

And then it's being overwritten and live reloaded.

Slug Case Conversion

https://github.com/Keypirinha/Packages/pull/38

Slug Case available in 2.25

General Plugin Development

  • the Keypirinha modules are in this repository: Keypirinha/PythonLib
  • I haven't managed to get auto complete working in VSCode (I only got it working in Pycharm), so you have to read a bit more rather than let auto complete help you
  • calling the methods in an interactive python console, while possible, it wouldn't help you much, because you want to generally see what your code does in keypirinha

In my opinion the best way to develop a plugin is with the live reload feature of keypirina (also see the online documentation):

  • put your plugin module (the python file with your class derived from keypirinha.Plugin) in the seperate directory in %APPDATA%\Keypirinha\Packages (installed mode) or \portable\Profile\Packages (portable mode) for example: for a new plugin "awesome" the plugin class has to go into %APPDATA%\Keypirinha\Packages\awesome\awesome.py

    import keypirinha as kp

class Awesome(kp.Plugin):
[...]

    this way everytime you change the awesome.py file, keypirinha automatically reloads the plugin

  • you can't debug your code with a debugger and step through line by line but the Keypirinha: Console (Shortcut F2) is your best friend. You can log things there with self.info, self.warn, self.err and you set the self._debug attribute to True you can also use self.dbg

additional hints:

  • have a look at other plugins github.com/topics/keypirinha (github repos tagged with keypirinha) or ue.spdns.de/packagecontrol (all packages available via PackageControl
  • as a rule of thumb: any code that is not directly related to keypirinha, say complicated logic to parse a file or request some webservice should be developed outside of keypirinha with a normal python debugging enviroment and after its done (working) added to the keypirinha plugin.

If you have any more questions, feel free to visit the gitter chatroom and ask them there. (The keypirinha user base is quite small, so you may have to have some patience with answers)

Source: https://github.com/Keypirinha/Keypirinha/issues/413

Docs: FileZilla Package Portable location of sitemanager.xml

It's not entirely clear where Keypirinha expects to find the sitemanager.xml in Filezilla Portable mode. I think it should be mentioned either in the docs or in the config file, that Keypirinha looks for ./config/sitemanager.xml as described in the package code:

# List configured sessions
# To do that, we first have to detect if FileZilla is in Installed or
# Portable mode. The steps are described by the official documentation
# at: https://wiki.filezilla-project.org/Client_Installation#With_zip_version

# select config file
if os.path.isfile(os.path.join(os.path.dirname(exe_file), "fzdefaults.xml")):
    # Portable mode enabled, configuration files are stored in the
    # 'config' directory located in the same directory than the
    # executable
    sessions_file = os.path.join(
        os.path.dirname(exe_file), "config", "sitemanager.xml")

I had a little bit of an edge case, where I installed Filezille from Portableapps.com and they setup a ./data/ directory with all FZ config, and I was wondering, why I can't get the sessions displayed in Keypirinha.

The fzdefaults.xml that is used to detect if FZ is running in portable mode leaves it to the user where to store the config data (from the shipped fzdefaults.xml.example):

<FileZilla3>
<Settings>
<Setting name="Config Location">$SOMEDIR/filezilla/</Setting>

TL;DR please add to the docs, that in case of Filezilla Portable, sitemanager.xml is expected to be in $FILEZILLA/config/sitemanager.xml

Source https://github.com/Keypirinha/Keypirinha/issues/432

Use Everything 1.5a search with Keypirinha

The Keypirinha Everything Package is supposed to recognize any Everything instance running, but that's not the case for Everything 1.5alpha

The following fixes it

• #software