Plans for 2024

527 views
Skip to first unread message

OneCommander Support

unread,
Jan 1, 2024, 5:01:07 PM1/1/24
to OneCommander
There are big plans for OneCommander in 2024
  • Several new layouts. More people use laptops than large displays so the next few layouts will be single-pane. The new layouts will be the experimental ground for testing some new interactions and rewriting existing UI elements. During this time the current two dual-pane layouts (Standard and Columns) will keep using old elements to avoid breaking anything
  • File operation manager. The system copy/move dialogs will remain as an option but those have quite few problems that Microsoft will never fix so the new system for this will be added. Some  details of it were already listed few months back but there is still a ton of other things that need to be changed before it is integrated into the main program
  • Search - the new system will be more flexible and should provide instant search on NTFS disks. I have started it several years ago and while it already works as a proof-of-concept, it still needs a lot of work before it can be shipped with the main program
  • Performance improvements (maybe). OC is already faster than Explorer and most other Explorer replacements I tested due to custom rendering and 10 years of optimizations, but I have found additional places for possible improvements. I am not convinced yet that it is necessary because it will require rewriting huge part of the program related to the actual file rendering and most PCs already have smooth experience with OC, but since some new features may slightly affect performance, it is good that there is an additional place where performance can be recovered.
  • New files pane, new file views, new navigation columns, new script execution system and scriptable buttons, new context menus…
Let's just hope Microsoft keeps their "cloud" a priority and leaves Windows alone (in short, I hope they don't break anything)

There will always be next 500 small improvements, and I will keep updating the features that won't interfere with larger planned updates, but if something will have to be rewritten as part of a larger planned feature, it will need to wait (so I don't have to do double work).

Future features and improvements are prioritized by estimated:

  • Percentage of users who will benefit from it (is it niche use-case)?
  • Type of users who would benefit from it? Is it for home users primarily, or businesses, other paying customers?
  • How often is the function required during an hour/day/week/month
  • Is there already an alternative way of accomplishing task? Making action from 2 clicks into 1 is not worth the time to implement unless many need it hundred times per day
  • Discoverability - will people know it exists, or even if they do, will they remember to use it and how to use it, or will they still use the old way? Most people don’t read help documentation so if having it there is the only way to know about a feature, usually it is not worth it as only a few will find it and I could have used the time to make something more useful.
  • Is there a proper way to implement it? If it requires improvisation and will make maintaining the code difficult, it will have to wait until there is a good way to make it.
  • Does it negatively affect program performance? Each additional option affects performance.
  • Does it make program maintenance difficult?  Options require testing and future quadratic overhead, meaning that one added option is double the work for me, but 2 related options are 4x the maintenance work as all 2x2 variations need to be tested and working. 3 options is 2^3=16x work and not 3x work. That's why big software doesn't have hundreds of options.
  • Options for the sake of options - how many people will need it, is the current way already suitable for 90% and the other 10% will just need to adjust their workflow? Most people will never go thorough all the options so even if implemented, only 10% of those 10% will discover it, so maybe it doesn't translate to new licenses.
  • Is the feature that is offered by other utilities? For example, OC can zip and unzip files, but it will never have all the options that standalone 7zip has, nor it should strive to be everything, especially if utility is open source and already accomplishes its purpose well. Same reason is for not having built-in Terminal (one of few thigs MSFT made well), FTP manager (most will still prefer FileZilla), GIT client (most will still prefer Fork, VS or similar), etc. OC shouldn't be an operating system. Also, running something in a separate system process is always better than using program's threads to do something heavy that a separate process can do faster and if it crashes it doesn't take OC with it.
  • 3rd party integrations - depends on if program is open source, is there an open source alternative, do they offer API to integrate or just clumsy way through command line, is the program maintained, is it from this decade or does it look like something from 90s, does it have annoying ads, do I want OC be remotely associated with it, does it do anything weird or otherwise improvises. Having a native implementation will always have priority as integration may already take 30% of time to actually build the feature into the OC
Overall, while I would like to have every feature perfect, it is not possible with the current budget/time, so features that translate to more paying users have priority, and if I really can make the feature significantly better compared to what utility/extension already does already.

Happy New Year!

Neko San

unread,
Jan 3, 2024, 10:24:32 PM1/3/24
to OneCommander
Thank you for sharing these interesting thoughts. Very excited to see what OC will become in the future :-)
Paid updates could be an option for the hard work, from my point of view. Happy New Year to you as well !

Łukasz Samek

unread,
Jan 18, 2024, 7:27:57 AM1/18/24
to OneCommander
Search - the new system will be more flexible and should provide instant search on NTFS disks. I have started it several years ago and while it already works as a proof-of-concept, it still needs a lot of work before it can be shipped with the main program

Would this work in similar fashion to Everything Search?

