Why some removed and same added?

[slavazanko]

ticket:161
ticket:200
ticket:225
ticket:228
ticket:235
ticket:236

What wrong? Why do we need to completelly drop glib? Because someone hate glib but love other [unstable] code? Is reason "glib is too big"? Don't launght me. Big and stable - my choise stable.

[slavazanko]

​http://mail.gnome.org/archives/mc-devel/2009-February/msg00015.html

I agree with man - we need to more use glib, but my propose: use via mhl (as wrapper).

If someone want - they may write glib-replacement code (will use via ./configure --without-glib).

As now, we use glib-functions very poor, but glib it's very powerful library. And my IMHO: need to use more functional of glib

[angel_il]

My MIPS embedded devices do not consider glib too big. I vote for stable.

[angel_il]

... and I would be very glad to see optional build with --without-glib

[slavazanko]

About removing ncurses and mcslang stuff - this added at the requests of mc-users and only users can decide to remove this functionality or not.

I propose to initiate a votes by all planned to remove stuffs and make their votes the most well-known that a large number of users has been able to express their views.

[styx]

in addition: I think at first we should aplly all the patches we already have and only then starting cleanups

[Slava Zanko]

---

Hash: SHA1

styx wrote:

in addition: I think at first we should aplly all the patches we already
have and only then starting cleanups

+1.

Otherwise, all existing patches can be incompatible with the head of
development

WBR, Slavaz.

---

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - ​http://enigmail.mozdev.org

iD8DBQFJiBsUb3oGR6aVLpoRAvtxAJ4lBLwZKteLI4KMYfOZxJetrjJNegCfZe1M
5hS3UhFNo8YPPCCeV1YV/oY=
=331s

---

[metux]

#1: glib:

Most of the glib stuff we'd used actually does nothing by itself (g_malloc(), g_free(), ...) or things that easily fit into a few inlines. Some can even be harmful (easy to forget a trailing NULL parameter, don't handle NULL ptrs properly, ...).

ATM we only use very few glib functions which aren't already provided by mhl (GTree, etc). But they're easy to replace.

#2: ncurses vs. slang

I've made some polls on several maillists, and the majority seem to prefer ncurses, but I know there're still some open issues for it.

Perhaps we should table this decision for a while and look if we can get them solved in nearest future.

[andrew_b]

Replying to metux:

ATM we only use very few glib functions which aren't already provided by mhl (GTree, etc). But they're easy to replace.

Why do you like make some work that is already made?