Question

1.

How can I report a wish, a suggestion, or a comment?

Answer 1

An open source project's greatest strength is derived from getting user feedback. That is why we love to hear what you have to say. Your “gripes” are our instructions. After about 6 months, programmers can no longer see their own mistakes. It is natural. We want the ideas, qritiques, and feedback because we all want to make Krusader the best and most useful file manager available anywhere.

The most convenient way to contact us is to use the krusader-users mailing list. For information on what remains to be done look at the Krusader-devel mailing list. We review and discuss every submission.

Answer 2

It is not easy to write patch guidelines, but here are some.

Patches, new code or new features are always welcome!
Focus only on one problem at a time, so the developers can easily understand you, and commit your patch it works.
Preferably, you can start a discussion with the developers on the krusader-devel mailing lists or on the Krusader GitLab page. Unfortunately, we cannot apply a patch if the patch is in conflict with the “general design” of the Krusader code (read for more instructions in this FAQ). Please send only one change request per mail, so that the discussion is easier to follow. The modifications should be committed step by step, checking each line.
Submit your patch files on the GitLab, so that all patch proposals stay organised and do not get lost, tar.gz archives or diffs are usually ok. Do not copy changes into a mail. Most mailers will change the white spaces, so that the diff will not apply or the code snipped does not diff. In the past, patch mails went lost or disorganized in many many mails, so please use the GitLab, thanks!
Use portable solutions, Krusader should run on:
- All POSIX (Linux®/BSD/UNIX®-like OSes), Solaris™.
- All BSD Platforms (FreeBSD©/NetBSD®/OpenBSD®/Mac® OS).
- KDE 3.3- KDE 3.5 and even on GNOME with kdelibs (for Krusader-2.x) .
- GCC 2.95 - GCC 5.4
Architecture changes are made by the team only.
A final note: always keep in mind a patch might be rejected. Either it has side effects, which we could not fix or it contradicts with the idea behind the patched module. In this sense, a software project differs from, let's say a wiki: a software project has to have someone to make all the final decisions. Otherwise the software will not work. Furthermore: keep in mind that the examination of patches might take time, as we all have private lives.

Answer 3

Bugs?!?!? Well, ok.... We have an online Bug Tracking System.

Using the online bug-tracker helps us have a clear and orderly way to know how many bugs are open, bug priority and follow-ups. It saves us from browsing through the entire Krusader forum, searching for yesterdays bug. Please use this system.

Before reporting a bug, please read the following:

Check if the bug is already posted in the online bug list of the Bug Tracking System.
If you cannot find this bug mentioned, please submit it into the bug tracker by clicking the Submit New button in the bug-tracker window. Please submit the following issues: the Krusader version used, the Linux® distribution + version used, processor type, and as good a description of the problem as you can manage.

Thank you for your co-operation!

Note

If possible, try to do the same operation with Konqueror or another KDE application. If you encounter the same problem then it is possibly a KIO Slaves or KDE Frameworks™ 5 bug, and not a Krusader bug. Krusader uses the KDE Frameworks™ libraries and the KIO Slave for many operations. In some cases you can encounter problems if your distribution is incorrectly configured, please test it first as explained above.

Answer 4

Usually binary packages that are been used by your distribution do not contain debug information. Since we usually only develop and fix Krusader-git, compile Krusader-git in debugmode and install it, than check if the bug still exist.

$ cmake -DCMAKE_BUILD_TYPE=debugfull

Install valgrind, a suite of tools for debugging and profiling Linux® programs. Run Valgrind/Krusader

$ valgrind --tool=memcheck {foo_path}/krusader

The valgrind tool will write to stdout, what really happens. If you could send these information before the crash, it is almost sure, that we may fix or tell you what to do.

Answer 5

Usually binary packages that are been used by your distribution do not contain debug information. Since we usually only develop and fix Krusader-git, compile Krusader-git in debugmode and install it, than check if the bug still exist.

$ cmake -DCMAKE_BUILD_TYPE=debugfull

If the KDEKrashhandler still does not provide useful backtrace information, than sometimes a coredump will give better information. Run Krusader, with disabled crashhandler.

$ krusader --nocrashhandler

On a crash you will get a .core file, usually in your home folder. Run gdb, the GNU Project Debugger

$ gdb -c corefile krusader

Now type bt to get the backtrace and type q to quit gdb. Often the best debug results will be given when using the valgrind tool.

Answer 6

Yes, currently we have several mailing lists. No spam, no bother, just Krusader. Feel free to subscribe and unsubscribe.

Tip. our mailing lists can be browsed online or read with a newsreader, so that you do not even need to subscribe to follow the action on the mailing lists.

