This is done by editing your commands.xml file and creating the view and edit commands.

For an in-depth explanation, read the documentation.

There could be many reasons for this, but the most common ones are:

You're running muCommander on a system that isn't officially supported. See this page? for information on how you can have your system supported. Your commands or associations? file is corrupt. Try deleting them. You're running muCommander on a known system but with a configuration that we haven't encountered before. See this thread for an example.

Because you haven't defined any commands for it to use. Please read this article for more information.

Simply put, because we haven't found how. As far as we know, Java doesn't allow us to use system dependent things like that.

If you know better and can point us in the right direction with code samples or documentation links, we'd be happy to hear about it.

At the time of writing, you can't.

This is an often requested feature, one that we're thinking about and have a few ideas on how to implement, but it's not there yet.

When you double-click or press Enter on an OpenOffice? document, the document's internals are revealed, which may seem a bit awkward. ODF files are actually ZIP files, and muCommander recognises them as such: when you try to open one, muCommander will show you the contents of the archive rather than start Open Office.

In order to start Open Office, you need to open "natively" (mapped to Shift Enter by default) the document.

This question is closely linked to the previous one: OS X .app files are in fact directories, and muCommander will browse them rather than start the application. You need to open them "natively" (mapped to Shift Enter by default).

The short answer is, because you're not running Java 1.6 or higher.

Until version 1.6, Java did not know how to set file permissions on local files. Extracting executable files from archives (or copying them, for that matter) will drop the executable flag, preventing you from executing it.

If you can upgrade to Java 1.6, we advise you to do so. If you can't, however, you only need run chmod +x on the file for it to become executable again.

As much as we respect Apple, this is actually their fault.

Java under OS X doesn't integrate properly with Spaces. Depending on which version of Java you're running, support might improve. Upgrading to Java 1.6 is usually a good idea, as it appears to have the best support: the only thing that doesn't work is tying muCommander to a specific Space.

Edit ~/Library/Preferences/muCommander/commands.xml to include the line:

<command alias="view" value="qlmanage -p $f" type="system"/>

Previous issues regarding slowness and missing ESC are no longer an issue.

The iCloud directory is browsable at ~/Library/Mobile Documents/com~apple~CloudDocs/

You can add it as a bookmark for quick access.

In the copy popup, press Run in background. If the copy task is already running, press the Hide button in the lower right corner.

That's a problem we've encountered a few times when running muCommander on Linux. You can find detailed information in ticket #48, but if you just need a quick fix:

Open the file ~/.Xdefaults. Add the line: *.multiClickTime: 500. Run xrdb -merge ~/.Xdefaults.

Before opening the .dmg, open terminal and run:

xattr -d com.apple.quarantine ~/Downloads/mu(c|C)ommander-*.dmg

If you have already opened the .dmg, use finder to eject/unmount the .dmg, run the xattr command, open the .dmg again and drag muCommander to applications (again), or run this:

xattr -r -d com.apple.quarantine "/Applications/muCommander.app"

There are many ways you can contribute to the project, take a look this page for a few ideas. Your help is greatly appreciated!