Re: A proposal for Midnight Commander

[Ali Akcaagac <aliakc web de>]

On Fri, 2003-11-14 at 15:30, Koblinger Egmont wrote:
> If you care about dependencies so much, then please let me
> share my experiences. I'm not really familiar in glib{,2}
> programming, I rather use plain glibc calls. In the mean time,
> working on a linux distribution we thought about putting some
> nice tools in the initrd that performs the installation. We
> have strace and other nice debug tools there. MC would be
> nice, too. But we didn't put mc there, and the reason was not
> glib. (Actually, glib2 is already there since our installer
> uses gtk2, but we'd simply put there glib2 if it wasn't there,
> no problem.)
> 
> I think glib2 is now a quite stanadrd piece of software, with
> plenty of useful functions. Even if it changes faster than glibc,
> I'm sure that there's always a big timeframe when obsoleted
> functions are still available, and I'm quite sure that porting mc
> to a newer glib2 requires less work than reimplementing all these
> nice features of glib2 in pure glibc.

Well I think I need to reply a bit more precise here.

I'm programming GNOME applications myself for quite some time now. This
includes fixing bugs, co-authoring of some stuff and my own projects.

http://www.akcaagac.com/index_atlantis.html

I for my own have no problems with 'glib'. glib is indeed a nice addon
with a lot of powerful functions usually not found in 'glibc' and it
guarantees that it works on all plattforms. So far for this.

I also share the opinion that re-using code is a wonderful thing. But it
only makes sense in large projects such as re-using a framework of
standard libraries under GNOME for example. Standard libraries are
librsvg, libbonobo, libbonoboui, libgnome, libgnomeui, gnome-vfs and so
on. This makes a lot of sense and is the right way to go. You can count
on my vote for this whenever someone shows up infront of me and asks
whether this is a good thing or not. Depending of making glib a standard
library is also something that needs to be viewed by the individual.
There are people who belive it to be standard, others think of it as a
graphical helper library for GTK+ and GNOME. Last one is valid for me.

I only belive that this is not a good thing for midnight commander. it's
by far the only console application that I've met in all the years (that
I personally use) which has this requirement.

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

http://www.akcaagac.com/tools/files/shell/cdimage.sh

> 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.
> 
> 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.

Yes I fully understand this problem, that could then be seen as step 2
of the process to move midnight commander forward. I am already peeking
to the MP fork of 4.1.35 -> which now became 4.1.40.

http://mc.linuxinside.com

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

greetings.