Updated 48 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)


  • 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).

Release Howto

NOTE: Don't follow this blindly. Think, test and improve if required!


(Information can be outdated and incomplete though.)

First time use:

mkdir -v krusader-build && cd krusader-build
git clone git://
git clone git://

Make final changes in repository:

  • Search in git log for changelog messages and add them to the krusader/ChangeLog file:
cd krusader

(Add changes from bugzilla bug reports and Phabricator differentials by hand if necessary.)

  • Set new version (and release name) in CMakeLists.txt and README
  • Commit:
git pull
VERSION=`cat CMakeLists.txt | grep 'set(VERSION' | awk -F '"' '{print $2; }'`
git commit -a -m "New release version: ${VERSION}"
  • Check:
    • clean repository (git status)?
    • compiling?
    • running/major bugs?
    • documentation up-to-date?

Tag and Push

git tag -a v${VERSION} -m "Tagging krusader-${VERSION}"
git push --follow-tags

Create tarball

cd ../kde-dev-scripts/createtarball/
create_tarball_kf5.rb -n -v $VERSION -a krusader
mv -vi krusader-$VERSION ../..
mv -vi krusader-$VERSION.tar.xz ../..
cd ../../

Test package

NOTE: corrupted translated documentation can break compiling, do this!
mkdir -v build-${VERSION} && cd build-${VERSION} &&
cmake -DCMAKE_INSTALL_PREFIX=../install-${VERSION} -DQT_PLUGIN_INSTALL_DIR=../install-${VERSION} ../krusader-${VERSION} && make -j 3 && make install ; cd ..

Upload source package to KDE server

sha1sum krusader-${VERSION}.tar.xz &&
sha256sum krusader-${VERSION}.tar.xz

curl -T krusader-${VERSION}.tar.xz

create new sysadmin request:

Ask the friendly sysadmins on Phabricator to publish the package, something like:

Package pending for Krusader

New release for the Krusader project. Package is uploaded to

Desired destination: stable/krusader/{version}

{sha1 hash}
{sha256 hash}

And please add this release to the list of Krusader version on


Explanation for And please add this release to the list of Krusader version on

To add versions on Bugzilla the 'editcomponents' permission is needed. This is equal to be able to change settings for ALL projects. Therefore only sysadmins can do this and nobody of the Krusader devs.


  1. Change/add links on website
  2. Write notification to krusader-user, krusader-devel, krusader-news and mailing lists
  3. Add new version to list of versions on (TODO how?)
  4. Set next beta version in CMakeLists.txt and commit:
VERSION=`cat CMakeLists.txt | grep 'set(VERSION' | awk -F '"' '{print $2; }'`
git commit -a -m "New beta release version: ${VERSION} &&
git push"
Last Author
Krusader, abika