Re: A proposal for Midnight Commander

On Sat, 2003-11-15 at 13:31, Koblinger Egmont wrote:
> more intensive usage of glib functions might make mc cleaner
> and more bug-free, and IMHO this is the way to go.

Assuming that glib itself is free of bugs - which you can't depend on.

> Which glib to use is a harder question, Gabucino votes for glib1,
> while I want to kill all the glib1 and gtk1 stuff from my system
> as soon as I can, and I'd rather use a new, actively maintained

Excuse me, in case I may repeat myself half a dozen times now. There are
no large significant parts inside Midnight Commander that justifies it
to use Glib2. It's not like you are removing 2000 lines of code within
Midnight Commander and have it replaced with 1 line Glib2 code. The
memory allocation/free calls are a good example. While they may check
whether they could allocate the memory or could even free NULL they have
no significant benefits over the calls made by glibc or the g_strdup vs.
strdup calls.

About Maintainance. If it wasn't possible to reduce all bugs until now
after X years then something must have significant wrong. Maintainance
of Glib2 on the otherhand makes you depend on other people. Say you
detect a serious bug in Glib2 in an important function you use. You file
a bugreport and then can start having painful discussions with the
maintainers of Glib2. You first will get X times 'NOT A BUG' replies
where your bug will be closed because they are trying to shift this
problem back to you. After you got them convinced that this really is a
bug, you then can continue having long conversations if the bugfix may
break API or not and things like this, while on the otherhand you could
have easily fixed your code within seconds in case something happened
and commit it to your Midnight Commander CVS.

I will give you a good example here enter
bugnumber #112806 and see yourself how many months it took until they
fixed 2 lines within a Makefile to have the modules generated correctly
in GTK+. Ok I don't want to blame anyone here but you were basically
crying for good practical examples why to not use Glib2 (or Glib in
general). I want to be more precise it's not about Glib2 vs. Glib1 it's
about Glib in general here.

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