Revive External Tools plugin
Needs ReviewPublic

Authored by dhaumann on Fri, Jan 4, 9:09 PM.



This brings back the External Tools plugin that was removed with
commit e443c58df03e9fb8f26b67e86852f708d097517a for KDE 4.8.

Revival is motivated by the fact that we seem to add more and more
tools in context menus which not always makes sense (e.g. having
lots of hard-coded git tools in the Projects plugin). It makes
more sense to e.g. enable launching git-cola as external tool,
which was also used for testing: git-cola -r %directory

The code is still old, and as such or rather low quality. There
are ugly casts from parent()->parent() to some magic widget type,
some strange connects in the plugin handling etc.

All in all, this is just a work-in-progress state such that you
can play around with it, and that we can discuss where we want to
go with this plugin.

Currently, the contents of the "Scripts:" multiline edit is
executed in a shell environment /bin/sh. While this is quite
flexible, we definitely also lack several features, namely:

  • we cannot replace selected text (think of clang-format)
  • we cannot use e.g. /bin/python or other interpreters
  • the KTextEditor::Command integration is broken, since the KTextEditor::Command registers itself on creation, which is a point in time where we currently do not know the commands yet. This needs refactoring to work in a different way.
  • Saving and loading is done via KConfig. We may want to use some json-based solution instead nowadays.
  • There are no default external tools.

More features that come to my mind:

  • Redirect output of external tool into editor
  • Redirect output of external tool into a toolview / sidebar
  • Make %project available in the macro expander, if the Projects plugin is loaded
  • launch external tool in a new embedded terminal
  • assigning shortcuts works, but only in a two-step approach, i.e. first create the tool, then go to the shortcuts editor dialog.
  • syntax highlighting in the "Scripts:" multiline edit
  • currently, since we allow arbitrary scripts, we cannot check whether a tool is really available and then hide or disable it.

Porting notes:

Diff Detail

R40 Kate
No Linters Available
No Unit Test Coverage
Build Status
Buildable 7333
Build 7351: arc lint + arc unit
dhaumann created this revision.Fri, Jan 4, 9:09 PM
Restricted Application added a project: Kate. · View Herald TranscriptFri, Jan 4, 9:09 PM
Restricted Application added a subscriber: kwrite-devel. · View Herald Transcript
dhaumann requested review of this revision.Fri, Jan 4, 9:09 PM
dhaumann edited the summary of this revision. (Show Details)Fri, Jan 4, 9:13 PM
dhaumann edited the summary of this revision. (Show Details)
dhaumann edited the summary of this revision. (Show Details)Fri, Jan 4, 9:22 PM
ngraham added a subscriber: ngraham.Sat, Jan 5, 3:51 AM

This is so cool! What an awesome feature!

pino added a subscriber: pino.Sat, Jan 5, 11:52 AM

Can you please add a "kate" prefix to the message catalog? See TRANSLATION_DOMAIN in CMakeLists.txt, and

Btw, there is also an External Scripts plugin in KDevelop - worth a look as well, see screenshot from Qt Designer:

Maybe we should steal that one?

I've been searching a bit what other editors can do and finally came up with this proposal:

Most of the stuff is hopefully self-explaining. Anyways:

  • The tool type "Application" will turn the Executable field into a required field. In this case, the Arguments are the args that are passed to the executable
  • The tool type "Bash Script" etc. are scripts. Then the Executable field is optional and used only if set to check whether the tool should be visible. The label "Arguments" then changes to "Script:".

More could be added later, such as environment variables, Error output (stderr) handling, Working directory.

Is it worth to proceed with this? Comments?

Looks fantastic!!! This would make Kate so powerful.

One typo: documet -> document

brauch added a subscriber: brauch.Wed, Jan 9, 9:10 PM

Thanks for working on this!
Something which would be quite powerful too would be to execute a tool on saving a file. This would e.g. allow integrating formatting tools such as golang's very easily.

gregormi added a comment.EditedWed, Jan 9, 9:40 PM

This is definitely worth to proceed, thanks!

Some things that come to my mind

  • Set a keyboard shortcut (like in KDevelop's screenshot)
  • +1 to "On-Save" trigger, as sbrauch suggested (then the order of the tools - if there than one is allowed - should be considered)
  • Ability to define tools that can be shipped with Kate by default (e.g. git commands like view history for current file, blame, commit)
  • Run in separate Konsole (if it is an interactive tool like a debugger, profiler, git interactive rebase etc.)
    • or in a always fresh Konsole located in Kate's view pane (using bash history it would be possible to redo the command with altered parameters)
  • Ability to see the exact command with all placeholders expanded prior to executing for analysis or manual tweaking
  • More control over the output pane; this is more about the capability of Kate's output panes:
    • Code checkers would need a list result (e.g. see the Project's plugin's Code Analysis result view) with parsing logic of the text output
    • For compiler output it would be nice if there is plain text output on the one hand and parsed output on the other hand (to easily step through the error list)
  • Control of where the external tool can be invoked: main menu, editor view's context menu, tab context menu, project plugin's tree context menu
    • Tagging or another categorization mechanism to be able to give many tools some structure
dhaumann added a comment.EditedWed, Jan 9, 10:41 PM

After some more investigation, the current designer file look as follows:

For the other requests:

  • most of the stuff is out of scope in the first iteration, especially since it would require to first heavily improve other plugins / features.
  • Having a preview of expanded variables would be great.
  • "Run in embedded terminal" could be added as checkbox. Or would it be enough to have an additional entry in Output: Display in Embedded Konsole?
  • Shortcuts: This is supported by opening the Shortcut Dialog afterwards. I would like to avoid having yet another button here (albeit I see a minor usability issue here)
dhaumann updated this revision to Diff 49297.Fri, Jan 11, 9:08 PM

Work in progress:

  • Port UI to Qt Designer file
  • Rename 'tryexe' to 'executable'
  • Cleanups
  • Merge branch 'master' into revive-externaltools-plugin
  • Update Copyright
dhaumann updated this revision to Diff 49909.Sat, Jan 19, 10:55 PM
  • Factor out KateExternalTool into separate file
  • Add ExternalToolRunner unit test skel
  • Factor out KateToolRunner for better unit testing
  • Introduce enum class SaveMode
  • Move load/save code to KateExternalTool
  • Rename member variable config to m_config
  • Initialize member variables
  • Simplify serialization and deserialization
  • Rename acname to actionName
  • Adapt default tools to new config file format
  • Rename test to a more generic name
  • Preliminary test for loading & saving external tool data
  • Start implementing KateToolRunner
  • Test for /home in ls output
  • Add some FIXMEs for later
  • Add checkbox "[x] Include output from stderr and port to QRegularExpression

Long not in a working state, so no review required.