Re: A proposal for Midnight Commander

[Arpi <arpi mplayerhq hu>]

Hi,

> Koblinger Egmont wrote:
> > Gabucino votes for glib1
> No, I vote to no glib at all! A two panel filemanager doesn't need all these
> sophisticated stuff! Check Volkov Commander, it's a 64kb DOS COM executable
> (and imho it's much faster/stabler/better than mc, pity it's on DOS).
> 
> But this argument is getting very very pointless, it seems Pavel apparently
> listens to noone, likes reinventing the wheel, dropping simple support for
> many OS'es, and his dictatoric means of maintaining resulted in the
> appearing of many mc forks...

Ok, I think it's time to comment on this thread.
I've just ran through this thread, read the most, but not all mails, sorry
it's way too much offtopic and flame and PR text.

As I already told in private to Ali, my opinion on these:

glib issue: i don't care of glib, at all. first when i noticed it in 4.6, i
didnt liked it, but i can understand and accept that it simplifies mc code,
and moves some bugfixing and maintaince and porting work to the glib team.
i will like if glib is removed, but i don't mind if it remains there.
anyway i'm against including glib as-is in mc source,it's total nonsence.
i'm not against code sharing, it's a good thing, if it's well done.
(and no, i won't work on glib removal of 4.6, i simply has no time for
something i don't care.)

forks: since i'm "owning" 2 of them (4.1.35-Axx series and amc-4.6 cvs),
i can't simply say here that i don't like them :)
but the reason of forking wa snot glib at all. it was gnome (!=glib) in case
of 4.1.35-Axx, and other buggy broken bloat in 4.5.xx series. when i did
that fork, there was no 4.6 (at least i wasn't aware of it), and the 4.5.x
series was so broken to be totaly unusable, and does not worth to fix it.
i've worked a lot on the -Axx fork, to fix known bugs, add most-wanted
features and fix VFS/extfs drivers, especially the oh-so-broken FTPfs.
then i stopped that work, due to MPlayer project and other works.

the next fork, amc-4.6 was done after 4.6.0 release, due to my patch sets
for 4.6.0 being rejected by maintainer with no (or not acceptable) reasons.
but i want to note, that i have nothing bad with current 4.6.x
maintainer(s), i see and can accept that he tries to keep the baseline mc
code as clean as possible, and fix all issues and remove obsolete code
before starting (re-)adding funcy features.
i should have done the same with mplayer years ago, keep it clean, and
refuse all feature patches until the code is cleaned up and bugfree.
(so i could avoid restarting from scratch nowdays, with mplayer-g2...)
but it isn't so simple, there is a big demand from users for new features,
so we must either accept these patches for the mainstream code, or make a
fork which focuses on features instead of cleaness and bugfixes. such fork
can be the testbed for such patches, before they gets accepted for the
mainstream code. this is teh reason, why i made amc-4.6, to accept and
test verious patches being refused from mainstream code.
unfortunatelly i was too busy to work on this fork, or even maintain it,
so it died as fast as it born.

i was recently told about a new fork, the mc-mp (aka 4.1.40-preXX).
it is said to be based on my 4.1.35-A12 code, but i miss many of the
featuers and fixes i made in -A12 from it, so maybe it isn't true.
(anyway it should be true, as some of my code is there in mc-mp, even
if it doesnt work due to other changes...)
also, it has a strong DN (dos navigator, some of you maybe remember that old
thing, ran by people on dos who didnt like (the imho much better, and less
bloated) volkov commander) feeling, especially in colors and some fancy
features (like clock in the corner etc). even with -Y option it still has
unusual look-and-feel compared to mc or vc or nc.
besides of that, it's a nice try, i like it. it is based on 4.1.x series,
but has the good parts of 4.6 backported, like the builtin df and find-file
code, and the editor. the vfs code is based on teh old API, which works
better (imho) for non-local filesystems than the 4.6 one.
(remember, i failed to port my ftpfs fixes to 4.6, due to new api lacking
some basic features)
also, the mc-mp maintainer guy said something (i dont know that code, so i
cant decide) about the new dialog boxes code being much worse in 4.6.

btw, could someone list the features and advantages of 4.6.x over the
4.1.x series (release or the forks: 4.1.35-Axx or 4.1.40/mc-mp) ?
i'm interested in both code-level (internals) and user-level (features).
i think it's a very important information for the decision, so we can
see if it does worth to work on mc-mp (and backport interesting things
from 4.6) or it's better to port -Axx and mc-mp features to 4.6-based fork
(be it amc-4.6 or make another). some time ago (2003 spring) i thought
the second is better, but after checking the mc-mp, and talking with his
author i'm unsure now. what i saw in 4.6 was some API changed, heavy usage
of linked lists, internal types and other OOP things make it less readable.
it wouldnt be a problem alone, if i see same amount (or more) advantages of
4.6, to balance it. but it seems the interesting features of 4.6 (over 4.1)
were easy to backport to 4.1, so why bother with 4.6 any more??


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu