Lessonsload648

• New 'Calculate checksum' feature added to the 'File' menu (mapped onto Shift+Alt+K by default) which calculates the checksum of selected files and writes them to a file in a standard format. The following checksum algorithms are provided: Alder32, CRC32, MD2, MD4, MD5, SHA-1, SHA-256, SHA-384 and SHA-512
• New 'Verify data integrity' transfer option that ensures that the files are strictly identical on the source and destination after being transferred. This option slows down transfers significantly but can prevent data loss on unreliable mediums
• Files can be marked/unmarked using a Regexp
• Added 'Owner' and 'Group' columns (disabled by default). The owner and group information is available on FTP and SFTP folders and some TAR archives
• Custom look&feels can now be imported from the preferences dialog
• New 'Mark selection' feature (mapped onto Shift+Add by default) that lets users mark all files whose extension match that of the current selection
• New 'Open in other panel' feature (mapped onto Shift+Alt+ENTER by default) that opens the current selection in the other panel
• New 'Open in both panels' and 'Go to parent in both panels' features (mapped onto Meta+Enter and Meta+Backspace by default) that open browsable files with a similar name in both panels
• 'Mkfile' can now allocate space to the newly created file
• New 'Rename' option added to file operations, allowing files that already exist in the destination to be renamed (contributed by Mariusz Jakubowski)
• Windows: 'Delete' now moves files to the Recycle Bin by default
• Windows: the Recycle Bin can be opened and emptied from the status bar
• Significantly improved the throughput of FTP uploads
• Significantly improved the throughput of transfers into Zip files
• Added an 'Explore bookmarks' item to the 'Bookmarks' menu
• Job confirmation dialogs show the list of files to be processed
• All OK/cancel choices can be navigated with the arrow keys
• Added keyboard shortcuts to 'Change date' and 'Change permissions' actions
• Visual enhancements made to the main window under Mac OS X 10.5 (Leopard)
• Improved file loading in the internal viewers and editors
• File encoding can now be changed in the internal text viewer and editor
• HTTPS connections can now be established even if the SSL certificate is not trusted
• Added a dedicated icon for the root of remote locations
• jCIFS library upgraded to version 1.2.18e
• J2SSH library upgraded to version 0.2.9
• Commons-net library upgraded to version 1.5.0 (svn snapshot)

These file manager replacement tools aren’t new or rare, but what sets muCommander apart is the fact it’s cross-platform. It’s not been built natively for Windows, Mac and Linux – instead, it utilises Java so development is concentrated on a single build, but applies equally to all versions. There are many alternatives to muCommander for Linux if you are looking to replace it. The most popular Linux alternative is Double Commander, which is both free and Open Source.If that doesn't suit you, our users have ranked more than 50 alternatives to muCommander and many of them are available for Linux so hopefully you can find a suitable replacement.

Ten years ago (2008) I submitted my first contribution to an open source project named muCommander that I maintain to this day. This post provides a short description of the project, recent changes we have made, challenges we are facing, and some future plans.

muCommander is a lightweight, cross-platform file manager with a dual-pane interface. It runs on any operating system with Java support (Mac OS X, Windows, Linux, *BSD, Solaris…).

In other words, muCommander is a long-standing (since 2002) open-source (GPLv3) file manager with a dual-pane interface (similar to that of Norton Commander) that can run on all the mainstream operating systems.

First and foremost, muCommander supports various file formats (e.g., ZIP) and protocols (e.g., SMB). It complements common built-in file managers with additional file formats, like 7z, and capabilities, like on-the-fly editing of ZIP files on Mac OS X. Moreover, it eliminates the need to set up protocol-specific clients, such as an FTP-client.

And not only that muCommander supports many file protocols but it also abstracts reads and writes with Java input/output streams. That way, reading from a remote file protocol and writing to another remote file protocol can be made very efficient. For instance, it can read files from an FTP server and write them to an SMB server without writing them to a temporary persistent location. That is done by reading a portion of the file from an input-stream connected to the FTP server and immediately write it to an output-stream connected to the SMB server.

These great capabilities are provided on all mainstream operating systems (OS). By having its core and most of its functionality written in Java, muCommander becomes cross-platform. Except for some OS-specific features that use native code (e.g., moving files to the trash), everything is implemented in the Java language. For developers it is significant as it conforms the principle of write once, run anywhere.

Another benefit of being implemented in Java is that muCommander can leverage the large variety of third-party client-side libraries for different file protocols.

Honestly, the project pulse has not been that great recently. I will touch that later on. Nevertheless, some important changes were done.