OneCommander Support

unread,
Jan 18, 2024, 1:29:17 PM1/18/24
to OneCommander
>Would this work in similar fashion to Everything Search

Yes

M R

unread,
Jan 20, 2024, 10:01:55 PM1/20/24
to OneCommander
OneCommander + "Everything" Search = Awesome :)

I'm really looking forward to seeing the Big Plans come to fruition in 2024!

Thanks for all the time and effort you're putting into OC...Much appreciated!

R J

unread,
Jan 22, 2024, 8:38:04 AM1/22/24
to OneCommander
Will search also support "some kind of tagging system"? I would love to be able to find content across different folders with something else than names. I'm currently not aware of a good solution for this kind of search. So I would also like to hear anyones suggestion if my expectation is too high.
Example:
I have a game. It displays images with story. I need to assign it to correct places. Each image has location, character, scene setting. I would love to be able to find image with just those images tagged as LOCATION_POOL + CHAR_TOM 

OneCommander Support

unread,
Jan 22, 2024, 10:12:20 PM1/22/24
to OneCommander
Tagging is supposed to be handled on the filesystem level but Windows just doesn't have that. Everything else is just an improvisation that relies on program databases and program to track all tagged files, but this could have been native for the filesystem. So the options are program database containing fileID, or writing tags in alternate filestream, or in metadata, a sidecar, propertystore... Any of those will result in slow search and losing the tags when the file is moved with different program, or renamed, resaved... The only place it survives is the name or folder structure. I don't know about Mac or Linux, but on Windows everything for that goal with be improvised until Microsoft implements it into the filesystem itself

R J

unread,
Jan 23, 2024, 12:56:17 PM1/23/24
to OneCommander
I understand, also noticed that the color 'tags' dissapear. 
Would there be a problem in performance to handle it in similar matter like you are handling color tags currently? Since I just assume those searches exclude each other.
I personally wouldn't mind if some tags were lost (due to what you said above). 
Especially if there was a way to see only those in child folders. 
At the same time OC is literally replacement for windows explorer. (so I don't need to use normal explorer for the most part).

It just seems that either software is going all in tag organization like eagle or tabbles, which misses out on normal explorer experience that you have.
Or just avoids tags in most way like OC currently.
Some of those other softwares also handle file tracking (to preserve the tags), which is part of a solution, which can probably bring a bit more problems also if proven diffucult.

Either way. It's probably useless for you. I'm just saying all that, because I'm just blind man looking for good solution for this. 
Keep up the good work.

OneCommander Support

unread,
Jan 23, 2024, 3:08:28 PM1/23/24
to OneCommander
Color Tags are currently tracked when OC renames or moves the file. If it is done with some other program, then the database in OC will still point to the file location before it was changed and it becomes useless. Same if drive letter changes. 

Tabbles is doing something weird and I know that it crashes OC file operations. It looks like it tries to inject itself into everyone's file operation at system level in order to track what happened with each file and the operation just crashes ("The data area passed to a system call is too small", E_Undexpected or similar) so Tabbles/Confidential is not supported (in fact if operation crashes with that error, then OC checks if Tabbles is installed and points finger to it as it is certainly the cause). 

The current color tag system is not designed for text tags and it is more for marking just a few files for quicker way to find, but it doesn't cost any performance.

Anything else would cost performance but it wouldn't be terrible if it was something reliable, but risking those of disappearing, while being slow is just not worth it. It is not possible to rely on people reading disclaimers and remembering things like: you may never move your file or rename your file between folders directly from from Unity or Bridge because then your tags will disappear, or use x,y,z program to save because it will remove the alternate file stream. 
I know that Microsoft will never implement that as they are not even capable of making the most basic functionality - every day I am shocked how much Windows itself is cobbled together including even the most essential functions. Nobody from Microsoft uses any complex workflows that we are used to in 3D/Architecture/Animation/game design and similar industries, so they are not even aware what we need, especially after Satya took over and just cares about the cloud. 

sean lee

unread,
Mar 10, 2024, 11:31:50 AM3/10/24
to OneCommander
Improved search will be such an exciting feature! Regarding it, it would be great if the 'quick search' or 'filter' feature (I'm not sure how it is officially refered to) which allows you to do search contents of a directory without opening a separate search dialog gets some sort of fuzzy search algorithm. I think I have written about it in this group once before, but basically I love how `fzf` (https://github.com/junegunn/fzf) provides a easy and seamless experience in navigating directories and selecting files only via command line. fzf is hugely popular for its convenience, and it seems to be a great fit for One Commander's quick search. The algorithm fzf uses is described in https://github.com/junegunn/fzf/blob/master/src/algo/algo.go, hope this can help shaping the future of One Commander!
Reply all
Reply to author
Forward
0 new messages