WIP: attempt to modernize muCommander

[TheIndifferent]

Hi there!

NOTE: I do not expect this PR to be merged, it is more of a discussion starter and a bit of a work log 😃

muCommander seems to be bundled with all the fantastic functionality, but one of the reason why it is not really competitive for me personally is because of how it looks and behaves.

I recently had to switch from macOS to Windows, and muCommander seems to be a no-brainer choice of file manager 😃 especially considering that I am perfectly able to change/contribute myself.

First thing I noticed is that Windows LookAndFeel does not really follow switching to dark theme that is now available in Windows 10. So this is my first experiment, add a wide selection of LookAndFeels to the application. I've seen that it is possible to download some and import them via special dialog, still that is something I would expect to see in 2004, I believe that modern application should have it available out of the box.

Code below is not nearly as well documented as main muCommander code at the moment, but it is also not really stable yet.

OSGI loading failures were a bit hard to figure out, but I found a way to make it work.

I failed to extract current version of Darcula from IntelliJ, but FlatLaf provides wide selection of LookAndFeels, so at the moment that is the only one bundled with application.

I've added separate OSGI module to provide factories for more configuration panels, and added catalogue of those to existing preferences panel. I feel like this is something that would be more convenient to do with ServiceLoader instead of OSGI, as it would allow discovery on demand, not only on startup.

I've created a small components demo with NetBeans GUI builder, and used it to render a bunch of PNG files to preview all the LookAndFeels available on my machine including FlatLaf.

I am pretty pleased with that part, next challenge is that current preference system is not extensible enough. mucommander-preferences module had enum of all possible settings, which means that modules have to be hardcoded in it, creating tight coupling? And mucommander-commons-conf seems to be quite low-level, without good high level abstractions that would be easy and convenient to inject into other OSGI modules.

So while window to select LookAndFeel is now pretty and working well, settings themselves are not saved.

My plan now is the following:

• Create injectable preferences reader/writer. So far I am thinking that it would be possible to do as abstraction either over Jackson or over protobuf, the problem there is to have schema-evolution built-in, so ALL settings have to be optional and must have sane defaults. Those preferences readers/writers will be provided to each module.
• Create modern preferences dialog. I am thinking something with tiles, where title and description are shown. It will be able to list all the loaded module preference dialogs. The only problem here is that it means that modules probably have to be responsible for applying their own settings as well, which will of course follow the way it works on macOS (no OK or Cancel buttons), but then I really like the existence of Cancel button 🤔
• I really miss better keyboard navigation in muCommander currently. Copy, Move and Delete dialogs should have some quick keyboard shortcuts, maybe with numbers, to tick any of the boxes without a mouse or cycling through with TAB.
• I would will try to make all the dialogs in background, similarly to how IntelliJ shows indexing dialogs.
• I would also try to bundle few more themes maybe, and maybe some font settings as well.
• I foresee issues with providing/configuring keyboard shortcuts configs to modules, as keyboard shortcuts should have centralized configuration window, but then might actually invoke actions provided by modules 🤔 that is something that will have to be addressed at some point in future.

[ahadas]

Hi @TheIndifferent ,
I didn't have time to look thoroughly at the code yet so here's just a quick feedback on the description of the PR.

First, it's great to see this! the presentation side got less attention recently but this, maybe together with updating the icons we use (#386), can really modernize that aspect.

About preferences, yes mucommander-preferences was created before switching to OSGi and was not adjusted to support module-level configuration. I'm not sure if the right way is to inject things from it to the modules or vice versa - that modules would register readers/writers to it. I agree that it's time to update mucommander-commons-conf as well - I thought about trying to replace it with apache commons conf long ago but didn't get to it and there may be better alternatives nowadays. When I looked at protobuf it seemed more complex as it was intended for optimized communication - we don't have to make the configuration really compact, ease of use would be more important in my opinion.

Changing the preferences dialog, sure, that's a good idea.

I'm not sure I have a good picture of what it means (or how it would work) to making the dialogs in the background and navigation not using TAB. I'd love to discuss it in more details or look at a reference that can clarify those.

Configurable keyboard shortcuts by modules - yeah, that's a challenge. But it's good to have it in mind as we provide default keyboard shortcuts per operating system. That's something I expect to tackle soon.

That's it for now, I'll provide additional feedback after spending some more time on reviewing the code :)
Thanks!