Re: midnight commander reloaded (?)

[Pavel Roskin <proski gnu org>]

Hello!

Just a few comments.

On Tue, 2006-05-02 at 19:48 +0200, Jozef Riha wrote:
> Dear mc devs,
> 
> please let me thank you for your work at the first place. Midnight
> commander is still my number one file-manager (Linux). Except the
> utility I welcome there are however things I see in other
> file-managers (total commander) which I would be happy to see ported.
> Specifically:
> * user defined key bindings
> * better bookmarks system w/ hotkeys
> * more options for searching (Esc ?)

Potential killer feature - exclude versioning data (CVS, RCS,
SCCS, .git, .svn directories and *,v files) with one checkbox.  Although
I should probably just find a night for it and add it to mc.

> * tabs (like in firefox/opera/you name it)

I think backgrounding the viewer and the editor would be fine.  I don't
think backgrounding extra panels would be helpful.

> * plugin support
> * better archive support (zip archive inside zip archive inside rar

This is working for me already.  On the other hand, associations don't
work well on the archive files (think pdf in zip).

> and sidenote: look how tc  opens/reads huge zip files)
> * ability to send copy/move process to background and back, manager of
> background processes

Yes, that's another useful thing to background.

Another high-priority requirement - proper Unicode support.  And better
keyboard support in Linux console.

> -- Lower priority ones --
> * drag&drop support
> * option to use a GUI (--enable-gui like option)

That has the potential to make the new commander another mc.  Unless
both the text and the GUI frontends use the same library for drawing,
and the differences are transparent to the bulk of the code.

> * clock (remember volkov commander?)
> * multiplatormness (a win32 port)

Same comment applies.  If it's not transparent to most of the code, it
will damage the project very badly.

> As from what I have read about the history of mc, the current
> development is somewhat cumberome. Namely since version 4.x.x the
> patches are becoming less transparent and it is still harder for a new
> feature to make it into the sources.

To be fair, many features that were added in the "good old times"
required significant clean-ups afterward.  So it's not like that it
suddenly became harder to add features because the of the code changes.
The requirements were changed to allow only complete patches that would
not require subsequent cleanups.

>  I do not know if or how much is
> this true,  if the real problem is the active developer number or
> something else, but I somehow feel that in order to make mc going
> somewhere the sources must be rewritten from scratch.

I agree.  Lots of time was spent on figuring out why some code was
written in a certain way.  The sources are full of irrelevant
workarounds for libraries that are no longer used.

> Midnight commander is still the only widely accepted filemanager for
> console but I see it becoming too old these days. And I am not the
> only one seeing this. Therefore I was thinking of the following:
> collect a decent sum of money from the linux users who share the same
> ideas as
>  me, make a competition of tenders based on the demo of the new
> manager, set detailed specifications (GPL license mandatory) on
> software after those are met the money will be paid. Simil
> ar to SoC except for that anyone (including companies) will be able to
> take part on it.

I'm afraid the best code is written by those who are going to maintain
it in the long term, not by those who want just to meet certain
requirements before the deadline.

In the case of "summer of code", the ideas were suggested by maintainers
of actively developed projects.  The criteria for success was
integrating the changes to the codebase.

And what would happen to the mc-reloaded once the "summer of code" is
over?  Who is going to maintain it?

> What I would like to know is your opinion on the whole matter as I
> admit I may be all wrong here.

I agree that mc should be rewritten, but I don't think your approach is
workable.  You can end up with something that does what the specs say
and nothing else, and the code may be even harder to improve.

-- 
Regards,
Pavel Roskin