Krusader-devel is the developer mailing list (read-only). If you want to follow the development of Krusader on the cutting edge, this is the list to follow.
Krusader-users is the Krusader users mailing list. Here you can ask for help and talk with the Krusader users and developers.
Krusader-news is a very low volume list, used for announcements of new versions or critical bugfixes.

Answer 7

Yes, we do. Several news feeds in various formats are available. krusader-devel feed, krusader-users feed and krusader-news feed.

Answer 8

In the spirit of freedom of speech, everything that is Krusader related can be discussed in our forum. It does not matter if you are a newcomer or an advanced user, everyone is welcome. An open source project's greatest strength is derived from getting user feedback. That is why we love to hear what you have to say. With your feedback we can make Krusader better and better; otherwise, we are not aware of issues and ideas you may have. But please remember the following, so that we can maintain some order in the chaos.

If the Documentation, FAQ and Krusader-devel (please use the search function ) cannot help you, do not hesitate to post on our forum. The Krusader Krew or the Krusader community is always available to help you.

Please use the search function of the KDE Forum, your issue may have been previously discussed (this allows us to minimize the double/triple/... postings). If your issue has already been discussed in the past there is a great chance that you will have an instant solution to your problem. If the issue is currently being discussed, you can join in the discussion. Some questions are asked over and over again, that is why we have created this FAQ. This allows us to spend more time developing Krusader.

Thank you for your co-operation!

Answer 9

If you are interested in translating the Krusader GUI or documentation, please contact the KDE translation team of your language.

Answer 10

You can support Krusader in many different ways. Please send us feedback, bug reports, patches, donations, translations, ...

Answer 11

The two panels and a commandline are available, all the other stuff like OFM features and the OFM interaction with the user is missing from this profile.

Answer 12

An Orthodox File Manager (OFM) is much faster than a one panel filemanager and faster than the command line. If you would like to know how Krusader feels, there is only one way to discover: install it on your computer and use it for a while. If you prefer to waste time and lose productivity, continue to use one panel filemanagers which are based on Windows® Explorer. Matej Urbančič has written a blog on why OFM is better than a one panel filemanager.

http://docs.kde.org/
Prev	Frequently Asked Questions (FAQ)	Next

1.	How can I report a wish, a suggestion, or a comment?
	An open source project's greatest strength is derived from getting user feedback. That is why we love to hear what you have to say. Your “gripes” are our instructions. After about 6 months, programmers can no longer see their own mistakes. It is natural. We want the ideas, qritiques, and feedback because we all want to make Krusader the best and most useful file manager available anywhere. The most convenient way to contact us is to use the krusader-users mailing list. For information on what remains to be done look at the Krusader-devel mailing list. We review and discuss every submission.
2.	How can I send a patch?
	It is not easy to write patch guidelines, but here are some. Patches, new code or new features are always welcome! Focus only on one problem at a time, so the developers can easily understand you, and commit your patch it works. Preferably, you can start a discussion with the developers on the krusader-devel mailing lists or on the Krusader GitLab page. Unfortunately, we cannot apply a patch if the patch is in conflict with the “general design” of the Krusader code (read for more instructions in this FAQ). Please send only one change request per mail, so that the discussion is easier to follow. The modifications should be committed step by step, checking each line. Submit your patch files on the GitLab, so that all patch proposals stay organised and do not get lost, tar.gz archives or diffs are usually ok. Do not copy changes into a mail. Most mailers will change the white spaces, so that the diff will not apply or the code snipped does not diff. In the past, patch mails went lost or disorganized in many many mails, so please use the GitLab, thanks! Use portable solutions, Krusader should run on: All POSIX (Linux®/BSD/UNIX®-like OSes), Solaris™. All BSD Platforms (FreeBSD©/NetBSD®/OpenBSD®/Mac® OS). KDE 3.3- KDE 3.5 and even on GNOME with kdelibs (for Krusader-2.x) . GCC 2.95 - GCC 5.4 Architecture changes are made by the team only. A final note: always keep in mind a patch might be rejected. Either it has side effects, which we could not fix or it contradicts with the idea behind the patched module. In this sense, a software project differs from, let's say a wiki: a software project has to have someone to make all the final decisions. Otherwise the software will not work. Furthermore: keep in mind that the examination of patches might take time, as we all have private lives.
