![]() ![]() But on the other hand, that may also be a consequence of the relatively low traffic in general in the project these days. 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. Seems like both the GitHub issues/PRs and Gitter provide good alternatives for communicating with developers. We used to communicate with the developer and user communities by Google group, Forum, and IRC channel. 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. That causes PRs and issues to occasionally wait relatively long time for getting attention. However, we currently have a fairly large codebase that becomes hard to maintain by a single maintainer. Scaling the development modelįrom time to time we get some really nice contributions as well as issues that users report. Next, I describe the four major challenges I see at the moment that hinder the progress of the project. Manage translations in the Zanata platform.Enable compiling the code with Java 9 and Java 10.Nevertheless, some important changes were done. Honestly, the project pulse has not been that great recently. ![]() For developers it is significant as it conforms the principle of write once, run anywhere.Īnother benefit of being implemented in Java is that muCommander can leverage the large variety of third-party client-side libraries for different file protocols. Except for some OS-specific features that use native code (e.g., moving files to the trash), everything is implemented in the Java language. By having its core and most of its functionality written in Java, muCommander becomes cross-platform. These great capabilities are provided on all mainstream operating systems (OS). 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. 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 way, reading from a remote file protocol and writing to another remote file protocol can be made very efficient. Moreover, it eliminates the need to set up protocol-specific clients, such as an FTP-client.Īnd not only that muCommander supports many file protocols but it also abstracts reads and writes with Java input/output streams. ![]() 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. Why?įirst and foremost, muCommander supports various file formats (e.g., ZIP) and protocols (e.g., SMB). 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. It runs on any operating system with Java support (Mac OS X, Windows, Linux, *BSD, Solaris…). ![]() MuCommander is a lightweight, cross-platform file manager with a dual-pane interface. This post provides a short description of the project, recent changes we have made, challenges we are facing, and some future plans. Ten years ago (2008) I submitted my first contribution to an open source project named muCommander that I maintain to this day. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |