iinegve / mucommander Goto Github PK

Generally speaking it's not required, but I believe we might benefit from having it developed on top of service's sdk instead of custom built. Although jets3t is a proven solution, aws-sdk is released much often, contains less issues and might have a logic that reduce amount of requests to the service (thus reduce amount of charged money).

Vital stuff. Cannot imagine it's possible to have file manager without search.
Might include search

• by file names / partial names (regexp?),
• by file contents (regexp?)

Suggest to use Lucene.
Caching for some times must be implemented in order to eliminate second / third / etc searches during 5 mins.

Total Commander (Windows) would be perfect example.

For example:

AsyncPanel idea is to show clocks while something useful happening in background (in practice that is file loading only).
SwingWorker is native mechanism to do the same. AsyncPanel by its nature implement such a mechanism, but in custom code. I'd like to eliminate such custom solution.

Hi, it saw, what at github host original mucommander with new arc, with gradle and other improvements.
https://github.com/mucommander
It would be greate if you merge yours features to it. Killer feature is background copy.

It will provide the error "Source and destination folders are the same", i think we should auto rename the copied file with "Test.txt" -> "Test1.txt"

In some cases, for example, when we are trying to search at the root an application throws OutOfMemoryError. The main reason for this is bypassing archives. So we need to investigate it.

Now we use naive approach of indexation, so it leads to a large data redundancy up to 500 mb per file system.
We need to denormalize index data.

It can be customized, but it'll be useful to have default some sort of standard hotkey.

This feature makes possible to perform operations like a delete by mask.

When we try to save a remote file there is a possibility that the file has already been modified by another user.

Run FindBug and fix known issues.

Currently directory can be selected (by space, for example), but the only way to get its size is to push special button combination. I'd like to have background process, which will calculate dir size by its selection.

It is redundant to bypass archive file if it has been processed before.
We can just check the modification time.

Another improvement for background copying would be to implement ability to put different background copying threads to stack. That would reduce disk pressure and improve overall performance (might be even let the drive live long happy live).

It can be done by building separate dialog window and put there list of files currently being in copying / moving / deleting. Switch from standard dialog to new one could be don by F2 key.

New dialog must have ability to be suspended.

By default such a dialog uses directory from other panel.
I believe it will be useful to unpack into the same directory where packed file is now.

Here it is: https://svn.mucommander.com/mucommander/trunk/
It'd be cool to have mature packaging mech as it's done in target "release" in build.xml

It's vital to have the feature.
Currently every dialog window in sources extend FocusDialog. If simply turn this FocusDialog into non-modal, then all question-dialogs like "Overwrite" or "Really really delete" stop working. Looks like it requires to extend some dialogs from NonFocusDialog (which doesn't exist, yet)

By opening stream and reading data by small chunks.

Those tests file module contains plugins that works with different protocols like FTP, SFTP, HDFS, S3 and others. In order to test them we might need installed working ftp, sftp and others stuff.
The best way do that is having a centralized common solution.

Off topic: Do you know, if github has additional service to create virtual machine? If not, we might need to get one somehow.

Free Space Item in the bottom line which shows free space of the drive of the active panel doesn't follow when you switch to the other panel which is a different drive. Sometimes it catches up most times it does not.

muCommander 0.9.3 on Linux with Java 1.8

Step to reproduce:

• open text file with the integrated text editor which is located under a jar file which is included in a ear file itself.
• save the file

Expected result:

• file is updated

Actual result:

• an error dialog appear which says "Unable to write file"

muCommander uses classes from package com.apple.eawt. directly. See the following classes:

com.mucommander.ui.macosx.EAWTHandler
com.mucommander.ui.main.MainFrame

I propose to use reflection:

public static void setWindowCanFullScreen(Window window) {
    try {
        Class util = Class.forName("com.apple.eawt.FullScreenUtilities");
        Class params[] = new Class[]{Window.class, Boolean.TYPE};
        Method method = util.getMethod("setWindowCanFullScreen", params);
        method.invoke(null, window, true);
    } catch (ClassNotFoundException e1) {
    } catch (Exception e) {
    }
}

The purpose of using reflection is to avoid any compile time dependencies on Apple Java Extensions.

It is really irritating. It must have size that has been stored in previous session with it.
I mean that anytime user open internal viewer and changes its size, such a new size must be stored into properties. And be applied next time internal viewer is opened.

Optionally (and possibly subject for another issue) size of internal viewer can be stored for each file separately (or for different types of file: like full screen for *.java, windowed for *.txt)

We can use http://www.jedit.org/api/org/gjt/sp/jedit/textarea/JEditEmbeddedTextArea.html as embedded editor.
Some of jEdit's features include:

• Written in Java, so it runs on Mac OS X, OS/2, Unix, VMS and Windows.
• Built-in macro language; extensible plugin architecture. Hundreds of macros and plugins available.
• Plugins can be downloaded and installed from within jEdit using the "plugin manager" feature.
• Auto indent, and syntax highlighting for more than 200 languages.
• Supports a large number of character encodings including UTF8 and Unicode.
• Folding for selectively hiding regions of text.
• Word wrap.
• Highly configurable and customizable.
• Every other feature, both basic and advanced, you would expect to find in a text editor. See the Features page for a full list.