Re: A proposal for Midnight Commander

[Pavel Roskin <proski gnu org>]

On Thu, 13 Nov 2003, Ali Akcaagac wrote:

> I know this may be a delicate point to discuss but I would like to
> propose that MC becomes independent to glib again.

In fact, the more I work on mc the more I think that we should be using
high level constructs rather than plain C.  Fixed buffers are a problem
for security and correctness, so we should use dynamic memory allocation.
If we allocate data, we should deallocate it.  Many functions return in
more than one place.  C lacks anything like "finalize" or garbage
collection, so we have growing code in the branches that are executed very
rarely, so that code doesn't get tested.

glib offers some relief.  In particular, g_free() includes a test if the
pointer is NULL - very useful to avoid extra code.  g_malloc() aborts the
program if the memory cannot be allocated.  Again, it eliminates a lot of
code.  It also makes sure that mc fails early and in a predictable way if
the memory is indeed very low.

Lists are also useful, once you know how to use them.  Unfortunately, they
make it easy to do something wrong.  For example, it's easy to write

g_slist_delete_link (vfs_openfiles, l);

instead of

vfs_openfiles = g_slist_delete_link (vfs_openfiles, l);

Both would work, but the former would break when the first element is
removed.  That's an error that doesn't happen often, so chances are that
is will be overlooked in simple tests.

Still, the lists are convenient to avoid code duplication and some common
errors.  But it you have a better alternative, I'll switch gladly.  I'm
seriously considering C++ with its standard libraries, but it's too
intrusive and may not happen soon.

> Reasons for this:
>
> Some years ago where Midnight Commander became some sort of Console and
> Desktop Filemanager (for GNOME) it made sense using libraries that came
> with the Desktop in this case it was glib. A lot of wrappers for simple
> types and a bunch of new functions like linked lists, hash tables and
> stuff usually not found inside glibc or other standard c libraries used
> on other platforms.

We actually use a small part of it.  But there is more code that could be
converted.  Lists are used almost everywhere.

> A few weeks/months we saw some people announcing MC forks such as Arpi
> did with his Midnight Commander fork and someone else who continued with
> 4.1.40 (which is glib free).

It's more like years, not months.  All that happened before 4.6.0 release,
as a reaction to the code bloat from the GNOME frontend.

> I have been thinking about this for quite some time and indeed it does
> make sense. Look MC is an all purpose filemanager (if not the best
> around for all sorts of open source architectures). People load it up,
> do their job and quit it again.
>
> But have we ever thought about rescue systems ? such like bootable
> rescue CD's or other situations ?. Let's look at rescue CD's for a
> moment. The aim for such a CD is to keep things tiny (small sized, less
> library dependencies if possible statically linked). Midnight Commander
> in it's current state is maturing and using a lot of libraries these
> days (libglib and libgmodule) for example, this means we need to provide
> these libraries as well.

Or listen to Miguel and link them statically.

> Not to mention what we all need to get MC compiled. Say if we create a
> rescue system and want to use uClibc we then try to depend on as less
> stuff as possible. Currently we need pkg-config installed to compile
> glib and if we build a new system in a chroot then we need to compile
> quite some stuff before being able to use Midnight Commander, specially
> in critical situations when we really urgently need a filemanager.

No, pkg-config is not required if glib 1.2.x is used.  In fact, glib 1.2.x
support is primarily kept to make it easier to compile mc in such minimal
environment.

> Say on my system (only to give a practical example). I have my GTK/GNOME
> installation kept in /usr/local this also means my 'mc' which I checkout
> once a week or something. When I compile GNOME from scratch (this then
> also includes all the other stuff, pkgconfig, startup-notification,
> libxml, libxslt, audiofile etc. before it comes to glib it needs to
> compile a few other things first. During that time I have no mc
> available or can't use it due the fact that my /usr/local dir is moved
> to /usr/local.bak a new /usr/local is being created where all the new
> GNOME stuff is being installed

If you really want to use glib2, there is a script mc_glib2_compile in the
CVS repository.  I'm not sure whether to distribute it in the tarball.
However, this script doesn't try to install glib2, it merely compiles mc
against it.

Actually, it were you who insisted on adding glib2 support, so I'm
surprised that you are complaining now!

> I think there are quite some people here who simply trapped themselves
> into such a situation every now and then and wished that mc would not
> depend on glib for example and only depend on the core libraries such as
> glibc for example. I think we should talk about this for a while and imo
> it does make a lot of sense. If we simply go and accept glib as some
> defacto standard library met on every system then we soon gonna accept
> every library to be standard and make mc become more complicated (maybe
> not now but maybe one day).

OK, maybe I'll move mc_glib1_compile and mc_glib2_compile to the root
directory so that users can use it.

I don't share your pessimism about other libraries.  Actually, gmodule
makes it possible to load other libraries dynamically, so they become
optional at the run time.

And what do you suggests to use instead of glib?  In particular what do
you suggest to use for lists and dynamic loading of modules?

> http://mc.linuxinside.com/
> http://www1.mplayerhq.hu/~arpi/amc/
>
> provided two links of recent mc forks.

Neither is recent.

-- 
Regards,
Pavel Roskin