A proposal for Midnight Commander

[Nerijus Baliunas]

(Pavel, please read my suggestion in the middle of the message)

Ali Akcaagac wrote:

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

glib is used by probably thousands of projects, so logically
it shouldn't contain lots of bugs, and bugs should be found
quite fast.

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

Yes, but Pavel and Miguel want to increase these parts instead of removing
them...;-)

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

Including glib in mc cvs tree should help in this case.

OK, I have a suggestion:
1. Include glib in mc cvs.
2. Make it so that it should be possible to use either glib or
libc functions (at configure time by ifdeffing etc).
3. Then there would be 3 choices -
a) use system glib,
b) use builtin glib,
c) don't use glib at all (i.e. use libc or own functions).
Maybe some features should be disabled in c) case.

> I will give you a good example here http://bugzilla.gnome.org 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+.

Well, I see Owen suggested you to try something, but you didn't -
so why complain? See this:

--Additional Comments From Owen Taylor 2003-06-08

I believe changing install-data-local to install-data-hook
in gtk+/gdk-pixbuf/Makefile.am and gtk+/modules/input/Makefile.am
will fix. Testing would be appreciated.

install-data-hook is, of course, not right since the modules
don't get installed in install-data. install-exec-hook should
work.

--Additional Comments From Ali Akcaagac 2003-06-30

Any future progress with this ? The problem still exists in current HEAD.


You didn't even tell if you tried the suggestion, so why
do you expect the problem to magically disappear?

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

It was bad example.

Regards,
Nerijus