Re: A proposal for Midnight Commander

>>>>> "Ali" == Ali Akcaagac <aliakc web de> writes:

Your site is giving a connection refused error.
Ali> I also share the opinion that re-using code is a wonderful
Ali> thing. But it only makes sense in large projects such as re-using
Ali> a framework of standard libraries under GNOME for
Ali> example. Standard libraries are librsvg, libbonobo, libbonoboui,
Ali> libgnome, libgnomeui, gnome-vfs and so on. This makes a lot of
Ali> sense and is the right way to go. You can count on my vote for
Ali> this whenever someone shows up infront of me and asks whether
Ali> this is a good thing or not. Depending of making glib a standard
Ali> library is also something that needs to be viewed by the
Ali> individual.  There are people who belive it to be standard,
Ali> others think of it as a graphical helper library for GTK+ and
Ali> GNOME. Last one is valid for me.
Ali> I only belive that this is not a good thing for midnight
Ali> commander. it's by far the only console application that I've met
Ali> in all the years (that I personally use) which has this
Ali> requirement.

I agree with you.  I won't even bother to download and try it out an
mc that has libbonobo in it.  Or anything else, for that matter -- I'm
slowly extracting myself out of gnucase and a couple of other tools
that use it.  As the guy in in Pulp Fiction said, "sewer rat may taste
like pumpkin pie, but I'll never know, because I won't eat the filthy"

I've already had too large a portion of my life wasted by the gnome
people.  Maybe in fifteen years when a generation of programmers have
passed through, and I can be reasonably sure none of the original
people are still writing parts of it, I'll look at it.

It's important to consider that kind of mindshare that a project can
lose by releasing successive worse and worse releases.  Especially
when there is a hype associated with it that is so clearly at odds
with what you see on your screen.

Ali> I'm also into making rescue systems. I must admit that I recently
Ali> started with it but it was something I always wanted to do and
Ali> understand correctly. But I don't belive that such stuff should
Ali> depend in the initrd image rather than one step later in the root
Ali> image after you pivot_root'ed into it - But I'm not to judge here
Ali> how people are doing their stuff. For the interested ones, you
Ali> can get a dead simply rescue/boot/backup bash script from my
Ali> webpage which generates such a cd for you, e.g. creating an
Ali> initrd, copying busybox onto it, then creating a syslinux disk
Ali> out of it and then later on creates a root image with some files
Ali> on it.

I made a single floppy linux that has mc on it:

It was more pain that it needed to be.  At one point I dug up out of
the Slackware archives the slackware package from mc 3.5, and
attempted to use that, and it lacked some feature which I have
forgotten.  Then I went back to a more recent version and commented
out whole swaths of troublesome code.  It seemed that I could pick any
source file and randomly delete stuff and mc would get better.  At
around that time the 4.6 version was released, which was a large
improvement, and the only thing I needed to delete was some stuff in

I like the current mc, and I think it is going in the right direction
in general.

>> If you think in dependencies: there's an uglier dependency of mc,
>> namely slang. My experiences show that mc compiled without slang
>> (only ncurses) has lot ot problems. IIRC even the developers say
>> that compiling against only ncurses is not recommended.

I compiled mine with ncurses.

>> Ncurses ships a big terminfo database, but it's possible to compile
>> some terminfo entries hardwired into ncurses. We have the most
>> common terminals (linux, xterm, vt100 and screen) compiled into
>> ncurses, this makes its size bigger about 2kB or so, which is
>> nothing. And then ncurses applications perfectly work on these
>> kinds of terminals without any terminfo database. Slang, however,
>> isn't able to hardcode some terminal entries. So for a slang-mc to
>> work properly, you must have the terminfo entries installed.

I did not know about compiling the terminfo's into ncurses.  I put a
single terminfo entry (linux) on my floppy.

Ali> I am already peeking to the MP fork of 4.1.35 -> which now became
Ali> 4.1.40.
Ali> It's based on a pre glib/gnome version of midnight commander,
Ali> which was heavily bugfixed and some nice little features got
Ali> added even backported from 4.6.0. The entire size is less than
Ali> half of what midnight commander became now. I only had some
Ali> problems with the colors when started up but got told a
Ali> workaround for this with the -Y classic color option that I
Ali> haven't paid attention for. I do share some of the sights from
Ali> olegarch here and I'm already in contact with him, whether we can
Ali> create a mailinglist and continue working on that one. I have
Ali> raised my opinion on the current situation of midnight commander
Ali> from a users perspective and I'm not forcing my opinion on
Ali> others. There are quite a lot of nice stuff in 4.6.0 no doubt but
Ali> some things have also changed for the bad. I primarily want is a
Ali> console filemanager that I can use to delete some junk, move some
Ali> dirs and rename some stuff - which not depends on glib.

It looks interesting.  In the cursory inspection I just gave it, I was
only able to compile it in the --with-included-slang configuration.
Compiling with -Os and stripping, with options as close to what I used
in mc 4.6 as possible, I get an executable of 4.51 MB, while my mc 4.6
executable is 3.98 MB.   I fiddled with the config options and
recompiled it three times.  Basically, it reminds me of mc 4.1 which
would not allow me to turn off enough options to fit it on a floppy
system.  However, I think it is good that multiple groups are
maintaining different versions of mc.

However, it is important to note that mc 4.6 is smaller, or can be
configured to be smaller, than it's predecessor.  The difference in
size is larger than the additional 171k of glib.

That's why I think mc is on the right path.  I agree with Pavel's view
on the various issues.  I would tend towards avoiding glib myself if I
were coding, but then I haven't contributed any code lately, and glib
is small enough that it has not stopped me from doing anything I want
to do with mc.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]