Re: A proposal for Midnight Commander

[Ali Akcaagac <aliakc web de>]

On Thu, 2003-11-13 at 21:19, Pavel Roskin wrote:
> Actually, it were you who insisted on adding glib2 support,
> so I'm surprised that you are complaining now !

Exactly I was the guy who provided the glib2 stuff to you. Well no, you
are misunderstanding me here I think. I have no negative intentions
about using glib1 or glib2 or something. I use GNOME for quite some
years myself now and glib is kinda part of my system. I was only
proposing to have it removed in general.

> And what do you suggests to use instead of glib ?

I suggest going back to plain standard C library. I like you to do this
test. Compile MC against the latest glib 2.3.x you get from
ftp.gnome.org and add the -DG_DISABLE_DEPRECATED to it and see what
happens.

Glib1 is a no option on my system and on many other people's system
either because the majority for now seem to have switched to GNOME2 or
GTK2 already and do not intend to use glib1 anymore - regardless of the
fact that it co-exists. The idea itself is wrong.

Glib2 as in the new version 2.3.x has some DEPRECATED functions inside
that MC makes usage of which pretty soon may be removed. This requires
someone to work around and use other functioncalls to make it work
again.

Standard C library is the solution here. Well I know this makes
allocating memory and free'ing memory not become easier but it works. It
works in thousands of open source console applications. MC is the only
app so far that uses glib for this. It's a mixture of using glib calls
and glibc calls and soon you hit on DEPRECATED functions anyways.

I can't exactly speak for other architectures such as SUN, AIX, Darwin,
BSD etc. but I somehow do have the feeling that using glib for this is
kinda wrong. Removing GNOME dependency from MC was a major big and very
cool idea from you and I fullheartly supported this decision the time
back when you removed that junk. It would now be a good sign to remove
the last bits of it too. Thus I propose to make it glib free. The first
steps would be to slowly replace the

g_malloc, g_free, g_new0, g_strdup, g_strconcat

Calls with native C ones. Once this has been done half of the entire
work is done. I have been playing with the code for some mins and
replaced (only as a test) the g_malloc calls with native C ones and the
g_free with free (without any function test, only the grep). I wanted to
check how much of the easier things can be done and what remains
afterwards.

It may look a lot at the first moment but it's not that much. Once this
has been done we can look whether some 'really important functions' can
be simply cut and pasted from glib into MC itself and then replaced one
day. Then the general cleanups here and there.

I know some of the users here are not thrilled by the idea, others may
definately be (and the MP fork isn't that old either its started in
April this year and based on MC 4.1.40 which probably was the last
glibfree version existing) e.g. he started with an older version because
he belived it was the better thing to do. This itself was based on
ARPI's fork which he made earlier. I think that these people and I share
similar ideas here and I do belive that a lot of people outside (not
subscirbed here) may belive the same here. A console filemanager should
be usable in even the worst ever scenarios and not depend on so much
libs. Statically compiling - ok is an argument, but requires that glib
exists on the system. Some people would argument that this may be a
stupid thing but on the otherhand it does make sense, we don't want to
stagnate here because we throw our pro's and con's at each of us. If we
go that way then we make no real progress, while I do belive that it
should be clear to everyone that having it not depend on many libs
result in an application that may run in even worst case scenarios. Many
people are trapped with prebuild distributions and installations, how
many of the people using open source these days really know howto deal
with the system. They all live in the best scenario e.g. when my system
crashes I then go and re-install it from debian or red hat, but what
about critical situations, e.g. your harddisk crashed, or some other
thing happened which made your system inaccessible and you urgently need
to rescue some stuff, you boot some rescue CD-Rom, you enter MC and it
throws out libglib-2.0.so libgobject-2.0.so required.. Where to get
these libraries quickly.. in the strange situation you may be trapped in
? You can't access the internet, you can't call up a friend, you have no
other CD laying around infront of you and you didn't made recent
backups. You then need to figure out another way to do the stuff.
Doesn't this ring a bell or something ? I can't imagine that there isn't
one on here that wasn't in such a situation.. and I can bet that there
is the one or other who may have said 'Shit. I wished it wouldn't depend
on glib.'

I would really like to go with the flow here. I know you are doing a
great work on Midnight Commander and the majority of people are usually
'I go with the real thing' person and I do see the benefits that we work
together to figure a good solution for this and I am not a friend of
forks myself. 20 forks, all halfassed, half supported, left unmaintained
after a while. There is no benefits.

I mean we are not going to change visible stuff to the user, or workflow
relevant parts. We are only changing something in the bottom framework.
It makes you happy, it makes me happy, it makes others happy and finally
an MC with less dependencies. I even think that the uClibc people gonna
thank you here because I do not belive that glib compiles against uClibc
here. The embedded guys would probably be thankful using a most recent,
active and alive project such as mc 4.6.0 on their embedded plattforms
or rescue systems.

I hope you see my point here.

greetings.