3.	How can I report a bug?
	Bugs?!?!? Well, ok.... We have an online Bug Tracking System. Using the online bug-tracker helps us have a clear and orderly way to know how many bugs are open, bug priority and follow-ups. It saves us from browsing through the entire Krusader forum, searching for yesterdays bug. Please use this system. Before reporting a bug, please read the following: Check if the bug is already posted in the online bug list of the Bug Tracking System. If you cannot find this bug mentioned, please submit it into the bug tracker by clicking the Submit New button in the bug-tracker window. Please submit the following issues: the Krusader version used, the Linux® distribution + version used, processor type, and as good a description of the problem as you can manage. Thank you for your co-operation! Note If possible, try to do the same operation with Konqueror or another KDE application. If you encounter the same problem then it is possibly a KIO Slaves or KDE Frameworks™ 5 bug, and not a Krusader bug. Krusader uses the KDE Frameworks™ libraries and the KIO Slave for many operations. In some cases you can encounter problems if your distribution is incorrectly configured, please test it first as explained above.
4.	How can i send good debug or crash reports?
	Usually binary packages that are been used by your distribution do not contain debug information. Since we usually only develop and fix Krusader-git, compile Krusader-git in debugmode and install it, than check if the bug still exist. `$` `cmake -DCMAKE_BUILD_TYPE=debugfull` Install valgrind, a suite of tools for debugging and profiling Linux® programs. Run Valgrind/Krusader `$` `valgrind --tool=memcheck {foo_path}/krusader` The valgrind tool will write to stdout, what really happens. If you could send these information before the crash, it is almost sure, that we may fix or tell you what to do.
5.	What to do if the KDEcrashhandler sends no useful backtrace information?
	Usually binary packages that are been used by your distribution do not contain debug information. Since we usually only develop and fix Krusader-git, compile Krusader-git in debugmode and install it, than check if the bug still exist. `$` `cmake -DCMAKE_BUILD_TYPE=debugfull` If the KDEKrashhandler still does not provide useful backtrace information, than sometimes a coredump will give better information. Run Krusader, with disabled crashhandler. `$` `krusader --nocrashhandler` On a crash you will get a `.core` file, usually in your home folder. Run gdb, the GNU Project Debugger `$` `gdb -c corefile krusader` Now type bt to get the backtrace and type q to quit gdb. Often the best debug results will be given when using the valgrind tool.
6.	Does Krusader have a mailing list?
	Yes, currently we have several mailing lists. No spam, no bother, just Krusader. Feel free to subscribe and unsubscribe. Tip. our mailing lists can be browsed online or read with a newsreader, so that you do not even need to subscribe to follow the action on the mailing lists. Krusader-devel is the developer mailing list (read-only). If you want to follow the development of Krusader on the cutting edge, this is the list to follow. Krusader-users is the Krusader users mailing list. Here you can ask for help and talk with the Krusader users and developers. Krusader-news is a very low volume list, used for announcements of new versions or critical bugfixes.
7.	Does Krusader provide news feeds?
	Yes, we do. Several news feeds in various formats are available. krusader-devel feed, krusader-users feed and krusader-news feed.
8.	How does the Krusader forum work?
	In the spirit of freedom of speech, everything that is Krusader related can be discussed in our forum. It does not matter if you are a newcomer or an advanced user, everyone is welcome. An open source project's greatest strength is derived from getting user feedback. That is why we love to hear what you have to say. With your feedback we can make Krusader better and better; otherwise, we are not aware of issues and ideas you may have. But please remember the following, so that we can maintain some order in the chaos. If the Documentation, FAQ and Krusader-devel (please use the search function ) cannot help you, do not hesitate to post on our forum. The Krusader Krew or the Krusader community is always available to help you. Please use the search function of the KDE Forum, your issue may have been previously discussed (this allows us to minimize the double/triple/... postings). If your issue has already been discussed in the past there is a great chance that you will have an instant solution to your problem. If the issue is currently being discussed, you can join in the discussion. Some questions are asked over and over again, that is why we have created this FAQ. This allows us to spend more time developing Krusader. Thank you for your co-operation!
9.	How can I translate Krusader into my native language?
	If you are interested in translating the Krusader GUI or documentation, please contact the KDE translation team of your language.
10.	How can I support Krusader?
	You can support Krusader in many different ways. Please send us feedback, bug reports, patches, donations, translations, ...
11.	Why is Konqueror in “Midnight Commander style” not an OFM?
	The two panels and a commandline are available, all the other stuff like OFM features and the OFM interaction with the user is missing from this profile.
12.	Why should I use an OFM?
	An Orthodox File Manager (OFM) is much faster than a one panel filemanager and faster than the command line. If you would like to know how Krusader feels, there is only one way to discover: install it on your computer and use it for a while. If you prefer to waste time and lose productivity, continue to use one panel filemanagers which are based on Windows® Explorer. Matej Urbančič has written a blog on why OFM is better than a one panel filemanager.

Prev	Contents	Next
Usage FAQ	Frequently Asked Questions (FAQ)	Credits and License
http://docs.kde.org/

General FAQ

Note