Hello, Timur!
> I'm still thinking, that rewritting mc(mc2:) is the best solution in our case.
> We do have perfect tool for the moment, but it suffers from all that legacy code,
> spagetty functions and all that multi-frontend issues...
Not only from that. It also suffers because we are losing developers.
Developers who can write good code are absolutely vital for any project.
GUI frontends that tend to break when the textmode edition is impoved,
changing the addresses of the mailing lists, long pause between 4.5.51 and
4.5.52 - all that slowed down the MC development.
Consolidation the efforts around one edition, one interface, one graphics
library is the way to attract new people who can do something useful but
have no time to test all different configuration and frontends.
Reusing the existing code, like libsamba and gnome-vfs is also a good way
of reducing the workload on the core team, but only if the libraries are
reasonaly portable.
Installing even glib on an old UNIX where you don't have root is already
painful. Now consider compiling against glib that is installed under
$HOME. This may be very painful for those who are accustomed to `mcview'
and `mcedit' instead of `more' and `vi'.
MC could ship with glib sources, just like CVS ships with stripped zlib
inside. This alone would increase the number of MC users.
> We can try to reuse gnome-vfs, which gives asyncronous access to the FS, what
> was always an issue in MC - scaning of big directories takes notable amount of
> time, impossible to break FS operation in the middle, all the issues with FTP
> updating, etc...
Probably your expectations are too high, but the idea is good. However,
don't forget about portability. I wouldn't bet that gnome-vfs compiles
cleanly, say, on OpenBSD. And Midnight Commander must.
> Widget system - There are plenty of hacks to make it work on old curses, which
> isn't an option nowdays - slang and ncurses was ported to everything....
Even two libraries - slang and ncurses - are too much. But it's very hard
for me to make a choice betweeen the two.
> But, if we'll be able to get working gtk+ in a text mode, it'll give us a front
> end independent widget library, at the top of which we'll be able to build dif-
> ferent flavours of MC2. Otherwise we need to reinvent that layer ourselves.
Different frontends are for different users. They shouldn't share any
user-interface code. Sharing the backends (e.g. vfs) is Ok.
> Also, I heard a lot of complains about absence of plug-in system in MC, like
> a Windows NC-like clone, FAR, has. And the last one is really neat.
I hope it will appear some day. Designing the Plugin API may be a task
requiring very experienced developers.
> Personally, I really would like to get something such nice, as MC and FAR for
> console mode, but improved. And I think, that rewritting is a good option in
> this case.
I hope you mean rewriting step-by-step, not starting a new project from
scratch. The later would be another fork and will divide MC developers
even further.
`IMHO' is assumed in all my statements above.
--
Regards,
Pavel Roskin
