⏱️Overview

This is my modified version (a fork) of Double Commander (DC), a two panel file manager. I first forked it in 2017 and in 2019 I finally moved to using it daily instead of Total Commander. I will describe few aspects here.

ℹ️How to start with DC

Here is a short paragraph upfront, for those who didn’t use a commander or are new to DC and want to start using it (or give it a try). I recommend the main website (for download and support) and the documentation (help) about how to use its functions.

Double Commander

DC is cross platform, so it runs on Windows and GNU/Linux. It is inspired by TC. There are of course many other file managers, (some even in text mode like MC), but I think DC is perfect for me and I highly recommend it.

The best features of DC though (for me), are being Open Source (FOSS, this gives Freedom) and still developed. What it means (especially for me) is that I can learn how it works and can change it myself. Or even add new features, including those that only I will use. And I can contribute to the project.

📜My History

I started using a file manager as a kid, already on my first PC which had DOS. It was Norton Commander (NC, in text mode). I quickly got to using it daily, as my main program to do all file and directory operations. I didn’t even know how to do them using DOS commands for a while. Well I barely started learning English and wasn’t able to read any documentation too (it wasn’t needed BTW).

When I was moving to Windows 98 (around 1999), I naturally wanted a similar program. I didn’t like Windows Explorer at all or even windows in general (I was still sometimes going back to DOS). Fortunately there was a similar program, at the time simply called Windows Commander (WC ?). It was later renamed to Total Commander (TC). Using NC in Windows was possible, but not always, since DOS had short file names and Windows has longer.

WC was better than NC, my favorite feature probably being that it could color file names by extension. I think it’s when I started adding my colors for file extensions I got to work with.

Naturally, when I started using Kubuntu and later Debian, I wanted something like TC.

⏳Before I started

I actually reported a couple of bugs that affected me the most and honestly prevented me from using DC. I was also too inexperienced to even try fixing them myself. Lastly those weren’t easy things to fix.

These were:

• Very slow File Filters. It took 4 seconds of delay to view 24000 files in a directory with my settings having 123 file filters. Directories over 1000 files were already entered with noticeable delay. And yes, my file extensions list grew and became something that I enjoy since years. Surely not something that I would throw away and just not use it.
• Freeze on entering unreachable network paths. It happened often at work (where I had to use DC not TC) and also for more people. Application froze for nearly a minute. So quite an inconvenience to kill the process every time someone accidentally tries an unreachable path or a tab with it.
• Compare by Contents not Implemented from Search result and archives. A simpler bug for a useful feature.

After a few months the first issue was fixed. So I started making my own program to deal with my file extensions list for both DC and TC. I had a lot of them 96 in 2017 and 239 in 2019, this is just the count of unique colors (file filters), though I split some for readability (e.g. for Stunt Rally track sceneries).

The program has its own page and is called Crystal Color Center. I’m sharing it with my list included. It allows an managing the list on an even higher level, with features like: groups, search, quicker editing (with R,G,B sliders) and of course import / export for both DC and TC. Thanks to it, moving my list from TC to DC was easy and any changes to it is fast and conveniently done in my program.

The second bug was fixed after a year (still, I can’t complain since I didn’t do it earlier). But earlier it became not that needed anymore for me.

After that it was probably the time, when I realized I should fix the rest of my issues with DC. I mean just missing things from TC that I got so used to. It also turned to a nice learning experience and woken up old memories from Pascal.

✍️How I started

Well the start is the hardest part of any software (program or game) or even any project in general. To start, the page Building from source is crucial. And I believe it’s probably the most important page for any FOSS project. Of course beside a good documentation for users. Fortunately the instruction is not long or difficult.

Sources are surely different, because DC is written in FreePascal. Lucky for me, I knew Pascal since DOS and later Delphi in Windows. So I had some start and the rest is nicely explained on internet and in language documentation and wiki. But basically I prefer to just search on internet for particular problem. It doesn’t matter where I land (doc, wiki, forum, stackoverflow, etc.) to read the solution or hints.

At first I was building just from command line. After installing packages for Lazarus IDE (a bit more trouble) I could develop in it. Naturally I created my own color theme for Lazarus IDE as a result. And I also saw that weird build “Internal error 200611031″ plenty of times (well count – 1 too many).

FreePascal

