Updated 23 Days AgoPublic

A twin panel file manager. Written in C++11 with Qt5 and KF5.

Useful links


  • Forum (same purpose as user mailing list)



  • Repositories
    • Source code
      • Read-only: git://
      • Developer access:
      • Web-based browser
      • GitHub mirror (read-only, no pull requests accepted)
    • Website
      • Read-only: git://
      • Developer access:
      • Web-based browser
  • Jenkins (automatic build server, supports an RSS feed for the build status of origin/master)
  • Krazy (static code analysis service)
  • Coding Style (KDE Frameworks coding style is preferred for Krusader project)


  • IRC-channel: (good place for quick questions regarding everything KDE related)
  • Freedesktop icon names (official standard icon names, try to use these instead of names only included in Breeze to be more independent from the icon theme used)


I want to contribute. How to submit my first patch?


  1. Get a KDE identity account
  2. Create a new Diff:
  3. Wait for somebody to review and accept your diff.
My patch has been accepted, what now?

See workflow documentation, for your first patches you will usually have to ask your reviewers to land them.

I want to fix a bug but there is no bug report for it yet. Do I need to file one?

No, not if you are certain that it really is a bug. Feel free to just submit a review.

I am unsure about the right approach to solve an issue, what is the best place to discuss?

Ask us on the developer mailing list.

Commit/Patch guidelines

If your changes are important enough to be included in the changelog, please add a line to the commit message OR summary text for the differential on Phabricator beginning with one of these keywords {FIXED:, ADDED:, CHANGED:, REMOVED:} and a description.

CHANGED: When the big red button is pressed, foo is activated and not bar anymore

(This line does not have to be title of the commit message/differential.)

If your commit/patch fixes a bug reported on, use the FIXED: keyword, add the bug number in square brackets and trigger the Git hook to close the bug.

FIXED: [ 654321 ] The most important bug Krusader ever had
BUG: 654321

Best practice "Git vs. Phabricator" workflow

NOTE: this is only my point of view (Alex). You can use your own workflow but be sure it is "good". If you are new to Phabricator (or Git), better do as it is described here.

Phabricator has a major design flaw: it alters Git commits. When a differential diff is created with arc diff, the last commit message is modified with potentially a huge unformatted summary text and information specific to Phabricator. These are definitely NOT good commit messages. Second, when landing the diff, all commits are squashed into one. This is against the "split changes into logical chunks"-rule for version control systems. This is default and can be changed (with the --merge flag). It is still annoying.

Here is are workflow for circumventing unwanted modifications:

  • Create a new feature branch:

git checkout -b feature/new-foobar-widget

  • Make your changes/commits normally you would in Git
  • When done, you can upload your changes to Phabricator for review but before copy your feature branch for arc:

git checkout -b feature/new-foobar-widget-arc

  • Now upload with nice information:

arc diff --reviewers "#krusader"

Added new foobar widget

Bla, Bla, Bla Mr. Freeman.

  • Wait ... until you changes are accepted. Merge the non-arc branch with master:
    • Make sure you're up-to-date:

git checkout master && git pull --rebase && git checkout feature/new-foobar-widget && git rebase master

  • Finally merge and add title and a reference to the Differential diff to the merge commit message:

git checkout master && git merge --no-ff feature/new-foobar-widget

Merge branch 'feature/new-foobar-widget'

Added new foobar widget
Differential Revision:

Done with git pull! The Differential diff should be automatically be closed (because of the reference).

Last Author
Krusader, abika