Technical

• Converted the code repository to Git.
• Moved the project to GitHub.
• Replaced the build system with Gradle.
• Enable compiling the code with Java 9 and Java 10.
• Manage translations in the Zanata platform.
• Fixed various bugs.

Communal

• Updated the website.
• Revived the twitter account.
• Use Gitter.

Mucommander Java Mac Download Software

Next, I describe the four major challenges I see at the moment that hinder the progress of the project.

Scaling the development model

From time to time we get some really nice contributions as well as issues that users report. However, we currently have a fairly large codebase that becomes hard to maintain by a single maintainer. That causes PRs and issues to occasionally wait relatively long time for getting attention.

Communicating with the community

The contributions we get and issues that are being filed are a good sign as they show that both developers and end-users are interested in and using muCommander.

We used to communicate with the developer and user communities by Google group, Forum, and IRC channel. All these are practically abandoned. Seems like both the GitHub issues/PRs and Gitter provide good alternatives for communicating with developers. It may feel like the tools we currently use do not provide a good alternative to the Google group and the Forum for getting feedback and ideas from users though. But on the other hand, that may also be a consequence of the relatively low traffic in general in the project these days.

Competitive products and projects

There is a large variety of alternative file managers nowadays. Some of them target a specific operating system and thus are sometimes faster and better integrated (the most interesting are probably those that target Mac OS X, that is used by most of our user base). Some are backed up by commercial organizations. Those are typically proprietary products that provide base funtionality for free and other paid capabilities.

Another type of alternative products are those that have forked from muCommander in the past. Some forks that we have made contact with complained about the development pace of the project that they claim is too slow. That is a shame since migrating features from these forks to muCommander is not always trivial and it could have been much more productive to join forces in a single project.

Technical debts

Some features that were recently introduced exposed gaps in our application. Here, I describe two of them:

1. As mentioned before, muCommander was designed to be a lightweight file manager, something one can deploy on a minimal USB stick and execute on different machines. That is why we use proguard to shrink the jar that is being produced. Nontheless, the size of the produced jar increased due to features such as supporting vSphere VMs file system that brought with it a dependency of size 3.3M.
2. When considering something like supporting the qcow2 volumes format (and other virtual disk formats, such as vmdk) using libguestfs, we encounter two issues. First, libguestfs is not available on all operating systems. As mentioned before, muCommander already includes OS-specific things but in this case it would mean having unused dependencies on many operating systems. Second, it requires not only the java dependency (java bindings for libguestfs) but also library code to be installed on the OS (libguestfs). We currently have no way to specify such dependencies.

Mucommander Java Mac Download Mac

Next, I will share some thoughts on how to address the aforementioned challenges.

Redefine the “mission statement”

The development of muCommander started more than 15 years ago. That is a pretty long time in software terms and so some of the assumptions we began with may not be relevant anymore. For example, the minimal USB stick today contains at least 1G and internet connection is much faster. So considering that muCommander is unlikely to run on devices with limited resources (such as mobile phones), it would probably be alright to produce a larger-size application. As another example, today much more data is stored on cloud services such as dropbox and google drive. Supporting such services may be more important for end-users than things like an advanced integrated text editor nowadays.

So I think this may be the right time to reconsider what is the goal of muCommander - what are its strengths, what should it provide, why should users continue using it and why should developers continue contributing to it.

Pluggable design

Mucommander Java Mac Download Windows 10

In my opinion, the most important technical change at the moment is introducing a pluggable framework. First, it can target only extensions for new file formats and file protocols. Later, it can be extended with other types of extensions.

Such a pluggable framework would enable us to:

• Separate out heavy file format or protocol implementations from the codebase.
• Install OS-specific extensions only when they are needed.
• Define external dependencies per-extension.

The implementation of a pluggable machnism for muCommander was already discussed in the past. A natural infrastructure to use for this would be OSGI.

Mucommander Java Mac Download Version

Promoting the project

With an up-to-date “mission statement” and a pluggable framework available, we should then promote the project. There are several ways to do this, like:

• Presenting in a conference, such as FOSDEM or DevConf.cz.
• Writing an article to a known website, such as opensource.com.
• Defining a list of some desired features (such as PDF viewer, integrating dagger 2, etc) and submitting the project to GSoC (Google Summer of Code).

Reassess Gitter for user discussions

When things are back on track, we can reassess Gitter as a tool for communicating with end-users. It may be a good idea to schedule a bi-weekly (or a monthly) conference meeting to discuss topics related to the project.