Update.
Pavel Roskin
proski at gnu.org
Tue May 1 21:19:58 UTC 2001
Hi, Miguel!
First of all, I hope that you have re-subscribed everybody from the old
list, so we are not just talking to each other :-)
> So we have copied the mailing lists over to gnome.org, and shortly I
> will be shutting down the mailing lists in Mexico, this should be a
> nice addition, as we get archives and all the nice features from
> GNU Mailman.
Yes. This lists are already archived here:
http://mail.gnome.org/mailman/listinfo/
Most importantly, we get somebody who cares about mailing lists.
> * In about a week I will branch the module "mc" in the CVS
> repository. The branch will keep the GNOME code, and the
> HEAD branch will drop support for GNOME and fully deprecate
> tk and xview (they were already, but there is some cruft
> here and there that needs to be removed).
We didn't discuss the situation with the "intl" and "macros" directories.
For the sake of safety they should be physically copied. If you want to
keep shared directories on the old branch it could be done in autogen.sh
that would ensure that the proper (for this branch) version of those
directories is used.
> * MC has accumulated some bad code over the years that we
> would like to clean up at some point. At this stage our
> objective is to go for maintainability and cleanliness in
> the source code to encourage people to contribute.
I cannot agree more.
> Part of this is dropping entirely the multi-"frontend"
> support that we had. Another part will be cleaning up after
> the mess we have done in a few spots (vfs has a few
> "interesting" pieces as well as some of the older code).
I'll also switch the source directories to Automake.
> * We need a web master for the project. The MC web pages are
> old and outdated. Janne did a great job for the MC team for
> a long time, we need to find a replacement for him.
Ideally, it should be somebody with native English. Not sure if we have
anybody eligible in this list.
By the way, some projects keep webpages in CVS. It's very convenient.
> * Updating documentation: we need to update the docs to
> reflect the location of the mailing lists, the web page (old
> or new) and drop the mc.sgml file (which was never actually
> used)
I dropped it in September 2000. I had asked in the list before doing that.
> * Encouraging people to use bugzilla (mention it on the docs,
> have a segfault handler that points to it, include a menu
> entry `Make a suggestion to the MC team',m etc) so we can
> keep track of features requested by people.
Bugzilla? You mean http://bugzilla.gnome.org/, right? I couldn't find "mc"
there, only "gmc".
> * Usability: there are a few spots where we could do better,
> for instance in the text editor if you make changes
> accidentally and you try to quit, you get one of the most
> bizarre error messages I have ever seen.
>
> The problem with the wording and the options and the default
> in that dialog is that I actually have to stop and think for
> a minute about what the dialog is telling me. A total
> contradiction of the Norton-Command interface which is: go
> as fast as can.
If you mean "File was modified, Save with exit?", it's just bad English
and bad syntax. All the translations I have checked have a better
message. Translating back from French, it should be "The file has been
modified. Save and exit?"
The default to "Cancel quit" (I think it should be "Don't exit" in good
English) is actually reasonable. It's the safest default possible.
Or you mean something completely different?
> * MC will be maintained by a team of people (mc-devel), we do
> not want random people making changes to the code without
> some peer-review of their patches.
Yes.
> If you are an "authorized" CVS user (and you have talked to
> me in the past), I just want to ask you that when you make a
> change to MC in the GNOME CVS, you also CC a patch to the
> mailing list.
To the development list, to be precise. One obvious addition - if you are
not 100% sure ask in the list _before_ applying.
> This will provide maximum speed: in one hand you will get
> your change into CVS without having to wait for approval,
> but you will give us a change to review and comment on the
> patch without forcing us to make some complex scripts or
> change our existing updating scripts.
I don't understand the part about scripts. If it's a problem to test a
patch before it's applied you should consider using better update scripts.
> * In the future, when the GNOME VFS progresses we might
> consider replacing the current VFS with the GNOME VFS (it
> has no GUI dependencies, do not fear), but currently it
> lacks a number of features that MC has (tar browsing, extfs,
> fish, good ftp support).
By the way, it would be nice to use shared libsamba for SMB support. It
can probably be done with the existing VFS as well.
> GNOME VFS would also allow us to do cancellation of
> operations at any point (which should be a nice addition).
Yes. That's important, especially for transfers over the net.
> * Cloning good ideas from existing Norton Commander clones.
> Apparently there are some very pretty additions made by the
> FAR file manager. Some of the ones described by Pavel seem
> to be easy to implement (if you are familiar with the Widget
> stuff in MC you would know it is easy ;-).
You probably mean background viewers and editors. Yes, it's a nice
feature. I probably wasn't clear and it's probably a theme for a separate
thread, but the plugins is something different:
1) Plugins adding new items to the "Drive" selection (FTP, SMB, temporary
disk). Mostly implemented, but could be moved to a single place. I would
also like to see there such things as "rpms" - all packages on the system.
They already exist but cannot be accessed from the menu.
2) Plugins that do something on the panels (advanced compare, case
conversion) - we have the language (%cd and such commands) and the system
shell, but not the interface allowing the plugins to create dialogs. The
same problem with plugin configuation.
3) Plugins using custom columns on panels (process list, network browser).
This would be hard to implement.
> * And of course, no program is complete without a mail reader,
> so we have to write one
We have it. It's mailfs. But again, it's not accessible from the menu (it
can be added to the user menu).
> I think that is most of it. Pavel, did I miss anything?
Embedded terminal. I really like this idea.
> The mail thing is a joke: dont start coding such a beast.
Too late. It already exists :-)
cd ~/mail/inbox#mailfs
Ctrl-x q
--
Regards,
Pavel Roskin
More information about the mc-devel
mailing list