> Time will show. I think S-Lang is better maintained than ncurses, so > we'll submit patches if needed.
I have no experience with slang, but I do have with ncurses. Once I had a minor problem (with the build infrastructure IIRC, not with the library itself), I reported to the author and he correctly replied and fixed it within a few days. There are patches released to the current version every week, so it's easy to stay up with development versions. For slang I don't see such patches or open cvs server or similar, so I can only download tarballs. Slang doesn't have releases too often, either. It seems to me that nearly three years elapsed between 1.4.0 and 1.4.9, which was followed by 2.0 in more than two years. I see that 2.0.4 followed 2.0 very shortly, but that is most likely (I guess) because of some new bugs introduced by larger code-changes and Unicode support, and I don't really think it means that slang will have a faster development cycle from now on. So based on these I don't see why slang is better than ncurses. > As I understand, there is a UTF-8 patch for S-Lang but not for ncurses. > You can ask the author of the patch about the motivation. I assume that > it's just easier to support one library. ncurses has Unicode support (the installed library is called ncursesw, ./configure needs an --enable-widec). The oldest version I found now, namely ncurses 4.2, which was released 7 and a half years ago, already has this configure option so Unicode support is not new at all in ncurses. For some reason, the default ncurses library does not support Unicode, so distributions usually install a non-unicode aware version as libncurses.so, as well as a unicode-aware version as libncursesw.so. I guess there are some compatibility issues why the wide version cannot fully replace the old one. A huge difference between slang and ncurses is, if I read the ncurses manpages and slang2's news correctly, is that ncurses functions use wchar's (that is, UCS-4), while Slang functions use UTF-8. This, I guess, would make thinks even more complicated if mc with unicode support would like to maintain both ncursesw and slang support. Basically I absolutely agree with Pavel's simplification proposal, and actually I never understood why mc was a utility (and actually the only one I know) that supported both ncurses and slang. More compilicated code, more developer resources spent for nothing, different bugs in the two cases, tester people devided into two categories and all hunting for bugs only in mc's usage of one of these two libraries etc... I (as a Linux distribution maintainer as well as developer of some really small pieces of software) believe which library to use is not a decision users or distribution maintainers should make. It is a decision that should be made by mc's developers. Users should accept it and install the library mc developers say mc requires. Personally I vote for ncurses because of the following reasons: - As descussed above, I think ncurses is maintainer better. - Ncurses is much more wide-spread, much more applications use it, hence it's most likely for bugs to arise and get caught and fixed by developers of other applications. So due to its wider use, I guess it's much likely to have less bugs as well as better compatibility with various systems. - Also due to its wide-spread use, ncurses is most likely to be already present in many small (size-limited, e.g. pendrive) rescue systems, since other handful utilities (cfdisk, vim ...) also need it. However, I don't think such systems have any applications (except mc) that use slang. - Ncurses has support to hard-code the terminal description of some terminals to its libraries, hence the terminfo database is not needed at all to operate in some very common terminals (linux, vt100, xterm...) if they're compiled into ncurses. Slang doesn't have this option as far as I know, so it relies on the terminfo database (which is actually shipped by ncurses). >From a packager's point of view, where we have ncurses with built-in support for the terminal types I mentioned above, on a rescue system mc w/ slang introduces another big dependency: the big terminfo database. Okay, I can remove all files from this package except three of them, but there are cases when it's much easier to install either a whole package or nothing at all. However, the most important point should be which library the developers are more familiar with and which library is more likely to make implementing Unicode support easier. Also I agree with Pavel's proposal concerning gettext and other stuff. I could never understand people who say "I have this extremely old system with out-of-date faulty libraries lacking lots of important and cool features, I cannot (or will not) upgrade it, but I need the latest mc, 4.6.1 is not good enough for me when 4.6.2 is already out there". Programmers of libraries invent new features for people to use them, and not for people to just stare at them and wish "oh, if only I could use them... but I cannot because of compatibility issues with ancient systems". -- Egmont _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel