Re: A proposal for Midnight Commander


> The advantage of this approach is that there will be no change in many files
> and,  if desired, we can change implementation of  these simple functions,
> e.g. we can make g_malloc to bail out if we run out of memory.
> But this is just a matter of taste which approach to chose for these simple
> functions.
> > And you ported Midnight Commander for over 60-70% to glibc again. This
> > was only a quick peek I did. A few things need a bit more investigation
> The remaining 30% of mc's glib code usage must be the list code, and I think
> the best way to handle it is just to use glib's implementation.

The problem is wasting the time doing this.

See, one of the worst parts in the code of MC is the input handling:
keyboard, idles and timeouts.   It only handles a few, and has a number
of workarounds and ugly chunks which are no longer required.

A worthwhile exercise would be to replace those with the GLib mainloop,
which would give us timeouts, and would cleanup a lot of messy code in
the viewer, the editor and the shell.

The focus should be on cleaning up *that* code base, taking advantage
of what glib has to offer, rather than introducing more regressions in
the code.


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