Ticket #237 (closed task: invalid)

Opened 11 years ago

Last modified 11 years ago

Why some removed and same added?

Reported by: slavazanko Owned by: styx
Priority: major Milestone: 4.7
Component: mc-core Version: 4.6.2
Keywords: Cc:
Blocked By: Blocking:
Branch state: Votes for changeset:

Description

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.

Change History

comment:1 Changed 11 years ago by 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

comment:2 Changed 11 years ago by angel_il

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

comment:3 Changed 11 years ago by angel_il

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

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by styx

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

comment:6 Changed 11 years ago by 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


comment:7 follow-up: ↓ 8 Changed 11 years ago by metux

  • Type changed from defect to task

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

comment:8 in reply to: ↑ 7 Changed 11 years ago by 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?

comment:9 Changed 11 years ago by styx

  • Status changed from new to accepted
  • Owner set to styx

comment:10 Changed 11 years ago by styx

  • Status changed from accepted to testing
  • Resolution set to invalid

comment:11 Changed 11 years ago by styx

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.