The DC code is quite big and it surely requires time to get a hang of it. Learning FreePascal adds even more time. But it is a very nice (almost funny) language which also reminded me of my earliest years of programming (at college I moved to C++ and later also C#).

Pascal language doesn’t use so many symbols, making other languages look more like a forest. Pascal code looks more like a book. Not a phone book, a novel. An English book where people write what should happen. Assuming that comments are written in English too, which I recommend always.

Well let’s have an example, I have cut and pasted few very readable lines here:

uses
  Forms, Controls, Dialogs, Buttons, Menus, Classes;

procedure LoadSettings;
function GetOptionsForm: TfrmOptions;
function GetAName: String; virtual; abstract;
destructor Destroy; override;

const
  allowed : set of char = [ '-', '.', '_', '~' ];

var
  I: Char;
begin
  for I := #0 to #255 do
  begin
    case I of
      '_', 'a'..'z', 'A'..'Z', '0'..'9': Identifiers[I] := True;
    else

implementation

if not Assigned(Operation) then Exit;
Operation.Execute;

with Operation as TMultiArchiveCopyInOperation do
  begin
  if cbEncrypt.Checked then
    repeat
      ..
    until sPassword = sPasswordTmp;

finally
  Free;

⚖️Pascal vs C++, quick rants

Well I can’t say I’m finally free yet ?, but surely many things from Pascal are great and make it very nice to read. E.g. that uses statement at start, compared to #include each in own line in C++. Or the with do statement that shortens a whole block below.

C++ is a horribly unreadable at start. And just to mention, some terrible mistakes made by just one symbol, like if (i = 0), instead of ==, that compiles fine. But I did like { } brackets for blocks, instead of begin and end, how many times did I spell them wrong.

I also remember my favorite thing from Turbo Pascal: F9 key to build project, if there is an error it jumps to it in code. Far too many times in Visual Studio I pressed: F1 to show error list, Enter to go to error and Shift-Esc to close that bloody thing. I can’t even ? (and those are my own shortcuts, just Esc won’t work).

It is much better with C# where it compiles in background and underlines bad expressions in code already.

One great thing in Lazarus IDE is that it makes tabs for each search you do. Why on earth can’t VS do it??

I could go on. But the point is, it was really nice (for a change) to code in a completely different language. I think I’d put Pascal after C++ and before C#. Okay then, that’s it from off topic.

---

📊My version

Now we finally arrive at the main and most interesting part (at least for me).

After I was able to use Lazarus IDE and felt good with Pascal (again), I wrote new features and customized DC to my liking. I also made source patches for some features on DC BugTracker.

📂Sources

Full list of my changes (in commits) can be browsed here (or locally after cloning with Git).

Here is what I changed and why:

• Undo Close Tab
  I simply can’t imagine having dynamic tabs anywhere without this. We’ll see if it gets into final DC release, and when.
• Multi Rename tool
  More compact look and new functions listed here. Probably the biggest update.
  I use this tool a lot at home, e.g. dealing with thousands of screenshots, deleting later half or one third of them, re-enumerating them with this tool and doing it again.
• Status bar
  New look, visible on screenshot above.
  I really like to have a different status bar (text and color) for when anything is selected.
  I once had selected files, not visible at cursor, forgot them, wanted to delete a file at cursor and deleted them all.
• Size colors
  Next, why shouldn’t I have different colors for different sizes (K, M, G etc)?
  Sure for some it’d be too much color. But I’m using the same idea in my audio player (cAmp), coloring track times and I find it informative.
• Gradient for cursor (blue) and selection (orange).
  Also visible on screenshot above. I think it’s nice, more futuristic.
• Follow links to destination.
  With Ctrl – (Left,Right or Up), quite a useful thing.
  I have few dirs with just such links (.lnk files) and use them as my starting point e.g. when developing one of my projects.
  And BTW a quick feature to use Ctrl-Shift-S on cursor to make a link to it, without asking.
• Find Files results, Color by file types.
  Another useful extension. Seems natural for me, to have any list of files use coloring by file type (extensions) especially when I have so many in my list.
• Some smaller things.
  Not very important, but definitely nice to have and a cool exercise to find it in code.

Another thing of mine is file and directory rating. I use it constantly since years too. This is visible on screenshot above as symbols ` ^ ~ + after name. It makes it easy to spot more interesting files/dirs and makes them change color (usually intensity). It is also an internal feature of my player to apply the symbols to filenames.

⚙️Contributing (in general)

There are a few different change types to software, that anyone can report, contribute, or have on own fork.

• Bug or issue reports.
  This is relatively easy to do as user. And is surely a good thing to receive as a developer. With more features in project and more systems where it can run, it is difficult to catch bugs. I didn’t like those reports as a Stunt Rally developer, but without them it would be a more buggy game.
  But still, there is probably nothing worse than a post “help, it doesn’t work”, without any (not to mention all) data required like version, OS, steps, etc. In that case it’s better not to post.
  There is a general guide for “how to report a bug” and some project have specific ones.
• Bug fixes.
  Like those above, but better. They requires programming skills though. It’s when you fix a bug yourself and submit it (to developers).
  In Git that would be a pull request (from your fork, name is surely misleading). It is less trouble to merge and test, also more convenient to discuss (on website Codeberg, GitLab, Github, Bitbucket, etc.). But sometimes a patch is enough.
• Ideas.
  Well that’s just the worst IMO. Everyone has them, just having is not much worth. Discussing them could mean wasted time on development. And developers have usually their own ideas and vision of project. Having more doesn’t help. But, I guess, it could be some help for starting projects, with not set vision yet.
• New features, implemented.
  That is way better than just having ideas. Being able to turn them into reality. One can submit those to developers. But there is a catch. Not all will be attractive to put into project. Having too many features makes a project more difficult to test and more bugs are possible. And could make it more cluttered in GUI or Options (wasn’t an issue in my projects).
• Custom own features.
  This is why I have so many forks. I do have plenty of ideas, I implemented them and I’m pretty sure nobody (from the developers) would care or want to add them (reasons above).
  Additionally, since I have a lot of preferences, it is natural to keep them in my own forks. This way I can keep up to date with upstream (main) project versions and have my stuff too. Priority for me is to keep my stuff.
  But merging upstream versions is needed too (once a while) even if it takes time. If not done, it would at some point accumulate too much, making upstream update too time consuming. Sometimes in that case, it could be possible to apply (merge) own changes (only if not too many) to a fresh upstream version.

⏳Conclusions

My move to DC was surely long and took many steps. But I’m glad to use FOSS, not just as an alternative to commercial, but to prove that it’s simply the only logical way for me. It was obvious already earlier, when I created my own audio player (I use it everyday).

If you’d ask me why I didn’t yet move to GNU/Linux (from that Windows crap) it is because of all those steps needed. DC was one of them. Rewriting my audio player for GNU/Linux is next. There are few other programs I customized and got used to (Video player, Image browser, etc.) but those two (DC and my cAmp) are crucial.

I think I also showed some aspects of FOSS and the great things it brings. In particular, opportunities to: learn, express creativity and adjust to own needs.